TCP/IP Fail

[bmann2000]

I have a manufacturing application that runs a production rig.  I also have a 24/7 logger application running on the same PC, the logger records temperatures and other data about the supporting plant.

Both apps can run independently, but when running at the same time, a TCP/IP link allows the sharing of data between the 2 apps.  They normally always run together, but I want them to be robust to the other not being open.

I have a bug, if the logger is not running for a long time, the manufacturing app freezes.  This is because the TCP/IP listen is somehow eating up a resource.

The reason for the freeze is that TCP/IP comms with another connected instrument fails.  I know this because if I try to open a connection to that instrument using it's dedicated from end software, I get this error:

When I close the frozen LabVIEW app, I can then open the front end without a windows error.

One explanation of this windows error appears to be "OS runs out of memory for TCP buffers".

Have I implemented the TCP/IP incorrectly? I figure I should check I've not failed to close a TCP/IP related resource?

[Mark_Yedinak]

You need to post code, not a picture of it. Can't look at any other parts of your code to see what is going on.

[bmann2000]

Hi,  If I try a save hierarchy as, I end up with dozens of VIs that I don't have permission to share online.

The actual base commands being executed are TCP/IP Open (localhost), TCP/IP Close.  This repeats every 10 seconds in the hope the server will be listening and create a connection.

It appears that after several hours of this, it stops the TCP/IP comms of another connected instrument.

I've since added code that prints time and open/close to file to confirm the code is actually executing as I intended, but that code has not been deployed yet.  The problem is that each freeze on the manufacturing rig costs us a lot of money, and I don't have spare hardware to replicate the problem offline.

I'm hoping someone can spot a fundamental mistake that can be corrected, then when I deploy the modified code, I never see the issue again.

Note, previously I said that TCP/IP Listen might be eating up a resource, that's an error, the Server listens, the problem bit of code is the Client that uses TCP/IP Open Connection/Close Connection.

[rolfk]

Well, if you can't share your VIs, try to create a minimal example that exhibits your problem. Most likely the problem then goes away as you eliminated the race condition or bug in your code. My magic wizardry crystal ball is currenty dysfunctional and that is the only way to get more information about the possible trouble in your VI from just looking at a picture.

[bmann2000]

I've been writing the G Code for a long time, about 18 years, it's unlikely to be something trivial with the diagram.

I'm hoping to find someone with experience of running multiple TCP/IP connections and the likely conflicts possible that might generate a windows error.  Mind the error is not from LabVIEW.  I suspect that LabVIEW TCP/IP Open & TCP/IP Close executed back to back for a long time are somehow interfering with the TCP/IP comms of another connected instrument.

The loop in the code posted executes TCP/IP Open, this fails to achieve a connection, which results in the close case executing where TCP/IP Close is executed.  This process repeats every 10 seconds, then 10 or 12 hours in, the other instrument loses TCP/IP comms and the windows error appears.

Is there any reason these two commands can't be executed without causing an issue?  All the other VIs in the code just relate to the variable names and data sets being passed around.

[Mark_Yedinak]

I have been using TCP connections in LabVIEW for over 20 years and have never encountered this error. You need to post some code so we can assist you. If nothing else write a simple Vi that does nothing but Open/Close a TCP connection repeatedly at a rate of let's say once per second. If that is the issue this very simple VI will expose it. It is impossible to help if we do not see your code to see what is going on. As mentioned, if you cannot post all the code create a very basic set of VIs that does and post that. Then we should be able to assist you.

Here is a very basic example of what I am referring to.

[Mark_Yedinak]

As an experiment, I started to run the code I posted above shortly after posting it. I also have several LabVIEW applications that are reading data from an external device.At present I have nearly 310K iterations of the TCP Open/Close and have not experienced any issues. The number of iterations that I have executed far exceed the number that you would run in the 10 or 12 hours before the error occurs. I highly suspect that there is something else going on in your code that is causing the problem.

[rolfk]

---

@Mark_Yedinak wrote:

I highly suspect that there is something else going on in your code that is causing the problem.

---

A probable cause is that some of the sockets opened with TCP Open, are not properly closed.with TCP Close due to bad error handling. Winsock only can have about 64k sockets opened at anytime and will then run into resource contention, which quite possibly might be reported as out of memory condition by some of the socket functions.

Note that executing TCP Close with an error in is not causing this. The TCP Close will still attempt to close the incoming refnum even if error in indicates an error, so the error must be earlier.

Another popular error is that somewhere you have a case structure with an output tunnel that is set to use default when not wired and above that another tunnel that "seems" to wire the refnum out of the case structure. This way you loose the refnum and TCP Close will report an invalid argument error (1) but it's not uncommon to ignore errors from TCP Close altogether. The lost refnum is still open in LabVIEW and contains an aquired Windows socket and LabVIEW only will close it when the VI hierarchy in which it was opened goes idle.

[bmann2000]

seems I was off the mark with the assumption that TCP/IP open/close was the culprit.

the application has stopped again, same windows error but this time the TCP/IP comms between the two application is still running fine.  I was able to close 1 app and re-open, then the TCP/IP connected was re-made automatically as the code intended.

All I know for sure now is that LabVIEW is failing to send a command to a TCP/IP instrument, it hangs because the instrument fails to response to the handshake

[Mark_Yedinak]

---

wrote:

seems I was off the mark with the assumption that TCP/IP open/close was the culprit.

the application has stopped again, same windows error but this time the TCP/IP comms between the two application is still running fine.  I was able to close 1 app and re-open, then the TCP/IP connected was re-made automatically as the code intended.

All I know for sure now is that LabVIEW is failing to send a command to a TCP/IP instrument, it hangs because the instrument fails to response to the handshake

---

After decades of using TCP communications in LabVIEW all I can say for sure is that you have a bug in your code. This is not an issue with LabVIEW itself or how it uses TCP. Based on your description above it sounds like you are not handling the TCP errors correctly.