Data.Text help

prakash

Hi all,

Can anyone please explain how to know, what i am getting in data.text buffer? And from where i can get all the properties of data.text?


Sent from my Nexus 4 using Tapatalk

prakash

Also when using debugging, its not showing any value in data.text and any variable

Sent from my Nexus 4 using Tapatalk

troberts

I have found it better to use a CREATE_BUFFER and parse from that, than trusting data.text. Refer to tech note 616
http://www.amx.com/techsupport/techNote.asp?id=616

vining

The structure is found in your Netlinx.axi file is is found in C:>program files(x86)>common files>AmxShare>AXIs

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.

GregG

data.text isn't a good buffer, it's just the fragment of string data that has come in when a data_event[] has been triggered.

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
    }
  }
}

vining

troberts wrote: »

I have found it better to use a CREATE_BUFFER and parse from that, than trusting data.text. Refer to tech note 616
http://www.amx.com/techsupport/techNote.asp?id=616

I almost never use a created buffer but instead I do as described in that tech note. I too prefer to keep it in the local scope by using a local_var and concatenating it w/ data.text just like the TN shows.

vining

The rule of thumb for data.text is it is a completely fine buffer for parsing strings from virtual devices but not for any real serial or IP connected devices.

ericmedley

I typically use data.text for virtual device returns. (Modules ). But I also might use it on serial devices with short messages. But, in either case I quickly pass the data on to functions and/or global storage.

I use create_buffer for larger strings like XML, web page scrapes or basically anything where the strings coming back are larger.

TonyAngelo

vining wrote: »

I almost never use a created buffer but instead I do as described in that tech note. I too prefer to keep it in the local scope by using a local_var and concatenating it w/ data.text just like the TN shows.

From that tech note:

Tech Note 616 wrote:

Also note that, as mentioned in the comments, you could create a buffer for this device in DEFINE_START instead of concatenating your own local character array with DATA.TEXT. The advantage to using CREATE_BUFFER is that the buffer is managed by the NetLinx operating system instead of by the interpreted NetLinx code. The results are the same, but your code will run slightly faster, because it is not having to manage the buffer.