Better way to change rate of Timed Loop?

[AristosQueue (NI)]

I heard somewhere -- and this is hearsay that might be wrong -- that on RT, the Timed Loops themselves allocate a CPU core entirely for themselves in order to maintain determinism. If you have more loops than cores, you may get stuck. Again, not sure if that's true or not, just something I heard.

[seanohue]

Well, given that I've only got 4 cores, that may be a possiblity. The way I've been designing my Actors that rely on a periodic rate has always been to inherit from a timed loop. Before though, BillMe and myself were using the Wait (ms) function to do timing which I thought would be equivalent to using a while loop where the CPU is sitting and waiting for the true condition. Does a notifier do the same thing? I would hope the notifier would put the Timed Loop thread to sleep until the notifier timer expires, but I rarely use the notifier and have little understanding of the way LabVIEW handles threading. I'm thinking the while loop is what makes the LabVIEW assign a core to a timed loop.

I will start making periodic requests from my root actor to my children instead of having my children periodically send to my root.

[AristosQueue (NI)]

There is a difference between a While Loop (even one containing a Wait Ms node) and a Timed Loop. The Wait Ms node means "wait this long", but it makes no promises about not waiting longer depending upon thread availablilty. The Timed Loop is deterministic on RT and tries as hard as possible to be on Windows. I don't know all the magic that goes on to make this happen. I do know that they are NOTHING alike in the code that they generate and the impact that they have. Timed Loops change the execution of all other VIs in the system in order to meet their timing constraints.

[MattP]

AristosQueue wrote:

I heard somewhere -- and this is hearsay that might be wrong -- that on RT, the Timed Loops themselves allocate a CPU core entirely for themselves in order to maintain determinism. If you have more loops than cores, you may get stuck. Again, not sure if that's true or not, just something I heard.

Close!

On RT (and on Windows), a Timed Loop node will prompt LabVIEW to create a dedicated thread for that Timed Loop.  Each new Timed Loop you drop, a new thread gets created. This is separate and apart from the normal thread pools that LabVIEW uses to schedule code onto threads, which by default scale depending on how many cores are in the system.  The Timed Loop threads have a higher priority than almost any user-created code in LabVIEW (such as regular While Loops).*

You can optionally assign a Timed Loop to run on a particular CPU core, and on RT you can optionally also restrict other LabVIEW threads from running on that core.

We recommend having no more Timed Loops than cores, simply because you get the best determinism and the fewest cases of priority inversions this way.  The phrase "if everything is important, nothing is important" applies here.  It also helps promote separation of time-critical operations that need to be in a Timed Loop and secondary operations (file IO, network comm, etc) that should be relegated to regular While Loops and processed as time allows.

Note that I'm talking about the blue Timed Loop node in the Structures palette, not an Actor named Timed Loop.

*Timed Loops and the scheduler that controls them run at a priority level just below Time Critical.  By almost any, I mean that a subVI with execution priority as set in the VI Properties dialog box of Time Critical will have higher priority in the scheduler than Timed Loops, but any other code will be considered lower priority.  It is an incredibly bad idea to mix Time Critical priority subVIs with Timed Loops, since this opens the possibility of spectacular race conditions.

[BillMe]

The "Timed Loop" actor seanohue and I are using I found in one of the AF resources and simply "stole" it since it works for my purposes. The loop itself is not a "Timed Structure". It's a simple While loop with, originally, a "Wait on Next Ms" timer in it. seanohue  and I changed that to a Wait on Notifier per drdjpowell's suggestion so we could pass in a new loop rate (Wait on Notifier timeout value) while the app was running. Does the notifier cause a higher priority thread as you describe to be created?

For my application, I don't care about determinism as my Wait on Notifier timeout is never smaller than 60ms and reasonable jitter is acceptable. seanohue may not have that luxury.

[AristosQueue (NI)]

The Timed Loop Actor DOES have an actual Timed Loop when deployed on RT. The Conditional Disable Structure flips over to the Timed Loop on the RT systems.

[BillMe]

Must be a slightly different "model" of Timed Loop, the one I got from one of the examples doesn't have a Conditional Disable structure. But I can easily imagine what it looks like.

[AristosQueue (NI)]

The one that ships with LV since LV 2012 does have the conditional disable. If you got it from somewhere else (i.e. the forums), it might not. Thus my confusion.

[BillMe]

Okay, I looked and looked but found nary a Timed Loop Actor in my LV2014 installation hierarchy. Can you clue me in on where to find it? Then I won't bother you anymore.

[seanohue]

Timed Loop Actor is located in \LabVIEW 2014\ProjectTemplates\Source\Core\Feedback Evaporative Cooler

Yes, definitely some confusion between BillMe, myself, and AQ on what Timed Loop we were referring to. We were working off the example from LV2012.