Max limit to the number of timed loops that can be run at once?

[ygritsenko]

I am currently developing a simulator which requires many pieces of code to execute in parallel.  As a result we have been using timed loops for this purpose.  I haven't counted but there are close to 100 timed loops which end up executing at one time.

A week ago I reached a point where the simulator was working just fine but when I added one more timed loop, it would crash LabVIEW.  When I say crashed LabVIEW, I mean there were no warnings that popped up, and LabVIEW just shut down completely.  Worse yet, LabVIEW doesn't even offer to recover the work when I start it back up again.  However, removing that one extra timed loop allows everyone to work normally again.

I am running LabVIEW 2009 Version 9.0f3 (32-bit).  I have observed this same behavior on two different systems, one which is 3.2GHz Xeon Quad-core  with 2.0 GB of RAM, running Windows XP (32-bit) SP3 and the other is a 3.0 GHz AMD Athlon-64 Dual Core with 4.0 GB of RAM, running Windows 7 Professional (64-bit).  

Because the two systems are fairly different and LabVIEW seems to crash at the same point, I am wondering if anyone has ever noticed such behavior.  I have searched online and can't seem to find any mention of such a limit on timed loops.  

One more thing.  I have made an attempt to replace all the timed loops with while loops but this seems to lead to some sort of starvation because the simulator suddenly becomes choppy, without seeming to consume any more resources than when the timed loops were in place.  So, that does not seem to be an option.

[Yamaeda]

About the choppyness: Did you add a Wait equal to the timed loop-value? Else it'll be choppy since 100 loops tries to run at 100% cpu each ...

How are these loops started/handled? VI server, 1 massive VI, reentrant vi, lots of sub-vi's? It may be a memory limit in LV, it may be a OS limit.

We need some more information on how the system works in order to help determine the reason.

/Y

[ygritsenko]

The choppyness: Yes, when I replaced the timed loops with while loops, I made sure to include Waits and hooked them up the same way I previously had the dt input connected in the timed loops.  What I meant by choppy is better explained if I explain the simulator a bit more.  The simulator involves streams of elements passing from one "piece of equipment" to another.  These pieces of equipment are implemented as numerous queues and timed loops (or while loops).  So, with timed loops, the elements pass fairly smoothly from one piece of equipment to another.  With while loops, the elements will pass from one piece of equipment to another in bursts, which is unrealistic and a problem for the simulator.

The loops are started at first by a top level VI which ends up calling about 10 Sub-VIs that continue to run while the simulator is on.  These Sub-VIs are not reentrant as they are only called once and simply continue to run.  Within these Sub-VIs are anywhere from 2-25 timed loops which also run in parallel.  Some of the lower level VIs are reentrant, however they do not seem to be causing any crashing.

On a basic level each timed loop represents a pump, something that exchanges elements from one queue to another, or a vessel, which can store elements and pass them to another queue.  Although there is a significant amount of other calculations, the only thing the timed loops really share are queues.

I will see if I can create a simple case where the timed loops crash LabVIEW and post it.

Thanks for the response so far.

[Jarrod_S. · Accepted solution]

I believe you are limited to 128 Timed Loops in a system. I couldn't find anything specifying that online, but am pretty sure I've heard it. Also, the Software-Triggered Timing Sources for Timed Loops can only be enumerated from 0-127.

However, it certainly seems like a bug that LabVIEW would crash when approaching this limit rather than throw some meaningful error.

You can do some things to help avoid the choppy behavior of using many parallel normal while loops. Place one or more loops in subVIs and then distribute the Execution Systems for those subVIs. This will provide your application with more threads to execute, which will reduce the choppiness. If you don't do this, your loops will probably all execute in the Standard Execution System, which by default may only have 8 threads at its disposal to share between all the loops.

[ygritsenko]

You got it Jarrod!  Running more than 128 timed loops crashes LabVIEW.  I would think NI would have had that documented somewhere to the public.  Oh well.  I have attached a VI which is running 129 timed loops.  Running it crashes LabVIEW without offering to recover your work upon the next restart.  Remove one loop and run it, it works.

So, Jarrod, are you suggesting that for some of the Sub-VIs, I change their execution system from what it currently is (yep, Standard) to any of the other 5 (user interface, instrument I/O, data acquisition, other 1, and other2), even if I don't necessarily care about how it interacts with I/O or data acquisition, et cetera?

In any case, you have answered my original question.  Thanks very much!

[AmitKaria2k]

The limitation of a timed loop that can be executed in parallel is documented on NI website:

http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/con_timed_structures/