TCP open connection freezes LV2014 completely

[wolfkil]

We have the problem that a subVI that should read values from a powersuply via a TCP/IP conection every five seconds does from time to time make LV to freeze such that also other indipendently running VIs freeze. From our problem solfing thus far it seems that the subVI already freezes while calling the "TCP open connection" to the adress specified device. This device is attached to a second network "card". I first only attach some screenshots.

Would be thankful for any advice how to solve this problem.

Thanks Wolfgang

[pincpanter]

Would it be possible to leave the connection open? You may manage the connection in an Action Engine vi.

Actions to be defined would be Open, Close, Get, Re-open. Open would be used at program start, Close at program cleanup, Get to output the connection reference, Re-open (close and open again) in case of read error.

In case you don't know Action Engines, they are vis keeping some data in a shift register (typically) and executing actions on these data (an example is here ). In your case, data would be the connection reference.

[wolfkil]

Not sure? Due to long time ago experiences on VISA connections I refrained from keeping connections open for long time and decided to always close and reopen. OK with the action engine as you recommend one would find a clever in between solution only reopening when problems are occurring. However, this would imply that one always has to check the connection before using it. To be honest I never worked with this kind of action engines as a Functional Global Variables (FGVs). I will have a look to the example you referred. However, the potential problem that LV will freeze due to TCP-open-connection is just reduced and thus the time when this might happen somehow prolonged. Not really down to the root of the problem.

[pincpanter]

If the connection is bad you will get an error from the TCP Write node.

Using TCP functions directly is closer to invoke the Windows API directly than using VISA.

The reason of the freeze is most probably due to something occurring at the OS level than to the application level. If this is true, you can't do much in the LV program to avoid the problem.

[wolfkil]

---

@pincpanter wrote:

The reason of the freeze is most probably due to something occurring at the OS level than to the application level. If this is true, you can't do much in the LV program to avoid the problem.

---

That would finally come to an "solution" what someone else also sated somewhere here in another thread on TCP:

Programming in LV with the TCP-open is always prone to freeze your program and LV completely --> i.e. no good way to program at all as there is no way to catch your program from hanging.

However, I'm not willing to say that here LV is not the problem but Win7. Why is there a timeout input for this TCP-open when problem anyhow freeze the whole LV with others independent VIs running?

Just two hours ago I realized that another company of data acquisition boards with TCP/IP connections have chosen to establish the communication via .NET. Maybe that they also realized this problem with the LV TCP-open routine and solved the problem by circumventing with .NET.

[tyk007]

It is not normal for a TCP Open to block other threads in LabVIEWs execution system in the way you describe. It should also not block the user interface that would result in LabVIEW no longer responding to windows messages (via the root loop). Given you are working with more than one network card the problem could be something else. Have you looked over this?

[pincpanter]

Wolfgang indeed does not describe in detail how freezing occurs, but from what he says I guess that the observed blocking is longer than the 2 s timeout. The issue in the thread you link is about two NIC belonging to the same subnet. If not, the OS is able to find which is the correct card to send the data.

[wolfkil]

Hi tyk007

thanks for the link. However, I have attached an image in my first post (Network_Settings_NI-MAX.jpg) that shows that we have chosen different subnets for the two cards (172....  and 192...). That is pretty clear that this has to be done. However, there is one statement in the thread you linked which made me curious: "And according to a Microsoft knowledgebase article it is a very bad idea to have more than one default gateway defined in the entire setup." So maybe that we should delete the Gateway entry in the second network (the local one where all the IO-devices are attached to). Do you think that this could be the problem.

Hi Paolo,

 OK to make it a bit more clear (I hope you'll find the time to read all this:-)

We have a main VI which calls the VI were I have shown the block diagram (Network_VI.jpg). Once the problem occurs all NI-Windows which are open (regardless if running or not) show up the message (not reacting). If you kill one of the windows (red cross) all LV windows are closing. To get a clue why and at which action this happens we first programmed a counter indicator in the main VI which definitively always shows the number which is set when the shown Network_VI is called. Thus we implemented into this VI also the "counter" named "Numeric" which is set to various values. In the beginning the settings of the negative values were not implemented and this sub-VI always did show the number "8". So we were not sure if it did finish or if the TCP-Open was the problem (which was the only explanation for me). So we now introduced these two negative settings. However, just yesterday evening and today in the morning we realized that this sub-VI still shows an "8" when LV freezes. So I have to admit that we are again at a point where we are somehow in the dark again. Thus I also attache here an image of the main VI diagram. As I said when the freezing happens we always have seen the "3" in the indicator "loop". Just yesterday we introduced the Boolean indicator "read IU-Laser" and just today the "3.5" setting of the "loop" indicator. Thus we have not seen the freeze with these changes. I will respond to this asap.

Thanks all,

Wolfgang