TCP connection overwrites after loop has been run once

[John32d]

Hello, I spend most of the day yesterday trying to find this bug. My code sends Read command "POLL" to two devices and then reads from the same two devices over TCP connection. The system will be doing it continuously: write write read read. If TCP connection has already been established during one of the iterations of the while loop, the state machine should not be re-establishing connection.

The program works well when I first execute it - it sends two write commands and reads correct data from both devices, but on the next iteration of the loop it somehow overwrites my TCP connections with second TCP connection and reads from the second device twice (albeit, correct data).

I've tried everything I could think of, I would initiate TCP connection inside and outside of the POLL subvi, I used initializer variable, shift registers, tunnels, etc. but still every time, first iteration looks great, second iteration overwrites. This is my main code, and POLL subvi. 

I can only attach pictures, it's unwise to upload my entire code here. 

 

It's a simple state machine and I think it's clear it should only overwrite TCP connection when it's in "Connect" state. I've tried to replace tunnels with shift registers and the result is the same. 

   

[crossrulz]

I'm guessing one of your VIs is non-reentrant, meaning it will overwrite the data each time it is initialized.  It is next to impossible to debug pictures.  There are way too many places I would want to probe to debug this issue.

[John32d]

I think that when LabView calls that subvi, it takes previous values from it and does not reset them to default values. I'm attempting to use shift registers to "store" TCP connection inside that big while loop, is this what people normally do?

[Bob_Schor]

I can only attach pictures, it's unwise to upload my entire code here.    

---

We cannot debug Pictures.  Also, many of us are not running the "latest" version of LabVIEW, so any VIs you attach should be "Save(d) for Previous Version", specifying LabVIEW 2019 or 2021 (2020 is also OK).

It should be easy enough to create one or more sub-VIs (call them "Test XXX") that you "copy and paste" your existing "LabVIEW code shown in the pictures" and enough explanation so that we can see/understand all the steps of your TCP/IP code.

This certainly is do-able.  I wrote a routine a while ago that communicated with up to 24 IP cameras (we actually ran with fewer, as we forgot to calculate the amount of network traffic required for 24 cameras at 30 fps, 640x480 pixels).  The VIs that connected to each camera were essentially identical "clones", each of which handled only a single camera, but was run by a master that managed and synchronized them.

Bob Schor

[crossrulz]

---

@John32d wrote:

I think that when LabView calls that subvi, it takes previous values from it and does not reset them to default values. I'm attempting to use shift registers to "store" TCP connection inside that big while loop, is this what people normally do?

---

Yes.  I find myself more and more keeping state at as high of a level as possible.  This includes connection references and other status you may need to keep track of.  Classes also help keeping this all straight (encapsulation is a wonderful thing).

[altenbach]

We really (really!!) cannot debug pictures with wires flowing in all directions and terminals names that don't hint at the purpose. ("Enum", "Enum 2", "data out 1", "data out 2" etc.

Way too many important things are not visible:

• Since you have a globally initialized feedback node, we would need to know what the default value of the state enum is.
• We cannot tell what the subVI settings are (reentrancy, etc.).
• It seems like a tail-wagging-the-dog kind of thing that the subVI determines the next state and the caller has no control over it except via the order of calling things. Seems fragile.

I'd be happy to have a look once you attach your callerVI and subVI.

[John32d · Accepted solution]

I've decided to flatten the code and try to make sure it works as is. I did end up fixing it, but then got hit with errors 62 Serial port overrun and error 66 network closed connection from TCP read. These errors only appear in debug mode only, when I uncheck yellow light bulb, it runs as expected and I don't understand why. I'll need to learn more about TCP data flow, buffers, timeout, etc. but main functionality is here.    

[Bob_Schor]

Running with Highlight Execution (the "Yellow light bulb") slows things way down, so processes that depend on finishing quickly because more data are arriving will start throwing errors.  When this happens, you need to switch to using Probes (to look at individual values) and judiciously-placed Breakpoints (which can sometimes be placed so you "get the data", then see why "the data are wrong" by following the subsequent steps, perhaps with highlighting back on.

Bob Schor