Telnet Buffer Questions

[CodeMunkee]

Hi,

Modems are configured to telemeter data to a LabView VI.  The LabView VI works as designed when hardwired to the instruments.  Now a modem and internet connection replace the hardwire, so a reconfiguration of the VI was required using Telnet Read/Writes instead of VISA Read/Writes.  Initially there were some kinks associated with the modem configurations, but those have been worked out.  Reason for backstory: I believe I have isolated my issue to how I use/configure Telnet Read.

My issue: data dropouts and incomplete data packets.  I receive 25 bytes of binary data per second, easiestly viewed as Hex when it streams in.  A valid packet looks like this:

0119 81CC 4C47 884B 5722 7ECA 000A FA37 7E52 FC66 7CF7 25D0 04

where 01 begins the sequence, and 04 ends the sequence.  All the mess inbetween is useful to me, but completely uninteresting to most sane people.  Attached are two examples of code.  The first, TelnetEx.vi, is a simple version of how I use the Telnet Read.  When I use this configuration I think I am buffering 25 bytes of data then ending the line whenever a hex04 is observed.  All too frequently I receive packets that are not 25 bytes long, but end in hex04.  By the way, I haven't been successful using 'normal' or'immediate' mode with the Telnet Read - I get no data packets delivered at all.  (??)

So I thought if I could hardwire a way to spot-check the 25-byte buffered data packet then I would outsmart the incomplete packets (an incomplete packet results in false spikes in my data as the VI is wired to look for data in a particular byte location in the data packet). An example of this shoddy attempt is shown in TelnetEx.vi.  When I apply this filter, I receive no data.  The filter is supposed to look for hex01, then look for hex04, then count to see if they are 25 bytes apart, and if they are, send that data to the rest of the VI because it is a valid packet.

One last note: I have been tinkering with the VI and found that if I use the time-delay at a faster sampling rate (10Hz) than my instrument (instrument = 1Hz) then I have fewer incomplete packets delivered, and sometimes there is a pause that looks like a data dropout and then I receive multiple packets at once.  This is probably a connection/packet delivery issue, but perhaps someone has seen this before and knows a good way to handle it?

Is the Telnet Read buffer a FIFO?  Is there a more sophisticated method of checking the validitiy of a data packet than my mangled attempt?

Thanks,

~Tristan

[Mark_Yedinak]

Take a look at the revised example. Also, are you guaranteed that the 0x04 will never be part of the data itself and it will only appear as the termination character? My example assumes that it will only appear as a termination character and never be part of the valid data. Have you sniffed the data using a LAN analyzer (think Wireshark) to verify what is actually being sent by the device?

Under the hood at the socket layer data does get buffered. In fact, depending on the implementation of the stackon the device sending the data you could receive multiple packets of your data in a single TCP packet. It is legal and valid for the stack to buffer data before sending it. This generally occurs more often when you are sending lots of small packets very quickly. In your case I doubt this is happening.

Message Edited by Mark Yedinak on 10-22-2009 05:24 PM

[CodeMunkee]

Thanks for the suggestions and the interesting ideas. 

I can't open your file since my LV 8.5.1 is not forward compatible with your LV 8.6.  Any way you can save as LV 8.5?

Thanks,

~Tristan

[Mark_Yedinak · Accepted solution]

Here it is.

[CodeMunkee]

Hey Mark, you rock!

[Mark_Yedinak]

---

CodeMunkee wrote:
Hey Mark, you rock!

---

Thanks. Glad I could help out.

BTW, I thought about the example I posted and thought it could be improved by filtering the errors. It could be changed to only filter out the timeout errors but capture and process other types of errors. This would make it much more robust and able to handle the connection being closed by the remote end, something the current version would not handle properly.

Message Edited by Mark Yedinak on 10-23-2009 05:37 PM