TPC-2006 Labview vi execution slows, then stops, forcing power cycle

[Jeff in Pleasanton]

I have a user interface vi comprising 4 while loops, each with a 100 ms "wait till next ms" timer.  There is a TCP/IP Tx loop, TCP/IP Rx loop, a loop to build the 2 bytes to be sent, and a loop to decode the 2 bytes received.

I added loop counters as a debug tool.  All 4 hum along more-or-less in sync for about 10 minutes, but then they all start  s l o w i n g  down, and while I watched, all 4 quit incrementing.  When this happens the TPC-2006 is utterly locked up, forcing a power cycle to recover.

I've attached the vi in hopes that somebody will see my error, or maybe there's a memory leak in the labview executable?

[GuenterMueller]

Hello Jeff.

As far as I see in an execution without a "TCP partner" on my PC there is no memory problem in your code.

But somehow your codes succeeds in breaking the entire execution system. There is no reason for the UI loops to stop execution and as I take from your words - they do.

Maybe you would should rearrange the code and do not execute TCP Read and TCP Write in parallel loops. Usually, "full duplex TCP" should work, but I don't see another chance for your code to stop. This would be my approach to find out the reason for the hang-up.

Hope this helps, Guenter

[Jarrod_S.]

I also don't see anything directly that would cause the code to slow down over time. There are a couple things I might recommend, but I'm hesitant because the code looks so meticulously and exquisitely written! 🙂

There are a few places in your application where you use a local variable when a direct wire connection is possible. Direct wire connections are always preferable if possibe. Granted, this would only make a small difference in memory usage and performance and should NOT cause your code to slow down. For instance, in the second loop you write a value to PDA Lifter and then read the PDA Lifter value from a local variable. A direct wire connection here would be preferable. Also, in the third loop you are writing all your values to the LEDs (TestLED, HighLED, etc) using local variables. You could easily perform your logic inside the case structure that decides what values to send to the indicators, but then actually use direct terminal connections for the LEDs outside the case structure instead of using local variables.

Finally, if you are using the LabVIEW 8.0 or 8.0.1 PDA module, you might consider transitioning the second loop into an event structure that would only run if a user clicks on one of the buttons. That would save one of the loops from constantly polling six buttons and checking to see if a new value was registered. PDA applications are multi-tasked, not multi-threaded, so it would help to have less loops running concurrently.

I also agree with trying to put all the TCP communication in one loop. It obviously wouldn't make sense to have a TCP Write in the same loop as a TCP Read set to have infinite timeout, since that would slow down the write process if the 2 bytes weren't available at the port to read, but you could set a timeout of 0 or 100ms and then probe the error output to see if a timeout occured.

I've been trying to reproduce the slowdown on my computer with your code. I closed the loop by setting the target IP to localhost and setting the server and client loops to both use port 5555. This sets the app to just talk to itself. It's running fine with no errors, and so far on the PocketPC emulator I see no slowdown. This might be strictly related to TPC-2006 devices.