View Single Post
  #3   Spotlight this post!  
Unread 31-12-2013, 01:43
XXShadowXX's Avatar
XXShadowXX XXShadowXX is offline
They call me Cody.
no team (None currently :\)
Team Role: Mentor
 
Join Date: Jan 2008
Rookie Year: 2008
Location: Pontiac; MI
Posts: 408
XXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud ofXXShadowXX has much to be proud of
Re: 20 Minute LabVIEW presentation

Quote:
Originally Posted by kgzak View Post
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.
__________________
Is now an engineer thanks to FIRST.

Last edited by XXShadowXX : 31-12-2013 at 01:47. Reason: included comments.
Reply With Quote