DATA.TEXT Parsing Best Practise Question

hodeyp

Hi,

I have an AV processor that sends feedback by rs232. The messages are terminated with 0x0D. However, the messages can be several hundred characters in length and it is possible that the 0x0D is actually embedded in the message for a different reason than termination of the whole message.

So, I need to be able to look for the termination character and also asses do I have the complete message.

Any guides as to best way to handle this?

Apologies if this is a bit vague!

ericmedley

Firstly, you should search the forums for this as there are quite a few threads on it that discuss this very issue.

You can use data.text or create_buffer. There's really no significant advantage between them on the grand scale. However, the subtle differences can be better for some situations. Data.text is limited to 2K in size. You can go in and tweak that but I typically don't.

You could try many methods to trap the. $0D. One simple way would be to put the messages in a que. That will slow things down a bit and allow the gear to finish it's message.

another thing to do is append all messages to another buffer and keep parsing it until it's empty. That way you kinda move the 'finding the $0D out of the data_even.

jjames

I use the solution suggested by Technote 616, which was suggested by a friend of mine. Has worked perfectly for years, and have no gripes about it; just be sure to modify the end-delimeter per device. I've run into issues where I forgot to do this - whoops!

John Gonzales

I had to deal with that recently with the Pelco-D protocol, where there was no unique delimiter or etx character. If you can find a checksum byte or data length indicator in the message, that will help you to parse it properly. What receiver is it?

--John

hodeyp

thanks all. its a Tag MacLaren AV192R using their TagTronic protocol. Good idea on data length, there is a byte to tell me data length, if I check this before removing the data from the buffer then if I am still waiting for data i can wait for the next event.

Marc Scheibein

DATA.TEXT also is just the "snapshot" of the byte sequence which has triggered the Event - which may be the complete string expected, a part of it, or just garbage. If the expected string comes "in 2 parts", and the $0D is in the 2nd part, the first part was lost if it was not copied/added into a char array previously. But this is what CREATE_BUFFER() is doing automatically, so why not using it.....

In a lot of cases, the expected string actually is received in one part from serial devices. But if receiving string by IP, in most cases it is not.

If you expect a string from a native NetLinx device (keypad input from a panel, a string response from a moduile's virtual device, etc.) you alway can work directly with DATA.TEXT, because they always come in one part.