switching between Teleoperated enabled and Wathcdog notfed

[Ether]

The multi-tasking LabVIEW environment gets even more complicated when you recognize that vi's are operating in parallel and in fact operations within vi's are also operating in parallel.

understood

There's nothing unique about Periodic Tasks.vi that's given it and all the tasks within it priority over Teleop.vi or Vision Processing.vi, etc.

understood

The timer alerts the task scheduler when it needs servicing again. In fact you can use a timer with zero time just to break a task out of the CPU and send it to the back of the scheduler queue.

OK makes sense.

Everything's clamoring for scheduled CPU time and somebody's going to have to wait sometime. It's non-deterministic in this framework. There are some low-level non-RT calls made too, but for our FRC purposes think of it as close-to-RT.

The point I was making is that the task time management in the LabVIEW framework is not preemptive, as I now understand it. So if the user creates a 100ms periodic task that takes 30ms to run, then a 5ms periodic task is NOT going to run at 200Hz. If the user creates a control algorithm in this 5ms task that depends on 200Hz execution, then the algorithm will not perform as expected, and may even be unstable. This is not a complaint, merely an observation, and a warning to other teams that may not already realize this.



~

[Mark McLeod]

I'm responding for the masses too

[Ether]

Originally Posted by Mark McLeod

I'm responding for the masses too

Understood. And in that spirit, one more question: if the user creates a periodic task with a 5ms timer, and the code in the task takes 1ms to run, is the period of the task 5ms or 6ms? In other words, does the Timer vi count down from the time the task was started, or from the time that the timer vi is executed?

~

[Mark McLeod]

In your case the 5ms timed loop will repeat every 5 ms or as soon as the task scheduler allows after 5ms are up.
The timer vi counts down from the moment it is started, and usually that's co-incident with the loop starting.

Using the example I posted above each use of the timer is a parallel task so it runs at the same time as all the other stuff within the loop.

For instance, the outer loop begins as soon as the four data tunnels in the outer wall are satisfied. These actions then occur in parallel:

• 100ms timer in the outer loop starts
• The Joystick Get also starts at the same time
• The Kick global variable is read

The outer loop will then wait for everything within it to complete before going to the next loop.
Now if all that other stuff (the inner Case statement and loop) finish sooner than 100ms. The outer loop will be waiting for that 100ms timer.
If all that other stuff takes longer than 100ms (it likely will when you kick because a motor is involved, and likely won't when you don't kick), then the timer will be long done by the time everything finishes and the outer loop proceeds to the next loop.

Look also at the first frame of the flat sequence structure. The solenoid release and the timer start simultaneously. So that frame will only take 10ms to complete before moving on to the next frame. A typical solenoid might take 5ms to open fully, so you'd better verify that 10ms is long enough to wait for a solenoid and cylinder to release a latch. If you have a large cylinder on that latch better up the timer to 20ms.

[Ether]

Originally Posted by Mark McLeod

In your case the 5ms timed loop will repeat every 5 ms or as soon as the task scheduler allows after 5ms are up.
The timer vi counts down from the moment it is started, and usually that's co-incident with the loop starting.

Now things are not making sense again:

- At time t=0 the CPU encounters the 5ms timer vi so the CPU goes away and does something else.

- When the CPU comes back to execute the code it is now t=5ms.

- the code takes 1ms to execute. It is now t=6ms.

- the task loops back to the beginning and encounters the 5ms timer vi again. The CPU goes away for 5ms, and when it comes back, it is now t=11ms.

- the code now starts executing again at t=11ms.

Therefore, the period is 11-5 = 6ms, not 5ms.

What is wrong with the above argument?


~

[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.

[Ether]

Originally Posted by Mark McLeod

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

• 5ms timer
• 1ms task

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

My understanding of the timer has completely changed based on the above. It is not a timer, per se, but rather a mechanism to re-schedule the present task at a future time...

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

- at t=0 the CPU encounters the 5ms timer which re-queues the task to run again at t=5ms (or as soon thereafter as possible)

- the CPU then continues on in the task to execute the task's code, which takes 1ms.

- the task is finished; it is now t=1ms. the CPU goes idle until t=5ms

- at t=5ms, the scheduler gets the task from the queue and runs it again

Is the above correct? If so, then the user, when coding a periodic task, should NOT put the task in an infinite loop, as my original pseudo-code did. Instead, the task should be coded as a one-shot, because the timer vi re-queues it each time it is run. Correct?



~

[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 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...

~

[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)

[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?


~

[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.

[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?


~

[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

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?


~