Multi-time triggered systems

[marccenter]

Dear Labview forum,
Is there a good powerpoint document showing how to set up multiple time-tasking subsystems? I think we may want to sample our actuators at 5 msec /10 msec rate and then divide by four /two; have the main loop run at about 50 hertz to match the 20 hertz PWM rate (different from about 40 hertz of IFI system); and maybe even hae a slow 100 hertz loop for discrete outputs.

I believe this kind of template needs to be developed in order to facilitate some level of commonality among all the teams.

[Philbot]

I haven't seen a specific document dealing with multi-timed threads, but that is probably because LabVIEW is inherently multi-threaded.

Put three loops on a page and they run concurently.
Want defined timing? put a periodic timer in each loop so they regulate their own execution.

See my footer, watch the videos.

I'm sure once teams start re-implementing their robots all sorts of "templates" will come out of the woodwork.

Phil.

[Kevin Sevcik]

*cough*
I hope it's not out of place for a non-beta tester to offer advice, but if we're working with Labview Realtime on the cRIO, then using plain loop structures with periodic timers is most definitely not what you want to do. You want to be using the Timed-Loop structure. It ties in more directly with the RT scheduler and lets you prioritize loops, along with telling you if you're missing loops because you're trying to run too fast, and a host of other goodies. A plain loop with a periodic timer will be prone to silently missing loops, starting loops late, and all sorts of other things.

So if you want deterministic timed loops (and why are you using RT if you don't?) then you should be looking at the Timed-Loop structure.

[Greg McKaskle]

*cough*
So if you want deterministic timed loops (and why are you using RT if you don't?) then you should be looking at the Timed-Loop structure.

LV realtime does indeed have both types of loops. So automatically replacing all loops with timed loops may at first seem like a good thing to do. In practice, I use both. For one thing, using high priority timed loops to consume the processor resources is more prone to starving useful BG tasks such as networking, debugging, etc.

I've yet to develop my roadmap of exactly when to use the realtime fifos instead of locals, or timed loops instead of regular ones. The RT guys will pitch theirs, and yet LV is a portable language and the other stuff generally works well too. I'm sure there are timing deadlines where each of the RT features are absolutely necessary, but when beginning, KISS, and regular loops with timers have proven to work just fine to this point. If I later want to lower jitter at the expense of shoving it elsewhere, then I can replace with the timed loop and dole out my priorities.

Greg McKaskle

[Philbot]

*cough*
I hope it's not out of place for a non-beta tester to offer advice.

Oh, Please

Seriously but... that's just the sort of info. that beta-testers and non-beta testers alike need.

I knew about the two different loop delays (Wait & Wait until next multiple) and I figured these would be enough... but having something more precise will be very handy.

(Note: could anyone who had downloaded the trial Labview could try these out? Not sure)

Ive noticed that the FRC I/O libraries seem to facillitate oversampling analog inputs automatically, so it may not be necessary to do precise timing just for data averaging. Also, there is a built in Gyro vi, so that may also remove the worst of the critical timing (integration) needs.... Time will tell.

[Danny Diaz (NI)]

I've yet to develop my roadmap of exactly when to use the realtime fifos instead of locals

The Real-Time FIFO should be used when you have a deterministic loop communicating with non-deterministic loops. The access to the Real-Time FIFO is atomic (which makes it deterministic), and there are no worries about synchronization or caching of values like you would with a local variable (you wouldn't want to be reading the value at the same time someone else was modifying it - to prevent this you'd need synchronization, which is definitely NOT deterministic).

or timed loops instead of regular ones

Timed loops should be used when you want a guaranteed deterministic scheduled or periodic "firing" of the loop. Realize that when you use a timed loop, the timed loop runs in a TIME_CRITICAL thread priority context, which definitely starves background threads in the system (like networking, et. al.). If your timed loop takes up the entire time, or frequently runs late, then you also end up with starvation of background threads. To prevent starvation when using timed loops, you want to make sure the period of the loop is ample enough to provide time for other threads to run in the "down-time" between when the loop iteration ends and the next iteration of the loop is scheduled.

-Danny

[Kevin Sevcik]

The Timed Loop is available in (I think) all Labview versions, though in the vanilla windows install and many other environments, it won't have the same special, deterministic properties as in the Labview RT.

As Greg notes, it's not necessary for many functions, just where you need things to happen at very precise intervals. Specifically, where you need process data and update outputs and states at very specific intervals. As you've noted, you can set up DAQ tasks to be hardware timed, background tasks. So processing gyro data to filter and integrate it doesn't necessarily have to be deterministic.

If you set up your data processing to handle multiple samples at a time, then feeding it 1 sample per run and running it at 1000 times per second should be equivalent to feeding it 20 samples and running at 50Hz. That is, the output from a single 20 sample run should be identical to the output from 20 one sample runs, provided the data inputs are identical. And thus, your data processing could chew 20 samples in most runs, but occasionally make way for higher priority tasks and end up having to chew 40 samples occasionally or some such.

So there's obviously going to be some amount of work that can happen in the background and at lower priorities, but I think timed loops are still going to be useful.