View Single Post
  #2   Spotlight this post!  
Unread 29-08-2010, 19:03
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,533
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: paper: Programming in LabVIEW: Tips and Tricks

Quote:
Originally Posted by apalrd View Post
Or you could use the threads to partition your code. Each thread operates a sub-system, allowing a single VI to be written that handles the acquisition of refs from Begin, the code loop, and cleanup at the end (although it actually never gets there), for one subsystem. More complex subsystems contain clearly labeled SubVI's called from this VI, and all WPI lib calls are visible from the main VI.

If you wanted to process images asynchronously from using the target data, you could put a call to process image and a loop to use the image data in the same VI, running as two parallel threads, but under one sub-system VI. If you needed to pass references to both threads at the beginning, they would both be there.

Plus, isolating the robot functions from Teleop allows you to use them much more easily in Autonomous.
I definitely understand the image processing requirement of being outside the teleop and running as fast as possible.

From our standpoint though, nothing mechanically really needs to run that fast. I suppose encoder sampling if you're attempting traction control would be another good reason (what's the maximum sample rate of our digital I/O on the crio?).

As for teleop and auton, we attack that differently. We wrote a subvi to handle our kicker, and had a copy in autonomous and a copy in teleop. Since they never execute simultaneously, you don't have to worry about re-entrancy.

I can see the reasons for doing it for a cleaner code look, however from the readability side, teaching my newer students is much easier if I can point at the teleop loop and say "this is where everything happens during teleop".

As long as you approach the code and create a subvi for each individual task I suppose it's pretty easy to code either way.

What I'd really like to get the kids to do this year is to have a decent fault / warning reporting system that tells you the state of each variable and what it's waiting on to progress to the next state - much in the way the automation in our plant is programmed.
Reply With Quote