switching between Teleoperated enabled and Wathcdog notfed

[Alan Anderson]

Ether, I'm still not sure you've got an appropriate context for the way you're trying to understand things. A lot of the questions you ask are fine from a procedural point of view, but that's not really relevant to how a LabVIEW programmer should be looking at it.

This is a data flow language. Each function runs as soon as all of its inputs are available, and provides its outputs when it is finished. Wires carry data from one function to another, and it is the flow of data which determines which functions can run next. Groups of functions collected inside a case or while or other block must all finish before the block is satisfied. That's all you need to know in order to understand the 5ms periodic loop example.

[Ether]

I'm still not sure you've got an appropriate context for the way you're trying to understand things. A lot of the questions you ask are fine from a procedural point of view, but that's not really relevant to how a LabVIEW programmer should be looking at it.

If the only goal was learning to be a LabVIEW programmer, I would heartily agree with you. But that's not the only goal for our students. The goal is for them is to learn concepts of multitasking and what's really going on.

This is a data flow language. Each function runs as soon as all of its inputs are available, and provides its outputs when it is finished. Wires carry data from one function to another, and it is the flow of data which determines which functions can run next. Groups of functions collected inside a case or while or other block must all finish before the block is satisfied. That's all you need to know in order to understand the 5ms periodic loop example.

Perhaps, but it's not all you need to know in order to understand even a very simple system. For example, suppose you have a VI that contains within a while loop a 5ms task that takes 1ms to execute and a 50ms task that takes 20ms to execute. Will the 5ms task run smoothly at 200Hz? That absolutely depends on how LabVIEW sets up the RTOS to do multitasking. The student cannot understand why his code doesn't work if he doesn't understand the basics of realtime task management.

Having said that, let it be known that I am an avid reader of your posts and have learned much from them, which I freely share with our programmers. A sincere thank you for you willingness to be so helpful.



~

[Greg McKaskle]

This is a valid lesson in model versus implementation. The model of the LV diagram is the straightforward one given by Alan. The implementation across a wide variety of OSes and architectures will of course vary from the model.

Both POV's are very useful. The simple model view lets you efficiently use the tool to write lots of good code quickly. The underlying knowledge of the RTOS and architectures is useful if you work on the LV team or if you are trying to coax the most from it. Focus too much on the details, and you lose sight of the model.

Greg McKaskle

[Ether]

Originally Posted by Greg McKaskle

Both POV's are very useful. The simple model view lets you efficiently use the tool to write lots of good code quickly. The underlying knowledge of the RTOS and architectures is useful if you work on the LV team or if you are trying to coax the most from it. Focus too much on the details, and you lose sight of the model.

It may not seem like it from my posts, but our programmers are spending about 99% focusing on the "model" and about 1% learning about the "implementation". My emphasis on "implementation" (in my posts) is because I want to "vet" in this forum what I tell the students.

The benefit of an underlying knowledge of what is actually happening "under the hood" goes beyond working on the LV team or coaxing the last ounce of performance. It is also useful in understanding the limitations of the model, for example under what conditions will a 5ms task and a 50ms task "play nice". I want the students to come away from this with at least a hint of understanding of how a single computer can (seemingly) be doing two (or more) things at once.


~

[Greg McKaskle]

Hopping back and forth between threads, I realize I forgot my main point in writing this. Focus too much on the implementation, .... Good engineering involves jumping between simplistic models and imperfect implementations and using measurements to validate results against the predicted results.

It sounds like you are exposing the students to a very good mix. I hope my info is helping. Ideally, I'd have the time to write VIs that measure and demonstrate the behavior.

Greg McKaskle

[Mark McLeod]

Just to round things out for anonymous readers...

On the cRIO, as LabVIEW sets up all these independent tasks and passes them to the VxWorks operating system, each task gets scheduled for execution based on an assigned priority. LabVIEW allows a fixed enumerated set of priorities, however, VxWorks task priorities are 0-255. "normal priority" is the default for our team code in the LabVIEW framework, but that can be changed on a vi basis if you know what you are doing (don't do this at home! ).

Remember too that LabVIEW tasks are not the only things being scheduled for attention by the CPU. There are standard OS functions, a mixture of high and low priority tasks, that also need their time.

Once a task has been started it can execute to completion if it is very short or if the CPU has nothing else to schedule (rare). More often a long task is assigned a fixed slice of time on the CPU, then rotates out to give another task it's share of CPU time, then rotates back in later to get a little more done. That's why multiple tasks appear to the casual observer to run simultaneously, and why we say it's easier to think of them as happening simultaneously. Their execution is actually interleaved with fellow tasks.

This gets complicated by interruptions from higher priority tasks, and lower priority tasks are not completely starved by higher priority tasks. Usually, part of the scheduling algorithm includes how long a low priority task has been shutout of the CPU. If the CPU is full up with non-stop high priority tasks, a low priority task that has been waiting and waiting will eventually be allotted some time-essentially by having it's priority temporarily increased for a short time. There are also cases where a low priority task will lock an important system resource that a higher priority task is next in line for. In that case the low priority task will get it's priority temporarily bumped up to match the high priority task until the system resource is released, then it goes back to lowly priority status.

On multi-core processors (not the cRIO) the tasks get further scheduled across the multiple processors available.

[Ether]

...This gets complicated by interruptions from higher priority tasks, and lower priority tasks are not completely starved by higher priority tasks. Usually, part of the scheduling algorithm includes how long a low priority task has been shutout of the CPU. If the CPU is full up with non-stop high priority tasks, a low priority task that has been waiting and waiting will eventually be allotted some time-essentially by having it's priority temporarily increased for a short time. There are also cases where a low priority task will lock an important system resource that a higher priority task is next in line for. In that case the low priority task will get it's priority temporarily bumped up to match the high priority task until the system resource is released, then it goes back to lowly priority status.

The above are pretty standard available features on any high quality commercial RTOS. But usually the RTOS is extremely flexible and configurable, and the app is responsible for specifying to the RTOS how it wants multitasking handled.

I wonder if what you described above is indeed the way the code generated by LabVIEW sets up the RTOS multitasking, assuming the programmer is using the 2010 FRC LabVIEW framework in the "standard" way (i.e. following the examples of the default code and templates).



~