View Single Post
  #26   Spotlight this post!  
Unread 21-03-2010, 20:47
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: switching between Teleoperated enabled and Wathcdog notfed

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
Reply With Quote