LabVIEW randomly freezes in while loop

[AJoneja]

You are right RavensFan, I am getting binary data back from the pump. I don't remember the exact reason because I wrote that subVI a while ago but somehow it was easier for me to take the relevant subset of the string I got from the pump and interpret it if I treated it as that weird ASCII string that you are seeing. Most of the time it works perfectly.

I am sure that my device uses 8 bits, no parity. My concern when looking at the probes is that the last command was sent to the pump after the last response was received (probes 8 and 9). So it's not that I'm getting a strange or uninterpretable response from the pump, I'm not getting ANY response.

[AJoneja]

Hi Lynn,

I made the adjustment to the subVI so that the configuration and closing of the port is outside the loop and just the writing and reading is inside (see attached VIs, perhaps double-check to make sure I did it right). I'm going to have to post two replies to include all the files.

I thought that if anything this would at least make my program a bit nicer and cleaner, but I had a very surprising result: this has actually made the loop freeze a lot more frequently! Perhaps 5 times more frequently actually.

I'm actually encouraged that it had some effect because maybe I'm on the right path here, but it doesn't make sense to me that the problem got worse.

Any ideas would be welcome, thanks!

[AJoneja]

Last file

[RavensFan]

Have you tried your VI's on another PC?

What USB/RS-232 converter are you using?  Can you try a different brand?

Perhaps you don't have any issues with your VI, but the problem is with the converter you are using.

[johnsold]

When you have many files to attach, it is best to create a zip file containing all of them and attach that.

I do not see a top level VI - the one which calls all of the subVIs.  For example the connection between the Open and Configure Serial Port VISA.vi and the read and write VIs is not shown.

The Check for Ready SubVI calls Query pump and interpret response.vi which in turn calls Send string to pump and recive status.vi. This subVI configures the port, flushes the buffer, writes and reads, and then closes the port.

So I am not sure what is actully going on.

Lynn

[AJoneja]

Hi guys thanks for your thoughts.

RavensFan, I have tried the program on other PCs but only by running an exe because I only have one LabView license. It does still freeze. I have tried two different serial-to-usb cables, with the same results. The one I typically use has been reliable in many applications before. I will look around for a third, just to leave no stone unturned.

Lynn, sorry I blew it and attached the wrong top VI. I had made a copy to mess around with but attached the original. I am attaching a zip file with all the correct files. For clarity the hierarchy is as follows:

Check for Ready subVI (Copy) --- calls --- Open and Configure Serial port Visa AND Query Pump and Interpret Response subVI (Copy)

Query Pump and Interpret Response subVI (Copy) --- calls --- Write to Pump and Get Response AND Interpret Pump Response

The main VI that calls Check for Ready subVI (Copy) is very large and ugly. Basically every time it sends a command to the pump it then proceeds to use Check for Ready to see when the pump finishes its movement. I don't think the main VI will help but I'm happy to post it.

[johnsold]

OK.  Your last paragraph may contain the clue. The Open and Configure subVI and VISA Close should be outside the loop in the main VI. Because the Check for Ready VI is apparently called multiple times by the main VI, the opening and closing should not be in this subVI.

Lynn

[AJoneja]

Hi guys, it's probably a bit too early to claim victory here, but I've gone a full day without any failures. My port opening/closing was already outside the loop but I moved it outside the subVI entirely into the main VI so it only opens and closes once while the program is running. I also gutted the "Send to pump and receive response" VI, removed all the error handling and error conditions. Not sure what did the trick but it has worked beautifully!

Thanks very much for your time and suggestions, I should have come onto this forum a long time ago...

[AJoneja]

Hi Lynn,

It seems like the freezing issue is happening a lot less frequently, but still occurring. I'm about to give up and "dumb down" this VI to limit its communication with the pump. Before I do, can you take one more look and let me know if there's anything that jumps out at you that I missed here?

I call the subVI "Send string to pump..." once in my main program to configure and open the port. I leave the port open until I exit the main VI. The subVI "Check for Ready" is frequently called to check the status of the pump. It queries the pump every second until it receives a "Ready" status. This in turn calls 3 other subVIs that actually communicate with the pump and interpret the feedback.

Thanks again for your help!

[johnsold]

I notice that you are using a global variable to pass the VISA Resource Name to the Check for Ready VI. You do not write a value to it in the Send string to pump and receive response VI and you do not bring the value out on the connector pane, so how do you get the value into the global? Is it possible that the global is written with an empty or invalid value at some time?

Generally the use of global and local variables in LabVIEW is discouraged because they break the dataflow paradigm and often lead to race conditions.  Use wires if possible.

If for any reason the pump fails to comunicate or does not send the "No Errors, Ready" message, the Check for Ready VI will never terminate.  You might consider adding a timeout or some independent means of stopping it such as a notifier wired to a stop button in the main VI.

Lynn