paper: Programming in LabVIEW: Tips and Tricks

[Ether]

Originally Posted by Lucario231

Hey I just finished writing his paper. If anyone has any questions you can message me or leave a question here.

Couple of suggestions:

If you want to reach a larger audience, get rid of the DOCX files. Replace them with DOC, or better yet, PDF.

Threading and state machines (mentioned in an earlier post by apalrd) are two areas which seem to cause a lot of trouble for new FRC LabVIEW programmers. Adding a concise explanation of these would add much value to the paper.


~

[Tom Line]

Originally Posted by Ether

Couple of suggestions:

If you want to reach a larger audience, get rid of the DOCX files. Replace them with DOC, or better yet, PDF.

Threading and state machines (mentioned in an earlier post by apalrd) are two areas which seem to cause a lot of trouble for new FRC LabVIEW programmers. Adding a concise explanation of these would add much value to the paper.


~

I've never understood the difficulty understanding state machines. Perhaps it is conceptualizing the fact that the loop runs constantly but only increments your state machine when a condition is met?

I've always understood that you COULD run parallel threads, but I have a question regarding that.

We put a timer in front of our teleop code that passes it's time value into each loop. We use that to run any time-sensitive loops. I have yet to find anything in FRC that requires anything faster than the (approximately) 50ms loop. Can you tell me what type of things you might want to run faster than that?

[Ether]

Originally Posted by Tom Line

I've never understood the difficulty understanding state machines. Perhaps it is conceptualizing the fact that the loop runs constantly but only increments your state machine when a condition is met?

I've always understood that you COULD run parallel threads, but I have a question regarding that.

We put a timer in front of our teleop code that passes it's time value into each loop. We use that to run any time-sensitive loops. I have yet to find anything in FRC that requires anything faster than the (approximately) 50ms loop. Can you tell me what type of things you might want to run faster than that?

I can tell you something that wants to run slower than that. A kicker for example. Say the kicker needs to wait 1000ms to re-arm before it will accept another kick command. You could code the kicker as a state machine and run it in teleop, or you could run the kicker in a separate thread and just block waiting for 1000ms. But what you can't do is block waiting for 1000ms in teleop. It will screw up the rest of the teleop code.

~

[apalrd]

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.

[Tom Line]

Originally Posted by apalrd

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.

[Ether]

It's not that state machines are difficult to understand, it's just that many new programmers (new to robotics) don't realize they need to use them (or concurrent processing). They program the robot like they would program a non-realtime app on a PC. This is understandable if they've never been taught the basic concepts of realtime programming.

Teleop runs once every time a DS packet is received. DS packet is sent every 20ms (not 50ms). Any functionality (like a kicker with delays) which can't complete in well under 20ms must be written as a state machine if it's going to be put in the same thread as teleop. Or it can be run in a separate thread, using block waiting for delays. Many hours of confusion and frustration could be avoided if a way could be found to ensure that new programmers are taught these simple concepts.

[Lucario231]

I have made the DOC files into PDF versions. That should clear up some viewing issues.