labview randomly freezes in while loop

[AJoneja]

I know it's bad practice to overuse variables, and as I learn more about LabView I'm figuring out how to avoid them. I have to admit that if I posted the whole main VI here you would probably fall off your chair in horror. I wanted to pass the VISA Resource name to the global VI so I could call it in my subVIs...and since they are in various locations all over the main VI I thought it would get messy if tried to wire it everywhere. Ideally the user would never change the COM port, but it is a possibility. So in my main VI I have a loop that runs every 100ms that passes the value from the VISA resource name to the global variable. Ugly.

I would love to add a timeout that would terminate the Check for Ready subVI. Unfortunately I haven't come up with any good ways to do it. Since Check for Ready gets stuck in a while loop that never completes, it seems that any method I try to use to stop Check for Ready would wait for it to at least finish the current loop it is in, which it never does...

[johnsold]

Here is one way to use a Notifier to stop the Check for Ready VI.  I did not wire the error terminals in this quick and dirty example. In addition to the stop notification, monitoring for the error which will occur if the notifier is released can also be used to stop the loop.

The Additions to Main VI shows what would be added to the Main VI to provide the stop notification.  You would not use this as a subVI but add teh code to the existing Main VI except for the while loop.  You would use the while loop in the original Main VI.

Lynn

[AJoneja]

Hi Lynn,

Thanks very much for the suggestion. I am reading a bit about notifiers today and will try to implement this tomorrow when I have my Labview computer. I'll let you know how it goes!

[AJoneja]

Hi Lynn,

After messing around with it a bit, I thought this method was surely going to work. As you said, rather than actually using the Stop button I put in a timer so that the notifier is released and the loop should stop after a given amount of time. Unfortunately I still have the same problem.

Does the "Additions to Main VI" section have to be in the Main VI or can it be a loop that runs in parallel to the Check for Ready loop in the subVI (see attached)? I made a couple modifications but kept the general idea. I added the Boolean global variable so I can see on the main VI if the time-out takes effect when running as an exe. Very annoyingly, this freeze still seems to be more frequent when running the exe, and for whatever reason the debugging application function isn't cooperating with me - I did Enable Debugging when compiling but viewing the block diagram isn't an option. Some other people on this forum have had the same issue.

Right now I'm running it over and over in LabView environment to see if I can get it to freeze again so I can probe and see where it went wrong, I will keep you posted.

[Tim-C]

If you increase the wait until time on the main loop, does that lower the frequency of the freezing?

[AJoneja]

Hi Tim,

I have tried increasing the wait time, hoping that it would freeze less frequently, but it doesn't seem to have much effect. It's certainly not linear. I suppose if I was somehow overwhelming the serial port or filling the buffer, it would have an effect here.

Strangely, if I unplug the serial-to-usb cable while the program is running, Lynn's suggestion of using the notifiers works. The software tries to communicate with the pump, gives up after the specified time-out, and moves on. But the issue of freezing randomly when querying the pump still exists. I really wish I could somehow reproduce this failure on command, but it is very unpredictable.

[AJoneja]

Hi guys,

I got this to freeze in LabView so I was able to probe a bit. In case this information gives you any ideas, that would be great. If not, I will find another way to do this without querying the pump, because this has dragged on too long! Thanks to everyone for their efforts.

The "timing loop" had reached 1000 iterations and returned a "True". It executed the True Case structure and exited the loop.

The "query loop" had only reached 13 iterations. The "Timed out?" output of the Wait on Notification was still True. I dug down into the subVIs and it looks like once again it was stuck between the Write VISA and Read VISA of the subVI "Write to Pump and get response".

This was confirmed when I unplugged the USB-to-serial and immediately got an error "Error 1073807360 at VISA Read....Unknown System Error". If I click continue, the "query loop" iterates and it switches to the same error but for VISA Write. If I keep clicking continue, the error just bounces back and forth between the Read and Write while the loop iterates. If I plug the serial-to-USB back in, it does not recover, I keep getting the error (maybe I have to configure and open the port again). For some reason the iteration of the query loop increases until it reaches about 30, and then it goes back to 1. The iteration count of the timing loop just continues to increase.

Is this starting to look like a hardware problem? I have seen the same behavior on at least 1 other laptop (different make/model/everything), but I did not test it as extensively as I am doing now.

[Tim-C]

Yeah, it sounds like you are not getting your read back from the serial connection. Are you able to get a reading from MAX test panels?

[AJoneja]

I haven't tested it with MAX test panels, but this code (and the hardware) works 99% of the time. In this case I know that I did get a read from the serial connection 12 times before it froze up on the 13th loop. And this subVI was called perhaps 50 times by the main VI before it reached this particular instance where it froze.

[Tim-C]

Sure thing. It's just if you are wondering if it is a hardware problem, MAX is the place to test that because you don't have to factor in errors in the code. I would test there if you can test at the same level of stress on the hardware so that you can see if it is a hardware issue. Otherwise, I would say it's a race condition or the reference already closed out or something along those lines.

Also, I understand your frustration with the issue. I hope you can at least find a workaround.