LabVIEW framework realtime architecture

[Ether]

Hello LabVIEW gurus,

Is there a document somewhere which gives a short overview of the realtime architecture of the framework provided in the 2010 FIRST LabVIEW?

I am familiar with event-driven embedded realtime software design, but a complete novice to LabVIEW. So I'm looking for something written for a such a target audience.

Thank you.


~

[Ziaholic]

The best resource I have found is the Labview Mastery Tipjar.

There are 18 videos about the 2009 code here ... http://www.lvmastery.com/tipjar

... and there are a half-dozen new ones, for the 2010 framework here ...

http://frcmastery.com/



The '09 videos, while based on last year's framework, are still VERY insightful into things like state machines, global variables, using typedefs etc. I've been through all of them, and still go back and refer to them on occasion. They are also active on this forum, so questions/comments are often quickly answered.

G/L!

[Greg McKaskle]

In reality, the realtime tasks such as producing a PWM, decoding pulses for a quadrature signal, accumulating values from a gyro or accelerometer, etc. are being done by the FPGA. The RIO architecture is a hybrid, allowing you to assign FPGA resources to time critical or high performance tasks, and the VxWorks/PPC resources to tasks which have needs a few orders of magnitude less demanding, and to higher order tasks of coordinating the realtime resources.

The LV architecture consists of several initial loops running in parallel at various rates. They are not highly synchronized or organized, and in reality, this is not a very good realtime architecture, but it is one that is hopefully understandable by many and real time enough for the robotics tasks undertaken by FRC.

Probably the most important input to deal with is the joystick and DS I/O. They are transmitted at 50Hz and are already delayed and jittered by various networking tasks. The UDP traffic is handled by a cRIO task which is involved in watchdog safety, and is therefore closed and shared across all three languages. The task decodes the UDP, stores the values so they can be retrieved later, and notifies the language framework code that data is available.

For LV, this work is done within the Start Communications VI. It allocates an occurrence primitive, gives it to the task, and enters a loop that waits for the occurrence to be set. Each time the occurrence is set, LV retrieves the data, stores it in various LV locations for WPI access, and fires another occurrence which triggers the Get Competition Mode to run one cycle. This loop invokes the appropriate user code callback for auto, tele, or disabled.

Occurrences are a lightweight scheduling mechanism not unlike a dataless event. LV code that is waiting for data or for an occurrence are taken out of the LV scheduling queue. When all data and/or occurrence needs are met, the code is inserted into the appropriate scheduling queue based on its priority and its execution system assignment. Once inside the scheduling system, various system threads will claim and execute the code until it completes, blocks for an occurrence or system resource, or decides to cooperatively round robin itself.

There are several template loops laying about for vision processing or other tasks that do not want to have the same 50Hz timing of the DS loop. These loops could be turned into what LV refers to as timed loops where a particular timing source, deadline, and priority are designated. Those timed loops would then probably use RT FIFOs to have lighter weight and more deterministic communication with each other. Instead, the loops are simple user level loops, the communications are fully protected but unsynchronized global variables. The RT elements in LV were not removed from the palette, but the template doesn't use them.

I think you'll find the other languages to have the identical communications task, a similar mechanism for notification, similar callbacks, and the ability to run parallel tasks with loose communication. Again, the teams can make use of more deterministic elements if/when they need to for a particular sensor or control task.

Did that answer your questions? If not, dig deeper. I'm not an RT expert, but I'm more than happy to explain what I know and consult with the experts when I don't.

Greg McKaskle