DATA.TEXT still limited to 255 characters ?

You can never be sure (when receiving from an external device) that the contents of data.text is the entire string, no matter how long it is, so you should always concatenate to a buffer that you manage, and check that it contains the string length or terminator that you want before acting upon it.

define_integer
char sBufferedReply[lots]

define_event
data_event[dDevice]                                               
  {
  string:
    {            
    sBufferedReply = "sBufferedReply,data.text"

    while(terminator present)
      {
      remove terminated string
      process it
      }
    }
  }

I don't know that I would qualify CREATE_BUFFER as "old-fashioned;" furthermore, I expect that considering it so biases one towards not using it when it really is a better solution. It's just a different way of doing things that has it's place.

vincen wrote:

Well I consider it old fashion as it means you need to use DEFINE_PROGRAM loop which is not in my idea best way to program in NetLinx. All programs I do in NetLinx don't have any DEFINE_PROGRAM neither DEFINE_START section as it was good only in Axcess

Vince

I think you are mistaken. DEFINE_START is the only place some things can be done (CREATE_LEVEL and CREATE_BUFFER being only two examples). In most cases you can do without DEFINE_PROGRAM, but I would hardly qualify "good programs" as never using it. You are limiting yourself to only some of the tools in your toolbox with that kind of view. Just the fact they existed in Axcess doesn't make them obsolete. Besides, you can still use CREATE_BUFFER without using any code in DEFINE_PROGRAM, just use your STRING handler in the data event to trigger parsing the buffer.

CREATE_BUFFER is an automated copy of data from the hardware buffer to software. Imho this is not an "AXcess oldie" but still a common way to get the data received from a device into a software buffer.
From my understanding, if a CREATE_BUFFER was done, any data is immediately copied from hardware buffer to software, instead of the sBuffer = "sBuffer,DATA.TEXT" which requires an Event.
An Event is triggered if a break happens in the data stream, and the length of the break depends on the baudrate, it's not triggered by a "the string I received is complete".

While DATA.TEXT can receive upto 2048 characters in one event trigger, depending on NetLinx hardware you have 255 bytes (NI series) na 2048 bytes (NXC-COM2, NXI) hardware buffer for each serial port.

With receiving ethernet data, afaik this differs a little, because a IP packet is limited to 1000 bytes, and depending on the protocol (i.e. receiving a telnet terminal input) every character is an event.

Next is the virtual device or a physical device which sends strings.
If you have a touchpanel with a keypad, you will receive from it like 'AKEYP-123456'. Because this is sent by the panel on system level (within ICSP/AXlink protocol), you can be sure that this string is always a full dataset. So mostly it's not required to do a CRAETE_BUFFER to the panel and you can receive and operate that AKEYP- data in DATA.TEXT directly. This is also the same if you send and/or receive data in/from a virtual device. SEND_COMMANDs and SEND_STRINGs are always one dataset and they are always "complete" within the ICSP/AXlink protocol. But depending on the hardware (i.e. command length to a panel, terminal output) it may be required to split up the userdata into several parts.