DATA.TEXT still limited to 255 characters ?

vincen · March 2007

Hi,

As told in subject, DATA.TEXT is still limited to 255 characters or is there a way to get that limit up ? as I prefer to use data.text in events than old fashions CREATE_BUFFER

Thanks

Vince

yuri · March 2007

no, it breaks up after 255 characters... it's a pitty

NMarkRoberts · March 2007

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

Marc Scheibein · March 2007

DATA.TEXT internally has a size of 2048 bytes.
From the NetLinx.axi file:

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

But like noted above, in most cases it is best to do a CREATE_BUFFER, because you never know if the data received is a complete dataset.

If is a string from a Device (i.e. Keypad data from a panel, virtual device, etc.) you can work directly with DATA.TEXT, because this data comes on "system level",so the string is always complete.

vincen · March 2007

NMarkRoberts wrote:

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.

Yep but then it's yet better to use old fashion CREATE_BUFFER because all the more DATA.TEXT is a char so impossible to receive extended characters in it

Thanks

Vince

vincen · March 2007

Marc Scheibein wrote:

DATA.TEXT internally has a size of 2048 bytes.

Thanks for the detail but why do we have only 255 characters avalaible in programmation ? It looks strange that restriction

Marc Scheibein wrote:

But like noted above, in most cases it is best to do a CREATE_BUFFER, because you never know if the data received is a complete dataset.

Yep I think I'm going to continue in the old fashion way

Marc Scheibein wrote:

If is a string from a Device (i.e. Keypad data from a panel, virtual device, etc.) you can work directly with DATA.TEXT, because this data comes on "system level",so the string is always complete.

Not really as it's for IP communications and I receive a string of nearly 15k of characters so I'll use BUFFER and CREATE_BUFFER as we did in old time in Axcess

Thanks for all

Vince

DHawthorne · March 2007

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 · March 2007

DHawthorne wrote:

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.

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

DHawthorne · March 2007

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.

TurnipTruck · March 2007

Pleaee offer me a clarification,

I have a serial device which can regularly deliver strings above the 255 character limit that is being discussed.

I am currently receiving data from the device like this:

DATA_EVENT [dvDATA_SOURCE]
{
STRING:
    {
    cBUFFER="cBUFFER,DATA.TEXT"
    }
}

Should I consider filling the buffer Axcess style instead of DATA.TEXT?

What about strings from virtual devices to real devices and vice-versa over 255 characters?

Thanks!

Marc Scheibein · March 2007

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.

Spire_Jeff · March 2007

If you use the CREATE_BUFFER dvDATA_SOURCE, cBUFFER command in your DEFINE_START section, then you can use something like this:

DATA_EVENT[dvDATA_SOURCE]
{
  STRING:
  {
    STACK_VAR CHAR CUR_CMD[MAX_CMD_LENGTH] 
    WHILE(FIND_STRING(cBUFFER,END_COMM_SEQUENCE,FIND_STRING(cBUFFER,START_COMM_SEQEUNCE,1))
   and FIND_STRING(cBUFFER,START_COMM_SEQEUNCE,1) )
   {
     REMOVE_STRING(cBUFFER,START_COMM_SEQEUNCE,1)
     CUR_CMD = REMOVE_STRING(cBUFFER,END_COMM_SEQEUNCE,1)

      ..... Process command
   }
  }
}

This will then only check the buffer for commands when the device receives text. Also, I normally use While(FIND_STRING(cBUFFER,START,1) and FIND_STRING(cBUFFER,END,1) and (FIND_STRING(cBUFFER,START,1)< FIND_STRING(cBUFFER,END,1))) but as I typed this, the method I used above seemed more appropriate. I mention this simply because I have not tested it and I have been out of state programming for the last 10 days straight so it's possible that my reality and yours don't coincide at the moment ;) 

Jeff


[QUOTE=TurnipTruck]Pleaee offer me a clarification,

I have a serial device which can regularly deliver strings above the 255 character limit that is being discussed.

I am currently receiving data from the device like this:
[code]
DATA_EVENT [dvDATA_SOURCE]
{
STRING:
    {
    cBUFFER="cBUFFER,DATA.TEXT"
    }
}

Should I consider filling the buffer Axcess style instead of DATA.TEXT?

What about strings from virtual devices to real devices and vice-versa over 255 characters?

Thanks![/QUOTE]

DATA.TEXT still limited to 255 characters ?

Comments