View Single Post
  #77   Spotlight this post!  
Unread 30-09-2008, 08:57
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,766
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: Programming with the 2009 controller

While LV expressions are based on dataflow, it is not a pure dataflow language, and since many real-world problems require state, LV has numerous mechanisms for maintaining state. Of course the parallel nature of LV means that it is important that you access the state safely.

As for loop timing, there is not a hardcoded schedule that everything else is bound to. In our prototype bots, we've often built loops that run in parallel at rates that match their task -- comms and joystick at 25Hz, servos at 50, motor updates at 100, camera at 10, etc. LV and C/C++ have different ways of doing this, but you have the flexibility of different rates.

You can of course put tasks in the same loop and try to run them at the higher speed, but you now have other choices.

The communication between the loops is usually a small set of variables, notifiers, queues, or other mechanisms for data transfer. It may be useful to think of them like registers between PICs if you want.

To calculate distance or otherwise factor in time, you will have access to high resolution clocks, which should give better results than assuming loop rates never wander.

Greg McKaskle