switching between Teleoperated enabled and Wathcdog notfed

[Tom Line]

The key here is to understand that both the wait task and the other code in the .vi run in parallel.

If your code took 5 ms to run, and you put a 5 ms wait timer in, absolutely nothing regarding program timing would change. The actual code would finish running just as the wait timer expired and would start running the loop again.

If your code takes longer than 5 ms to run, say 7 ms, then your code would finish and start over again.

The "wait" function does not mean finish the code then wait. It means to wait 5ms before asking that code to run again - from the time you last asked it to start running.

[Mark McLeod]

Originally Posted by Ether

So it looks like this (assuming the 5ms task is the only task in the system):

Your error is that you then go on to describe several tasks .

I think the main hangup is that EVERYTHING is a task to LabVIEW.

P.S. Trick question: How many tasks do you see in the attached?
I see three. P.S. My mistake, four.

[Ether]

Originally Posted by Tom Line

The "wait" function does not mean finish the code then wait. It means to wait 5ms before asking that code to run again - from the time you last asked it to start running.

Hi Tom,

A few questions:

1) The "wait" function mentioned above, and the "Timer vi" mentioned by Mark... are you both referring to the same thing? The thing with the icon that looks like a clock?

2) In my post to which you replied, was my conclusion correct that the periodic task should be coded as a one-shot, and not wrapped in an infinite loop?

and finally

3) Are you sure that it means to wait 5ms from the time you last asked it to start running? Or is it 5ms from whatever time it is when the CPU encounters the request to re-schedule?


~

[Ether]

Originally Posted by Mark McLeod

Your error is that you then go on to describe several tasks .

In my previous post I was describing a hypothetical simple example with only one task in the system: a 5ms task. I was not referencing your diagram (see below).

i.e. "assuming the 5ms task is the only task in the system" and "the CPU goes idle" etc.

By using an extremely simple example I was hoping to be able to frame clear and unambiguous questions. I need a rock to stand on. Once I've got that rock to stand on, I think I can envision how it works in a multi-task environment.

P.S. Trick question: How many tasks do you see in the attached?
I see three.

Trickier than you might imagine. I don't know. I am not a LabVIEW programmer. I don't understand LabVIEW diagrams. I am trying to understand the real-time aspects of how LabVIEW works by referring to my embedded programming experience with assembly language and C, so I can explain the real-time aspects of LabVIEW to the programmers on our team who have never done real-time programming before. My programmers don't really understand what the Timer vi does, and I want to explain it to them. This is such a great opportunity for them to start to understand what real-time control and multitasking is about and how it works.

Thanks for dialoging with me. If I haven't worn out my welcome I would appreciate it if you could hang in here for just a bit longer. I sense that "aha" moment is imminent...

~

[Ether]

Originally Posted by Mark McLeod

The parallelism of the two tasks within the loop task has to be taken into account:

• 5ms timer
• 1ms task

The loop task starts
The timer task starts and goes away for 5ms
The 1ms task starts and finishes, then it too goes away
The loop task rests as all it's internal tasks are not yet satisfied, but it has nothing to do
The CPU wakes up the loop task when the 5ms timer expires
The loop task sees that all it's tasks are accomplished and moves on

The timer task only stops itself. It doesn't stop tasks around it. It really sets a timer interrupt.
If the Timer task expires and the loop task is still active because of other independent tasks within it the CPU doesn't have to wake it up and it doesn't get scheduled.

I've been reading and re-reading the above post and I think I may have had an epiphany.

Is this any closer to the truth:

- the 5ms periodic vi has two parallel "tasks" in it: a 5ms timer, and some code that takes 1ms to execute

- this 5ms periodic vi gets called once to kick-start it

- the first time the 5ms periodic vi gets called, the CPU encounters the 5ms timer task and executes that... which basically just sets a timer interrupt to occur 5ms in the future.

- the CPU comes back and starts executing the 1ms "task", and finishes it.

- since the 5ms timer task hasn't finished yet, the 5ms periodic vi can't "finish". The CPU goes and does something else.

- when the 5ms interrupt occurs, this basically completes the 5ms timer "task", so the periodic vi is now "finished"

- in this scenario, it is required to make the periodic vi loop back and start again

Is the above even remotely correct?


~

[Mark McLeod]

Originally Posted by Ether

In my previous post I was describing a hypothetical simple example with only one task in the system: a 5ms task. I was not referencing your diagram (see below).

i.e. "assuming the 5ms task is the only task in the system" and "the CPU goes idle" etc.

By using an extremely simple example I was hoping to be able to frame clear and unambiguous questions. I need a rock to stand on. Once I've got that rock to stand on, I think I can envision how it works in a multi-task environment.

I meant what I said
I was not referencing my example, I was referencing your example.
Your example, as stated, has more than a single task in it. I think that's where the blind spot lays.

Here's the simplest example of a task you can have in LabVIEW:

• A completely blank vi

Next, add your Timer and you have two tasks:

• A framing vi (formerly blank)
  • A Timer task (sets a timer interrupt and goes away. When the interrupt prods the CPU it wakes up the framing vi)

The next level of complexity has three tasks:

• A framing vi
  • A Timer task (same as above)
  • Any other action you care to take (completely independent of Timer)

My latest example really has four tasks:

• A framing vi
  • An infinite While loop
    • A Timer task (the CPU will wake up the enclosing While loop)
    • A 1ms Task (completely independent of Timer)

[Mark McLeod]

I'm playing catchup with crossing posts, but yes I think you've got it.

The only change I'd make to your thinking is the line:

- the CPU comes back and starts executing the 1ms "task", and finishes it.

Think of both the 5ms Timer and the 1ms Task as starting simultaneously.
There is no rule that says one must start before the other, or which starts first.

Originally Posted by Ether

I've been reading and re-reading the above post and I think I may have had an epiphany.

Is this any closer to the truth:

- the 5ms periodic vi has two parallel "tasks" in it: a 5ms timer, and some code that takes 1ms to execute

- this 5ms periodic vi gets called once to kick-start it

- the first time the 5ms periodic vi gets called, the CPU encounters the 5ms timer task and executes that... which basically just sets a timer interrupt to occur 5ms in the future.

- the CPU comes back and starts executing the 1ms "task", and finishes it.

- since the 5ms timer task hasn't finished yet, the 5ms periodic vi can't "finish". The CPU goes and does something else.

- when the 5ms interrupt occurs, this basically completes the 5ms timer "task", so the periodic vi is now "finished"

- in this scenario, it is required to make the periodic vi loop back and start again

Is the above even remotely correct?


~

[Tom Line]

Originally Posted by Ether

Hi Tom,

A few questions:

1) The "wait" function mentioned above, and the "Timer vi" mentioned by Mark... are you both referring to the same thing? The thing with the icon that looks like a clock?

2) In my post to which you replied, was my conclusion correct that the periodic task should be coded as a one-shot, and not wrapped in an infinite loop?

and finally

3) Are you sure that it means to wait 5ms from the time you last asked it to start running? Or is it 5ms from whatever time it is when the CPU encounters the request to re-schedule?


~

1. Yes
2. Yes
3. To the best of my knowledge that wait timer starts at the same time the vi executes. If it waited to start until after the cpu re-requested it to schedule, your actual wait time would be the vi processing time + the wait time, which isn't the case. Does that make sense?

[Ether]

Originally Posted by Mark McLeod

[*]A completely blank vi

• An infinite While loop
  • A Timer task (the CPU will wake up the enclosing While loop)
  • A 1ms Task (completely independent of Timer)

[/list]

OK, let's use the above as the basis for discussion.

Let's call "the completely blank vi" the "5ms periodic vi" since it's no longer blank.

This 5ms periodic vi has inside it an infinite while loop (is that the right way to say it?)

Inside the infinite while loop are two tasks:

1) a 5ms timer task, and

2) a 1ms task

Assuming the above is correct and I haven't mangled anything yet,

Something has to initially "call" (is that the right word?) the 5ms periodic vi to kick-start it. Is that correct?

Once started, it will run forever (until some other process stops it) because it contains an infinite loop. OK so far?

Both "tasks" within the infinite while loop must complete before the loop can loop back and re-start. Yes?

Since the 5ms timer task doesn't "complete" until the 5ms timer expires, that establishes the period of the 5ms periodic vi. How am I doing?

The 5ms timer task is implemented as an interrupt (or some other mechanism) that allows the CPU to go do something else while the 5ms is ticking away. That allows the CPU to run the 1ms task while it's waiting for the 5ms timer task to complete. Still OK?

When the 5ms timer expires, the 5ms timer task is now complete, and, since the 1ms task has also completed (since there are no other tasks in this simple example which would prevent it from doing so), all two of the tasks in the 5ms periodic vi are complete, so the loop re-starts. Please tell me I'm close.

Now, my questions:

1) It seems, in the above example, that it is important that the CPU somehow knows to start the 5ms timer task first, and then go run the 1ms task. If instead it ran the 1ms task first, wouldn't that task have to complete before the 5ms timer task even got started? Then the period of the 5ms periodic task would not be 5ms. Is the location of the graphics within the the diagram the key to telling LabVIEW in what order to execute?

2) Now, if there are other tasks in the system (besides those enumerated in this simple example), and if the CPU happens to be busy with some other task when the 5ms timer task completes, then the loop does not re-start right away, correct? It has to wait until the CPU finishes whatever it is doing? AND... any such delays are cumulative; ie the system doesn't compensate by short-cycling the next loop. So the effect of other tasks is not to create jitter, but rather to reduce the effective frequency of the 5ms periodic vi. True?


~

[Ether]

Originally Posted by Mark McLeod

I'm playing catchup with crossing posts, but yes I think you've got it.

The only change I'd make to your thinking is the line:

- the CPU comes back and starts executing the 1ms "task", and finishes it.

Think of both the 5ms Timer and the 1ms Task as starting simultaneously.

Sorry, I can't think that way. Too many years coaxing miracles out of underpowered embedded microcontrollers and sweating microseconds.

It's got to start one or the other.

There is no rule that says one must start before the other, or which starts first.

I'm still missing a piece of the puzzle. It has to start one or the other first. And if the RTOS is not time-slicing (or is it???), then if it starts the 1ms task first, there's no preemption to go make it start the 5ms timer task. The 5ms timer task then has to wait until the 1ms task completes.

Does LabVIEW somehow "know" that if a vi contains a timer task, it should be executed first?


~

[Greg McKaskle]

I've done my best to catch up to this thread, and progress is definitely being made, but let me add in a few points.

LV VIs execute by adding tasks to a queue when they are ready for execution. All tasks on the queue are guaranteed to be safe to execute in any order because they will satisfy the data dependencies in the user's code. OS threads are used to execute the tasks on the queue and to preempt back and forth between them.

Using the 5ms wait and 1ms task, when the VI begins, one task will be placed onto the queue -- the while loop itself. The while loop code will test the exit condition, increment i, and will then schedule two additional tasks and remove its task. One of the two tasks will be the 5ms wait, and the other will be the sequence of code that takes 1ms.

Since the user didn't specify which to run first, the compiler enqueue the tasks in either order. Graphical location has no impact on the order, but creation order may. The code for the wait will schedule itself with a worker thread to be removed from the queue for 5ms and then queued up again. The 1ms sequence will then be the only code on the queue, and the OS threads will run that task. As each task completes, it decrements a counter and conditionally schedules the end of the while loop when the counter goes to zero.

Of course the code is almost never that simple, but it scales quite well. Add many loops or tasks to the queue, and the same system still works.

As you noted, the loop with a time delay is not necessarily the most deterministic way to write your code. This is the easy and succinct way to write it, and for FRC, it is likely good enough. A more specific way to write it would be to note the time that the loop begins, then run the task, then subtract to measure the time before the loop should begin again and sleep the delta. Fortunately, this is built into the loop on the palette called the timed loop. It is very capable and even lets you balance priorities, modify loop rates, measure jitter and many other tasks well-suited to writing a realtime task and probably not needed for most FRC tasks.

Greg McKaskle

[Ether]

Originally Posted by Greg McKaskle

OS threads are used to execute the tasks on the queue and to preempt back and forth between them.

You may have told me that before but it didn't "stick". Now I think I get it. LabVIEW queues the tasks and the OS multi-tasks them.

Therefore, it doesn't matter what order LabVIEW queues the 5ms timer task and the 1ms task because the OS will "run them both". In the 2010 FRC LabVIEW framework, what algorithm does the OS use to decide what task to run and how long to run it? Is it a simple time-slice with equal slices for all queued tasks? Or does the OS look at deadlines and give priority to tasks whose deadlines are imminent?


~

[Greg McKaskle]

Typical LV tasks do not have deadlines. The realtime loop may, don't really know the details.

Greg McKaskle

[Mark McLeod]

At this point what I think you really want to know about is how the cRIO VxWorks OS handles it's end of things.

http://download-book.net/vxworks-pro...e-pdf-pdf.html

[Ether]

Originally Posted by Mark McLeod

At this point what I think you really want to know about is how the cRIO VxWorks OS handles it's end of things.

http://download-book.net/vxworks-pro...e-pdf-pdf.html

You may be right, but vxworks is extremely flexible and configurable, and I am mostly interested in specifically how the 2010 FRC LabVIEW framework is using it.

Thanks for the link though; I will take a look. It's been many years since I've read any of WindRiver's stuff


~