LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Top LabVIEW Rookie Mistakes

I will be writing a series of 6 articles over the next few months on top LabVIEW rookie mistakes. Readers will be encouraged to add their own LabVIEW rookie mistakes that they want others to know about to this thread. I also want this to be an open discussion of the article topics so I'll be responding to questions as each new one is released.

 

No action will be happening with this forum thread now, but subscribe so that when discussions start you can take part.

Message 1 of 47
(9,870 Views)

Alright the article is now live (http://zone.ni.com/devzone/cda/pub/p/id/1735).

 

What are some other mistakes that you've run into that I left off my list?

Message 2 of 47
(9,599 Views)

I am so glad you mentioned documentation.  I find a lot of the "experts" often forget this.  Get people in the habit early and it'll make life a lot easier down the road.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 47
(9,594 Views)

I'm planning this as a series of articles where I can dive into each topic more in-depth (no way to fit it all into one article). I purposely put documentation at the end so hopefully I can talk about exciting documentation features in LabVIEW 2013 (shameless LabVIEW Beta plug: ni.com/beta).

 

I have also found that as programmers (of any language) we wait until the end of development before adding documentation and even then most don't add any at all. This makes it harder than necessary for someone to figure out what your code does. Spending even a little time on documentation can make a world of difference.

0 Kudos
Message 4 of 47
(9,591 Views)

Here is a classic.  Not using projects! 

 

The usual answers involve some form of painful experience with projects that grew.  Either the developer edits a lot of code outside the project becasue its a quick edit and the project takes time to open.  Or the really painful horror case where "It was getting too big" so "We moved things around on disk and cleaned up the vi names." Usually straight drag-n-drops from windows explorer. 

 

That, of course, can really confuse the project and the novice can't explain why, what, when or how to fix it.  About that time, the novice just deletes the lvproj file.Smiley Surprised


"Should be" isn't "Is" -Jay
Message 5 of 47
(9,588 Views)

@JÞB wrote:

Here is a classic.  Not using projects! 

 

The usual answers involve some form of painful experience with projects that grew.  Either the developer edits a lot of code outside the project becasue its a quick edit and the project takes time to open.  Or the really painful horror case where "It was getting too big" so "We moved things around on disk and cleaned up the vi names." Usually straight drag-n-drops from windows explorer. 

 

That, of course, can really confuse the project and the novice can't explain why, what, when or how to fix it.  About that time, the novice just deletes the lvproj file.Smiley Surprised


I haven't seen things go to that extreme.  But yes, the lack of projects is a problem.  I find this problem grows from working with the very simple projects that don't need to be built.  For a few VIs, you can get away with it.  But as soon as you get a decently small to medium sized project, project files are a must.

 

Another issue I just thought of (again, many "experts" fall into this problem): Not handling errors.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 47
(9,576 Views)

How about not turning on context help?

Or not using the search function?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 7 of 47
(9,563 Views)

I'd go with billko: not using context help, detailed help or example finder. Some people are very surprised when told about those "features", this can really change their lives 😄

 

Also:

  • Not caring about cleaning the code up - it was covered in the article, not directly though. Take 20 seconds now to make your wires straight, save 2 hours later!
  • Using stacked sequence structure... That's it: "using", not "overusing"*. Especially in situation, where state machine is the solution.

 

 

 

 

 

* I mean - really, if you're a rookie, you don't have a good reason to use stacked sequence, you're just lazy and/or don't know about proper design patterns 😉

Message 8 of 47
(9,546 Views)

Awareness of help tools is a big one. There are some people (including myself personally) that feel that Stacked Sequence Structures shouldn't be in the language at all. This is a religious battle though so people will have differing opinions. Expect Stacked Sequence Structures to definitely make an appearance in my Data Flow article.

0 Kudos
Message 9 of 47
(9,539 Views)

Very nice article.

I received this via email before, but read again.

Actually, this remembers me my first months using LabVIEW: I see wires, I see wires everywhere...

And as Jeff and crossrulz said, not using projects are a risk situation for bigger projects.

 

Well, every LabVIEW rookie should take a look at this.

 

Congrats G-Money.

Mondoni
Message 10 of 47
(9,536 Views)