20 Minute LabVIEW presentation

[kgzak]

I am giving a LabVIEW presentation at kickoff. I was wondering what you guys think I should add to my presentation that I can cover in 20 Minutes. How have you guys seen LabVIEW presentations done? Most of the teams will be completely new to programming and some have had some experience.

Thanks

[wt200999]

During my time as a FIRST student our team used C/C++ and never really bothered with LabVIEW. This was mainly due to ignorance on our part. The only graphical programming anyone had seen was either EasyC or Mindstorms.

The coolest featured that I have seen in LabVIEW so far (this my first year playing with LabVIEW for FRC) is the ability to quickly run code in memory, and how easy it is to write quick test code with graphical feedback. Having a chart or two on the front panel to test and plot real time sensor data is quite powerful.

Having some sort of autonomous routine with a fancy front panel could be a good demonstration, and may even convince some teams to take a second look at LabVIEW as an option.

[XXShadowXX]

Originally Posted by kgzak

I am giving a LabVIEW presentation at kickoff. I was wondering what you guys think I should add to my presentation that I can cover in 20 Minutes. How have you guys seen LabVIEW presentations done? Most of the teams will be completely new to programming and some have had some experience.

Thanks

A few points you could try to touch on. These are more of the finer points of labview, not actually really concepts that apply to other languages.

1) Local variables (and global to an extent) are made of pure evil. They seem fast and fun when writing code, but they aren't. Each write and read clones the value in memory (at least in Windows/Linux/OSX), I don't know about cRIO but its just a 'best practice thing''. They're bad, don't use them. They make debugging your code harder, and cause extra memory usage (also sometimes labview just doesn't track where locals and global are being read/write, so you may have a errant write in an unexpected location).

3) SubVI's, and why you should you them. Don't make a huge mess of spaghetti code. SubVI's help keep you organized.

3.5) Comments, graphics may seem simple compared to some of the magic that languages like haskell or perl can do, but you NEED TO HAVE THEM.

4) Different forms of SubVI execution. This is VERY important since sometimes just leaving normal execution will prevent recursion and sometimes cause weird behavior.


Normal Execution, this slightly sucks, and may under some circumstances clone the output of a previous calls to this subVI again. So yes you call this VI in 2 difference places with 2 difference inputs and it will output the same thing twice... Not particular handy. But it does limit the function to existing once in memory.

Shared Clone is used if you want to call a sub-VI recursively. It allows for a VI to be self referencing, if you don't execute like this the VI will break the block diagram if you nest it recursively.

Pre-Allocated is generally the way to go (sorta, not completely the best memory efficiently). This (I believe) creates a separate instance of each function in memory so it means you'll never run into the rare normal execution cloning error.

[Pault]

Originally Posted by XXShadowXX

1) Local variables (and global to an extent) are made of pure evil. They seem fast and fun when writing code, but they aren't. Each write and read clones the value in memory (at least in Windows/Linux/OSX), I don't know about cRIO but its just a 'best practice thing''. They're bad, don't use them. They make debugging your code harder, and cause extra memory usage (also sometimes labview just doesn't track where locals and global are being read/write, so you may have a errant write in an unexpected location).

Be careful when giving this advice. I agree, with one exception. When you are coding in the WPILib framework, you need to use global variables and can't be afraid of them. The reason for this is that if you are coding the right way, you will be doing a lot of communicating between Teleop.vi and Periodic Tasks.vi. By far the most practical way of doing this communication is via globals. There are also other good uses for globals, such as using one to create a sort of fake enum for all of your refnum names.

Also, 20 minutes is not a lot of time to teach a bunch of beginners about LabVIEW, and things get even more complicated when you have some experience in the mix that you don't want to bore. My recommendation would be to not even bother trying to touch upon how to actually code, instead just link them to guide that will teach them how like this one. Your time would be better spent talking about the LabVIEW environment and WPILib framework. Talk about some good overarching principles like data flow and documentation and good debugging practices. Make sure they know how important it is to establish a good way to share code, giving SVN, GitHub, and email/flashdrives as examples. And most importantly, make sure they know where to look for help when they need it (Chief Delphi would probably be a good place).

[mrscience21]

I agree with Paul T, 20 minutes is not a lot of time for a labVIEW tutorial. I have been teaching a set of new programmers and have found that in order to do it well you need a much longer amount of time, allowing questions to be answered along the way. In any case, if you are mainly reaching out to new programmers, please make sure you cover a couple of things (Hopefully without repeating someone in the comments above, sorry if I do.):

1. Type Defs, Clusters, and Arrays: I have found that these specifically confuse new programmers quite often. That's a big problem too, since these data forms are used frequently, especially in WPI Lib Functions. Not to mention they are very useful once mastered and can minimize memory usage.

2. Robot Data Flow: This one is critical. A good understanding of Data flow through out RobotMain.vi, the robot and dashboard, and even the flow between the C-RIO and other components can save tons of headaches later. ( This can be as simple as ensuring they understand begin operates before teleop and etc.)

3.Construction of a basic drive system: From "begin" to "finish", this may be the most important thing you can do.

4. Disable.vi and safety configurations: I frequently see new programmers leave these alone, resulting in a flood of errors that can very easily be avoided.

If you wouldn't mind the suggestion, I would hold off on doing an autonomous program but instead demonstrate the construction of a basic drive program from start to finish. Autonomous may be more interesting to watch but it is Teleop new teams will have to worry about. Plus, construction of a complete drive system is capable of demonstrating how the all the subVI's in the system work together to accomplish a single task - moving that robot. In the short amount of time given, I realize you wouldn't be able to do a full explanation of how the system works, but I've found that giving them a basic over view of how and why it works provides them a foundation from which they can expand their knowledge.

If you have more time, please also consider talking a bit about sensors and how to use them. From personal experience I realize the demonstration alone could eat up all your time but this is yet another topic I see a lot of younger programmers over complicate or mess up entirely. Good Luck!