Buffer vs. Char Variable

davidv

What is the fundamental difference in storing data into a buffer or storing char data into a char variable?

Can you store data to either or is it specific applications?

Jeff B

A buffer is a char variable that is associated with a device.

dvDEVICE = 5001:1:0

CHAR Buffer[50]

Create_Buffer dvDEVICE, Buffer

This is used to buffer incoming data from a serial port. You can also use DATA.TEXT for this purpose.

JB

DHawthorne

In other words, the variable itself is identical. The only difference at all in using CREATE_BUFFER is that incoming strings are automatically appended to the variable.

Jeff B

DHawthorne wrote: »

In other words, the variable itself is identical. The only difference at all in using CREATE_BUFFER is that incoming strings are automatically appended to the variable.

Yes this is true, but since they fixed DATA.TEXT many years ago I never use it. Just extra work to set it up.

kbeattyAMX

What do you mean about fixing data.text? I thought data.text is continually overwritten as data comes in from a device. So to buffer strings from data.text, you'd have to append it to a variable that would act as a buffer for the incoming data. I haven't used the CREATE_BUFFER keyword in years.

Jeff B

Early in NetLinx history, the DATA.TEXT object did not work correctly. It is always good practice to transfer data from DATA.TEXT or a variable associated CREATE_BUFFER to a new variable for processing. Most often a temp variable within the data event is sufficient.

JB

kbeattyAMX

From my understanding, data.text is and was not intended to be a buffer. It's max length I think is 125bytes and if the data being recieved is too slow, it will break it up. (eg. INC OMI NG). So if your are waiting for a certian string, you may only see a part of it. This happened recently to me when a extra vortex2280 was added to a system. I was ramping a crosspoint value with a wildcard and the string became too long to fit into data.text. So of course I did, cIncoming = "cIncoming,data,text" to capture the whole string. Now CIncoming is buffering the incoming data. Buffers to me are VARS holding transient data that are cleared on my discretion.

vining

kbeattyAMX wrote:

It's max length I think is 125bytes

DATA.TEXT is defined in the NetLinx.axi with a lenght of 2048.

STRUCTURE TDATA
{
  DEV      DEVICE;
  LONG     NUMBER;
  CHAR     TEXT[2048];
  CHAR     SOURCEIP[32];
  INTEGER  SOURCEPORT;
  DEV      SOURCEDEV;
}

ericmedley

vining wrote: »

kbeattyAMX wrote:


DATA.TEXT is defined in the NetLinx.axi with a lenght of 2048.

STRUCTURE TDATA
{
  DEV      DEVICE;
  LONG     NUMBER;
  CHAR     TEXT[2048];
  CHAR     SOURCEIP[32];
  INTEGER  SOURCEPORT;
  DEV      SOURCEDEV;
}

you can modify this too. I don't since it handles most thing more than well enough. For large buffers and/or web page scraping, I switchh over to CREATE_BUFFER. We learned in PROG III (part deaux) that there is no problem with either method and they are both acceptable.

vining

ericmedley wrote:

For large buffers and/or web page scraping,

For web scraping it's actually better to use DATA.TEXT. Since the laws of Ethernet prevent chucks of data over 1500 bytes at time which is well with the means of data.text your can create a var just big enough to hold the actuall section of the return you need and start appending incoming data to it when get to the part you want and stop appending data to the var when you find the end of the portion you need. Much more efficient than creating a buffer big enough for the entire return up to the end string you're looking for.

If you need to append data to a var larger than 15999 you can just use string to var function that AMXJeff posted a while back.

DHawthorne

DATA.TEXT is not reliable for serial devices. If they pause a bit too much mid-packet, it considers it the end of the text. Though less likely, I presume this is also possible for IP data. I will only use DATA.TEXT directly for messages local to the system, like internal communications between virtual devices. Since CREATE_BUFFER doesn't have those issues ever I use it whenever talking to a device. I simply don't have the time to be trying to track down that one time I have an incomplete message in DATA.TEXT, even if it's a one-in-a-million shot. You know how it goes ... those odds drop considerably the more time-sensitive your situation is and the more critical the communication.

fogled@mizzou

I always use 2 CREATE_BUFFER statements for just about all device communications - both an incoming buffer tied to a real device, and an outgoing buffer tied to a virtual device. The cost of code is worth the control and consistency in communications.

kbeattyAMX

Read TechNote TNDL616. It got some great insight on the subject..