TCP Read in LabVIEW on Windows

[LabVU_Dog]

Hello all,

I'm interfacing a piece of instrumentation over a TCP connection from LabVIEW (actually 4 devices simultaneously on the same network, one cnxn each) version 8.5.1 on Windows (tried XP and Vista, identical behavior). I'm able to connect to the device and communicate withi it and control it. One mode that the device(s) use will send binary data packets at 500Hz. I can receive them and process them without thruput trouble. But, I have another problem that I think is related to the device.

When I operate the devices at 400Hz or slower, then send the STOP command (vendor defined protocol), everything works OK. The device stops sending data immediately. If I read the data available immediately after the STOP command (using IMMED mode on TCP read), I get all of the data and need do nothing further to clear my input buffer. If I run 400-460Hz, I notice that I have to wait about 1-2 seconds and do a second TCP Read to clear my input buffer, but the device always stops. The problem gets really bad when I go to full 500Hz. If I continue to execute TCP Reads faster than 2Hz, the device(s) will send data forever! The devices act as though they never receive the STOP command.

The device accepts the STOP command over TCP, and I am checking my error when sending (none generated). My understanding is that if I get no error, I am guaranteed that the message made it as far as the HW layer on the recipient. Is this correct? The devices are running VxWorks.

Here's the weird part:
If I execute TCP Reads faster than 2Hz on the Windows machine, the device will send data indefinitely, despite no errors . I know that the data are new because there is a unique frame number in each message, and they are increasing monotonically. If I pause the TCP reads for more than 1-2 seconds, the device stops sending data. I will need to read my input buffer 2 times (seems to be a maximum of 72192 bytes returned for any message, maybe an artifact of VxWorks??) to finish reading the data. After that, the device sends no more. When I query the device status, it indicates that it is done scanning and ready for a new operation. It is acting as though my frequent TCP Reads keep the VxWorks system too busy to respond to the STOP command, that is still waiting in it's input buffer. But, when I slow down, the device has a chance to catch up and obey the STOP command.

My understanding is that messages communicated over TCP are handled by the OS/ HW driver. As data become available at the HW layer, they make their way up the OSI stack to the app layer, where I read them. The behavior of the system, as described above, seems to only make sense if the TCP Read command is actually causing communication at the HW layer to keep the device busy. Could this be so? I'm using Immediate mode for the TCP Read, and requesting more bytes than I should ever have waiting for me.

Thanks for any thoughts or shedding light.

Derek

[Kameralina]

Hello Derek!

LabVIEW in fact uses wrappers to call system DLLs when doing TCP communication, so it is actually the operating system that is taking care of the entire communication.  Aside from operating system settings, packet size can also play a role and you may see different results when playing with packet size for different TCP transfer rates. 

Also, I wanted to clarify whether you meant 2 Hz or 2KHz when refering to the state where your instrument does not read the STOP command.

Have a great day!

[LabVU_Dog]

Yes, I meant a "poll" rate of 2 Hz.

If I attempt a TCP Read in IMMED mode in LabVIEW, requesting more bytes than are currently available, does this cause any reaction at the HW level? Based on the performance of my system, it seems that it does. If so, how can I prevent LV from doing this?

[Kameralina]

If you request more bytes than are available with a TCP Read command, then this TCP call will clear out the hardware buffer.
Because these functions are intrinsic to the operating system, you cannot use LabVIEW to prevent this from happening.

Does this answer your question?

[mesmith-ut]

This is mostly on topic - I'm curious because I'm working on a winsock DLL that allows IPv6 and IPv4 TCP from LabVIEW and I'm trying to make the functions as compatible with the existing functions as practical (so a user can mostly just drop these in as replacements for the native LabVIEW functions).  So, do all modes of the TCP read command (Standard, Buffered, CRLF, Immediate) clear the hardware buffer?  Buffered and CRLF documentation says they don't return any bytes if certain conditions aren't met (timeout, no CRLF in string).  Do these bytes get read and discarded?  Or does the LabVIEW implementation peek at the port (which seems to be a cardinal sin in sockets programming) to see how much data is there before it decides whether or not to return any, or does LabVIEW retain these bytes in an internal buffer that gets served up on the next Read call (seems unlikely). 

Thanks,

Mark

[NathanK]

Mark,

No peeking is happening.

As unlikely as it may seem LabVIEW maintains an internal read buffer that will hold on to the bytes that are read and not returned to the diagram.

By the way- I am very interested in your IPv6 project.

[mesmith-ut]

OK - so if LabVIEW is maintaining the buffer, then it would be appropriate to just create the Immediate and Standard modes inside the DLL as pure Winsock 2 calls and then manage the Buffered and CRLF modes at the VI level.  This is easier for me since I'm no C/C++ wizard 😉  I plan on posting the completed DLL, VS project, and VI library on the LAVA site when complete.  Also, this is a continuation and refinement of some example code that Christian Loew at NI wrote as a proof of concept for using IPv6 inside LabVIEW.  What I'm doing is making the interface as much as possible a direct drop-in replacement for the Native TCP/IP LabVIEW functions and making it usable for IPv4 or IPv6 calls.  If you have a need for this, let me know and I'll let you know when I get it ready for public consumption (should be soon). 

BTW, not to doubt your advice, but how do you know how LV handles the read internally?

Thanks,

Mark