TCP/IP instabilities in LabVIEW?

[caleyjag]

I'm just beginning to work with TCP/IP in LabVIEW and I'm hitting some problems. As usual the hardest part is knowing what questions to ask.

Background: Essentially, we have a PC (Windows 7) running LabVIEW (2011), communicating with a Staubli CS8 robot controller. The code on the controller is written using Staubli's native VAL3 development environment. It's set up so that we send it pre-defined command strings via TCP/IP. The robot performs the command and when it reaches its destination it sends a response string.

If I use Putty to send the strings via command line, everything works fine, and I get the response string expected loud and clear afte the robot has performed its task. If I use LabVIEW, however, using code based on the TCP 'active' and 'passive' example functions, I get communication most of the time, but occasionally the system hangs.

The robot almost always get the movement command - this is obvious as it starts moving. The problem seems to be more to do with the fact that the 'listening' portion of the LabVIEW code seems to be occasionally missing the string sent back to the PC, and the listen loop then runs indefinitely, thereby causing the system to hang.

Using timeouts as a quick fix is out as the robot speed can be varied, therefore there is no way to know exactly when the robot is going to send back its message to the PC (although it's always going to be on the order of seconds).

So my initial questions are:

1.) Is a degree of instability normal in communications using TCP/IP?

2.) Why does LabVIEW appear to be less stable than Putty?

3.) Does anybody have TCP example VIs that I can contrast with the two examples that ship with LabVIEW?

[Julianne_K]

Hi caleyjag, 

Typically, we do not see instability like this with the TCP/IP. These types are issues are usually related to programming or network issues. Did you modify the examples at all? If so, can you post them to the forum? 

LabVIEW should not be less than PuTTY for TCP/IP communication. There are some features of PuTTY that LabVIEW does not support, which are explained here.

However, as I mentioned above, TCP/IP should work fine with LabVIEW. You might also want to try the Data Client and Data Server examples provided with LabVIEW or an example on our website for sending string array data via TCP. 

[rolfk]

I can only support Julianne's statements. I have done quite a few intensive network communication libraries and projects and don't see instabilities as you describe them, if the LabVIEW part is programmed correctly. Network communication I have done include both TCP/IP and UDP based protocols and also binary and ASCII style variants of those.

Network programming is different than other LabVIEW programming in several ways. You have to be prepared that network functions can return errors for many reasons, and that some of them should be ignored, some of them indicate to retry the operation, and some require you to close and reopen the connection. Which error means what, is the biggest part of the magic about network programming and there are no definitive rules about this, as it can depend on the used protocol, the particular implementation of the remote side and sometimes other factors you need to figure out.

With some experience you learn to program fault tolerant network communication, that can work with different implementation specific behaviour of the remote side but this stage can sometimes feel a bit like magic and the only way to get it to work right is usually by trial and error, and some logical thinking about what the different network layers are supposed to do.