TCP - Multiple Connections Causing Lock-Ups - 2018

[DailyDose]

Scenario:

I've got a board with two micros, each programmed to act as a server.  Each with a separate IP Address (and different Port just to for kicks and giggles).  Both on the same subnet.  This has been confirmed repeatedly.  My LabVIEW 2018 program is designed to communicate to both.  I have 3 loops running.  One loop runs the event structure.  The other two run the the connect/read/write TCP connections to the respective micro.  I use two functional globals to store and handle the respective references.  So they're separate VIs, however, I do not fully understand if a call to a TCP connect and what not act like typical VIs where they can only be opened once and if anything else wants to use it must wait until it's done.  Even if this is the case, I shouldn't be getting the issues I'm getting I'd think.

Problem: 

A TCP connection is successfully made to one of the micros and continues on with expected behavior.  But the second loop is still trying to make connection.  Eventually, the second loop makes the connection and I instantly lose connection in the first loop.  But then... EVERYTHING FREEZES!  Event structure comes to a complete stop.  I have it set to timeout at 100ms since I need to calculations.  The timeout also sends a data request to the TCP connections via a queue system (there's logic behind it).  If I shutdown one of the loops from the get-go, the single TCP connection has no issue and there's no freeze up.  I've also been able to switch between the two for this exercise.  So I've technically proven my code that the master/slave queue system is working and I request data and receive it.  But not when both are running (and yes, I'm using two different queues).

I know there's a lot of info and I'm sure someone is wanting VIs.  I would ask first if I'm not using the TCP VIs correctly yet before anyone asks to debug.  Do I need to make a single TCP Handling VI that switches between the two references?  Or is it just not possible to make two connections?

[Mark_Yedinak]

No, you do not need to make a single VI to process both connections. You are doing something wrong in your code. I have applications that have well over 100 next connections open and functional at the same time. I wonder why you are functional globals for your references. A better solution would be to have your VI handle the open/do stuff/close and keep track of its TCP reference.

[DailyDose]

---

@Mark_Yedinak wrote:

No, you do not need to make a single VI to process both connections. You are doing something wrong in your code. I have applications that have well over 100 next connections open and functional at the same time. I wonder why you are functional globals for your references. A better solution would be to have your VI handle the open/do stuff/close and keep track of its TCP reference.

---

I was pretty confident I could make as many TCP connections as I wanted.  But in parallel?

As for the FGVs, I learned a long time ago this was the best way to handle actions for specific references.  One of the biggest reasons being keeping your main VI nice and clean and legible.  Granted, I'm not doing anything to these references outside of their respective loop, so the need to be global is non-existent.  But it's a habit and a good practice and no harm is done.  Completes the task.

"Something wrong in your code."  I made a very basic Test VI in LabVIEW 2015 that just straight up attempts to make two different TCP connections in parallel and then request data after it accomplishes this and I see the exact same results.  One loop will establish connection and then process while the other just hangs up.  If I close down the first loop, the second loop will happily connect and move on.  Do I need to be encompassing all loops inside a single loop?  Perhaps labview and it's data flow paradigm is just completely ignoring the other loops?

[Mark_Yedinak]

A much better design is that each component of your system you only have the data it needs/uses. Putting things in FGV just because someone said it is a good practice opens your application up to bugs since ANY part of your system can access that data.

In terms of running TCP in parallel, yes it is possible. I have applications that use a TCP messaging system which communicates with hundreds of clients/tasks, all running in parallel.

If you have this simple VI that demonstrates the issue, please post it. Otherwise no one can really identify what you issue is.

[DailyDose]

Attached is a VI that's pretty spot on to how the architecture is designed.  The Micros don't send any data unless requested.

[DailyDose]

Updated VI... Wanted to make sure I put the Connected Local Variable.  Does not Write if Not Connected

[DailyDose]

Also I should probably note that my connection is through a network switch that isn't managed.  This wouldn't be an issue, would it?  I wouldn't think it would.

[Mark_Yedinak]

Do your micros send some data after the initial connection? Immediately after opening the connection you attempt to read 16 bytes.

Also, your Connect action should always close the connection. As written you have a memory leak.

The IP addresses are not valid. This may be part of your issue. Also, are you running this with execution highlighting enabled?

I suspect that your issue is that you are not communicating the correct messages and format to your microprocessors. Attached is a simple test server VI that works as I would expect for your application.

[DailyDose]

---

@Mark_Yedinak wrote:

Do your micros send some data after the initial connection? Immediately after opening the connection you attempt to read 16 bytes.

Also, your Connect action should always close the connection. As written you have a memory leak.

The IP addresses are not valid. This may be part of your issue. Also, are you running this with execution highlighting enabled?

---

Micros send "Hello Client\n00" in return.

I close the connection in the Close Case.  But when I have to do an abort, I generally close LabVIEW and reopen to avoid memory leaks.  In the case scenario of a dropped connection, I do close the connection.  Didn't add that to architecture I see.

Ah, Ha.  This was quickly thrown together architecture explaining what I'm doing.  The IP Addresses in that VI is definitely wrong. Looks like I fat fingered 3 instead of "dot."  Rest assured, main code IP are correct.

Highlight execution shows one connect and then the other interrupt it.

[RavensFan]

For me, both of your loops seem to be working.  I did see instances where the messages at the server screen seem to be scrambled saying "TAGET DA", for example.

I suggest using some termination characters so that your server and client know when messages end.

Also, move the terminal for the Stop button into the event case so that when it is read, the latch action will allow it to snap back.