Best Of
Re: Data.Text help
this is it:
STRUCTURE TDATA
{
DEV DEVICE;
LONG NUMBER;
CHAR TEXT[2048];
CHAR SOURCEIP[32];
INTEGER SOURCEPORT;
DEV SOURCEDEV;
}
It's a global structure and holds the current or last incoming string if nothing is current of all input buffers. Netlinx is single thread so only one event can be processed at a time.It should only be used in a device's data_event or a function called by one. Use a send_string 0 to print what is being received in each data.event and add into your send_string 0 a description of what that event is so you know what you're looking at in diagnostics.
Again it can only be guaranteed to have the data you're expecting when used inside a data event handler or function it immediately calls for any given device you're expecting data from so don't use it anywhere else.
vining
Re: Data.Text help
It only exists and is expected to contain relevant data while inside the string: or command: sections of a data event, which is only a few milliseconds.
If you want to debug strings you can use 1 of these 3 methods. (There are more ways, but I'm not teaching the whole class here.)
1) Use send_string 0 to see the strings in diagnostics or telnet:
Data_Event[dvDevice]
{
String:
{
Send_String 0,"data.text"
// Do stuff with the incoming string in data.text
}
}
2) Assign it to a variable and watch that (add cData to your debug variables):
Data_Event[dvDevice]
{
String:
{
Local_Var Char cData[2000]
cData = data.text
// Do stuff with the incoming string in cData or data.text
}
}
3) Create an actual serial buffer and watch that instead (add cBuffer to debug list):
DEFINE_VARIABLE
Volatile Char cBuffer[2000]
DEFINE_START
Create_Buffer dvDevice,cBuffer
DEFINE_EVENT
Data_Event[dvDevice]
{
String:
{
// Do stuff with the incoming string in cBuffer
}
}
I usually prefer the 3rd option, since there is never any guarantee that the serial string coming in from rs232 is complete. Sometimes, usually on long strings or slow talking devices, there will be more than one string data_event that makes up a complete reply. Using the 3rd method cBuffer will keep collecting the whole string until you remove the data yourself.
For example with messages coming back that are expected to end with carriage return (ascii 13):
DEFINE_VARIABLE
Volatile Char cBuffer[2000]
DEFINE_START
Create_Buffer dvDevice,cBuffer
DEFINE_EVENT
Data_Event[dvDevice]
{
String:
{
Stack_Var Char cCompleteReply[2000]
While(Find_String(cBuffer,"13",1)
{
cCompleteReply = Remove_String(cBuffer,"13",1)
// Check cCompleteReply against the list of expected replies from your device
}
}
}
GregG
Re: Open Popup After Holding Button For Designated Time
From the sounds of it, your command to trigger the pop-up is incorrect. Control a Device is a feature within Netlinx Studio under the Diagnostics header of the menu bar. You would enter the device number, port, and system for your panel. Within the large text box, you would enter your command to send and check the radio button for COMMAND (instead of string).
^PPN-Room Control
then click SEND. This test removes your code logic from the equation and is a straight send command to the device to proof the syntax.
Re: Open Popup After Holding Button For Designated Time
Marc means that you can open NetLinx Studio -> Diagnostics -> Control a device and send the ^PPN command as it is sent in your code:
Essentially that way by-passes your code and sends the command direct to your panel to check if the popup name is spelled correctly...
Re: LG 110" Monitor Discrete IR codes
Well, the solution was very simple... Just a custom box with USB input and a dry contact output.
The box is connected to the LG usb port supplied with 5Vdc while the monitor is ON.
If the monitor is OFF the usb is not supplied.
A very simple circuit inside the box is taking that voltage and triggers a relay accordingly.
We finally connect the relay output - as a dry contact - to the NX IO ports.
That's it....