Go to Post Honestly, I'd much rather see FIRST put a little more effort getting the point values correct than the marketing theme. - Brian Selle [more]
Home
Go Back   Chief Delphi > CD-Media > White Papers
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

photos

papers

everything



Programming in LabVIEW: Tips and Tricks

Lucario231

By: Lucario231
New: 08-27-2010 05:37 PM
Updated: 08-30-2010 07:43 PM
Total downloads: 1648 times


What I learned and used in LabVIEW through FIRST robotics. This includes executable VIs, hints, and papers from others from the FIRST communitythat helped me to make clever Driver Station stuff.

Some helpful URLs for the Driver Station stuff:

http://www.chiefdelphi.com/forums/showpost.php?p=901152&postcount=6

http://decibel.ni.com/content/docs/DOC-8862

Attached Files

  • zip Programming in LabVIEW by Chris Hideg Revision 1

    Programming in LabVIEW_ Chris Hideg REVISION 1.zip

    downloaddownload file

    uploaded: 08-29-2010 10:54 AM
    filetype: zip
    filesize: 1.48MB
    downloads: 398


  • pdf PDF version of the DOCX document

    Programming in LabVIEW_Chris Hideg REVISION 1.pdf

    downloaddownload file

    uploaded: 08-30-2010 07:43 PM
    filetype: pdf
    filesize: 845.93kb
    downloads: 712


  • pdf PDF Version of the Classmate customizeing document

    ClassmateSideOfCustomDS.pdf

    downloaddownload file

    uploaded: 08-30-2010 07:43 PM
    filetype: pdf
    filesize: 28.95kb
    downloads: 536



Recent Downloaders

Discussion

view entire thread

Reply

08-28-2010 12:33 PM

Lucario231


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

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



08-28-2010 10:17 PM

Jogo


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

Wow, thanks for this! I haven't seen anything like this before, good stuff. One question: you had mentioned in the intro that you would discuss version control, but I can't find anything in the document discussing this. This is something that would be especially useful for me, think you could add some tips for it?



08-29-2010 09:23 AM

apalrd


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

There are a couple tricks you missed:

Threading. The ability to run each sub-system in it's own thread gives you two things: Independent loop cycle timing (some things that are higher priority can update at the same rate as the Victors/Jaguars, while lesser things can run slower (flashing lights or Dashboard comm). When running multiple threads, you can pickup and scale user input data in Teleop (e.g. take the distance slider, and scale it to feet) and pass it to the parallel thread using either RT-FIFO or Global variables.

OpenG has a rising/falling edge trigger, among a GIGANTIC list of helpful VI's.

State-machines. These are HUGE. You can describe the process of creating an enum. control and using that to select states in a case structure. Very useful for things like kicker sequencing or multi-position arms.



08-29-2010 10:52 AM

Lucario231


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

@ Jogo

Whoops sorry about that. I will fix that.

Anyway Version control in LabVIEW is hard to do. What I do is at every competition or before it. I Make a copy of the code and save that under a different name. I also make a new executable and label it for that competition. For example, I have "build season code.exe" as a downloadable code for the robot. Then for I make a new exe called, "competition one.exe". Then when ever I make changes to the code I build in the new .exe file. That way if the code doesn't work I can change over to "build season code .exe". I also made a text display on the DS that says what code is running. Us the other papers attached to modify DS screen and other things. This is more of a way to manually handle version control. I don't know of a way to have LabVIEW do this automatically other than using multiple exe codes.

Hope that clears things up.

@ apalrd

Threading is interesting I never used that before. I might try that later. I will add state machines in another revision when I have more time and some code ready.



08-29-2010 11:22 AM

apalrd


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

About Threading:

You would create a VI for each subsystem (not necessarily each thread)
Then you would call the VI from under the main loop (where Vision and Periodic Tasks is)
Then, in each VI, you would add one or more While loops (for each thread)
Each While loop will run in parallel.
You can then use Wait Ms to time the loop, somewhere between 20ms and 50ms is average (remember: the main loop runs at *around* 50ms ish, and has no exact means of timing.)
If you do not include Wait Ms, then the new thread will consume all of the remaining CPU power, cause possible network lag, and make it impossible to determine actual CPU load. Include the Wait Ms or another source of delay (e.g. wait for occurrence from the comm packet, or a camera wait for image) in every loop.



08-29-2010 02:46 PM

Ether


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

Quote:
Originally Posted by Lucario231 View Post
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.


~



08-29-2010 03:36 PM

Tom Line


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

Quote:
Originally Posted by Ether View Post
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?



08-29-2010 04:36 PM

Ether


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

Quote:
Originally Posted by Tom Line View Post
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.

~



08-29-2010 05:05 PM

apalrd


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

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.



08-29-2010 06:03 PM

Tom Line


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



08-30-2010 01:24 PM

Ether


Unread Re: paper: Programming in LabVIEW: Tips and Tricks



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.




08-30-2010 07:58 PM

Lucario231


Unread Re: paper: Programming in LabVIEW: Tips and Tricks

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



view entire thread

Reply

Tags

loading ...



All times are GMT -5. The time now is 12:06 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi