Data.Text question

vegastech

Now that I have a few rs232 devices and a few IP devices running on my home system, I have a sort of educational question with regard to data.text: Since I am creating buffers for each of these devices, how does the system know what to put into which buffer, based on the initial flood of data into data.text, like at startup? I'm thinking in terms of an alarm system that is constantly (or at least frequently) sending zone status data, along with, say, a weather parsing function sending info as well. Does it ALL just go into data.text as it is sent, and then the coding figures it all out from there?

Marc Scheibein

DATA.TEXT contains only the "snapshot" of data came in between the last execution of the DATA_EVENT and the current. It can have upto 2048 bytes at one time.

DATA.TEXT can easily be used e.g. to receive a keypad string from a panel or data (string, command) from a virtual and Duet device, because the data packet always is complete (imagine that the panel or virtual device is doing a SEND_STRING with the complete message native on NetLinx).

On a serial port or manually programmed IP communication, it is not quaranteed that the data the device has sent is a complete packet, containing the full working string from begin to end, espacially on IP connects. For example, you may expect 20 bytes for a full response on RS232, but after 10 bytes a "lag" in the datastream may occure, and so the datastream is not complete within time. You may now get a 1st Event where the DATA.TEXT contains the first 10 bytes, and from the lag, a second event with the next 10 bytes but the first received bytes get lost.

With the above limitation of 2048 bytes, using the DATA.TEXT you can receive "only" 2048 bytes in one event cycle, which may be too less on IP. CREATE_BUFFER automatically copies the incoming data from the port's inbuffer to the software array, and the software array can hold much more as the 2kB data.

vining

Marc Scheibein wrote:

With the above limitation of 2048 bytes, using the DATA.TEXT you can receive "only" 2048 bytes in one event cycle, which may be too less on IP.

Actually Ethernet is limited to 1500 bytes per transmitted chunk so as long as you concantenate the received string using data.text to a large enough var your safe. cVar = "cVar,data.text" ; providing you don't go above 15999 bytes. If you do there's concanstring function originally posted by AMXJeff that can be used to concantenate strings larger.

http://amxforums.com/showthread.php?t=4406&highlight=mtu&page=6

ipssheldon

On a more basic level, each Data_Event has its own DATA.TEXT. For instance, here is one way to handle the incoming data:

DATA_EVENT[dev1]
{
STRING:
{
// handle data.text for dev1 here
}
}

DATA_EVENT[dev2]
{
STRING:
{
// handle data.text for dev2 here
}
}

etc.

Or you can use CREATE_BUFFER for each device and process the buffer variable in each string event as well. In that case, capture the data in each buffer as follows:

CREATE_BUFFER dev1,dev1_buffer
CREATE_BUFFER dev2,dev2_buffer

Through either approach, Netlinx will simply provide you with the incoming data from either dev1 or dev2. You don't have to worry about how it happens.

Hope this helps.
Sheldon Samuels

vegastech

Sheldon,

That's exactly what I was looking for! "each Data_Event has its own DATA.TEXT".

vining

There is only 1 data.text per system but as long as you reference data.text with in data event for a device your safe. As many devices as you want can use data.text but it can only be relied on to have accurate data for a particular device during that device's data event. Since the system can only handle one event at a time this works fine. If you reference data.text outside of the data event it will be holding data from the last device to trigger a data event system wide. So although you can reference data.text outside of a data event in most case you probably shouldn't.

ipssheldon

To further clarify this, it is my understanding that the most efficient approach is to combine CREATE_BUFFER and DATA_EVENTS. Netlinx will add incoming data into a buffer through the CREATE_BUFFER faster than the same data will arrive in the DATA.TEXT associated with a DATA_EVENT. However, you can still process the incoming buffer in the DATA_EVENT. Something like following:

DEFINE_START

CREATE_BUFFER dev1,dev1_buffer

DEFINE_EVENT

DATA_EVENT[dev1]
{
STRING:
{
// process dev1_buffer here
}
}

In this way, you know that the dev1_buffer contains the incoming data for dev1 only, but you only have to worry about processing that incoming data when the DATA_EVENT is triggered.

It just depends on how you manage your devices and the incoming strings.

Hope this helps.
Sheldon Samuels
SchoolView Technologies, LLC

ericmedley

For me the choice is based around these principles (somewhat loosely)

If the data coming in fits the size limits of data.text AND I'm not going to be doing any serious string chopping, I'll use data.text. I usually just create a stack_var buffer and dump data.text into it, chop away and leave the data_event with what I need.

If the data coming is is from a chatty device, I'll use data.text to append data to the end of a large buffer with a delimiter and setup a queue that handles the buffer elsewhere. This is how I handle all my module<->main program communication on modules I write myself.

For slower baud rate gear that is chatty but the messages are smaller I'll go with good ole' Define_Buffer. I've found that data.text can misfire on slower gear. It thinks the gear is done talking when it may or may not be.

For web page scraping, I almost always use define_buffer. It handles the larger data sizes and chunkiness of internet communications better in my opinion.