Intra-Loop Timing Advice

[Ziaholic]

I haven't had the time to play around with some of my timing ideas ... this being the final week and all.

I'd like to ask some of the more advanced Labview developers and cRIO gurus for some advice and/or rules-of-thumb regarding the elapsed time for some common tasks.

Our team's software has most of it's "decision making" in the teleop/auton enabled VI's, running at the frequency of the DS packets ... 20 msec/cycle.

Underneath all that "main-while-loop" stuff, we've got our other primaryVI's ...

One reads a command global and sets the drive-motor speeds.
One reads all the nav sensors (accel's, gyro, encoders) and writes to a global.
One reads a command global and sets the camera-gimbal servos
One is for Vision

In the teleop/auton modes, we look at the Nav data and the joystick inputs, and set the commands to the motor-globals.

In each of my free-running VI's (other than vision), I have a WAIT = 10 msec so that they'll run at most twice for each DS-cycle. But I'd like to adjust that arbitrary number with one that is based on the expected response times for these sorts of actions.

I wish I had the time during our recent build-sessions to play around with some timers and find out for myself, but alas, today my hands were on power tools much more than the keyboard

Do y'all put these WAIT's into your standard parallel VI's? or do you let them free-run as fast as they can? If/when you let them free-run, what sorts of elapsed times would you expect from them?

Thanks!

[Greg McKaskle]

Free running literally means take all available resources, pretty much maxing out the CPU. This won't necessarily do harm unless you have some lower priority tasks which may now become starved. It will also add lag to other tasks since at any given point in time, the CPU will have to finish the excess loops before it gets to the task that waited in line.

Moral: Almost always delay your loops in some way. The ideal way is to make them run when new data arrives or is needed. In some cases this is more easily done using a time schedule, but that has its own set of tradeoffs.

At this point, I wouldn't recommend it unless you have an issue. But when you have time, read up on the notification mechanisms, and especially the FIFO.

Greg McKaskle

[Merle]

Originally Posted by Greg McKaskle

But when you have time, read up on the notification mechanisms, and especially the FIFO.

Greg McKaskle

Where would one read up on these topics?

[Luke Pike]

The LabVIEW Forums are a good place.

I like using Queues to control my sub-loops. Queues are FIFO arrays; I enqueue a command from teleop or autonomous and dequeue from the loop that handles the commands. If you don't specify a timeout, the dequeue vi will wait until a command gets enqueued, effectively pausing the loop until it's needed. As a bonus, if the loop takes a long time to finish an iteration, other commands will still be added to the queue and processed in the order they were added.