Serial port (VISA) hang on reentrant VI

[reto]

Hi

I have a program starting several reentrant parallel lops, each of them asking a sensor for data. In the end application, the number of sensors connected will terminate how many instances of the serial interface VI’s to be generated. As synchronization between the different VI’s is important, timed loops are used.

Please find attached a simplified but still not running code.

The loops all start fine and the communication counter counts up. After a while (some tens up to some hundreds of iterations) one or several of the reentrant VI’s hangs. I was able to track the hang to the serial write function. The program hangs also without any sensor attached.

The SW is developed in LabView 2011 and was tested with the same result on:

- Windows XP, MOXA CP-114EL (PCI multi port card)

- Windows 7, 64 bits, 2 “build in” RS232 ports and MOXA CP-132U (PCI multi port card)

Always using 4 serial ports (the end application should be able to run with at least 10 sensors / serial ports).

It would be of great help if somebody could run the attached VI’s on any other PC with different serial ports card installed (MOXA issue?).

Any tips would be of great help.

Reto

[A.E.M]

Hi Reto.

Just found your forum post after I send you an e-mail.

I'm not sure what could cause this behavior, but I have some ideas, that we can discuss and try.
1) It is important in what mode your VISA Read and Write is set to. You can choose between Synchronous and Asynchronous. Since you application is working most of the time, I don't think the problem relates to this, but it is worth to make sure the settings are correct. You can read more about these settings here:
* The Effect of Asynchronous vs Synchronous VISA Write and Read Functions
* What is the difference between doing a VISA read asyncronous vs syncronous?

2) Then I found another forum post, that uses the same application architecture as you are. This customer found out the importance of using the Error Cluster.
* Visa Read Timeout Occurs with multiple Reentrant VI Calls
In general, it is a good idea to use the error cluster. This means we can control what should happen if an error occur, but also, we can control the dataflow in our application.

3) Regarding the bug you mentioned in the e-mail, I think I have found the one you were talking about:
"VISA and GPIB read/write primitives not respecting async flag"
This was a problem in LabVIEW 2010 only. This means that it has been fixed for LabVIEW 2011 and later. So if you are using LabVIEW2010, this could be the root to the problem.

4) Maybe it is a timeout problem: if you ask to read 10 bytes but only receive 5, then the application would appear to hang waiting for the remaining 5 bytes unless you have set timeouts to allow the read to abort. You can for instance check the '# of byte waititng' and only read that amount, or set the timeout flag (or do both).

5) Also, you could try to upgrade to the newest VISA driver: NI-VISA 5.4

6) Other forum posts that might are worth reading throug:

* serial port hang/freeze

* Recording from multiple serial ports causes slowdown

[A.E.M]

Hi again Reto.


I have now a system with 5 com ports. I make my own example to verify that everything works, and then I tested your code.

I ran my own example without any problems, for 20.000 iterations. I then ran your example, and saw the starvation you have described. I then took a closer look at your code, and did some modifications.
1) In stead of calling the dynamic VIs using Open VI Reference, I used Start Asynchronous Call as also described in the detailed help for the Open VI Reference.
2) You are using the Timed Loop in your Serial_Main VI. I would not recommend doing so. The Timed Loop is a single-threaded structure meaning that it does not allow code within the structure to execute in parallel. The timed Loop has a preemptive nature and can monopolize resources of a system. The priority level of the Timed Loop is fixed between time critical and high priority and is usually used when programming on a Real-Time Operating System (but it can though still be used when programming on Windows-based targets). If you want to use the Timed Loop in a Windows application it might, if not handled in a manner with respect to the amount of available resources in the system, increase the likelihood of unpredictable behavior. If you have multiple Timed Loops running simultaneously in your application it may, depending on the amount of Timed Loops used in conjunction to the system resources, enter a deadlock where no time is scheduled to some of your loops, because the processor is occupied and it will seem like part of your application is not executing. It will from a user perspective appear as the application is hanging and not responding properly to various actions.
I therefore changed this loop to a normal While-loop.

With these two modifications, it seems like your code is running without any problems. I have attached the code, I'm looking forward to hear the result from a test on your system.