labVIEW programming guidelines

[Nukem]

Hello everyone. I was on here a week or two ago with a program I had written. I received a lot of well deserved negative feedback. There were a lot of things I had done that either didn't make sense, was sloppy, or did not fit the accepted rules of LabVIEW programming. I am returning to you and your expertise after this holiday weekend to take another look. I have revised the program using the suggested JKI State Machine, but I want to make sure there are not any huge glaring issues plaguing my code.

Thank you all for your help! 

Nukem 

LabVIEW 2010

[JÞB]

Nothing "Glaring"

Some issues. 

• You'll have the devil's own time modifying the "Data: Initialize" state.  Yes a bundle by name might just make the BD space worth the time it would take to add a new element or replace the one you need to change (HINT: Type def that cluster!)
• Property FP.Open is depreciated for a reason.  Use FP.State in "UI: Front Panel State"
• "UI: Modify" has a few minor errors.  did you intentionally break the error chain because you forgot to use a shift register through the for loop? (Actually that might not be "Minor"  for loops can iterate 0 times you can loose an error that way)  and really there is no need to set the indexing twice on that loop!   If given the opportunity to guess I would say this case got "Debugged" by a rookie when that array was empty and caused a day of headache.
• This deserves a speccial note:
• 

Why not just run the code to configure the FG?  Heck you could init your test equipment and report the error for missing coms!  The point being you want an operator with a IQ of 3 to be able to "Push the button - get a banana"  Humans reading and following directions is error prone.  Automated test should not be.

Overall I like it! Kudos

[Yamaeda]

I agree with Jeff, it looks good now. The State machine is probably made a few LV versions back. Usually that's a non issue but FP.Open is now an "elderly" function. According to help you should change it to Invoke node -> Front panel Open.

How does it feel for you? Do it feel more expandable, reusable and easier to navigate?

Good Job!

/Y

[Nukem]

Thank you both for your input. Since both of you touched on it I will ask this first: Since I plan on packaging this as an exe for my professor and future students to use do I really care about the front panel open/close state? As long as I remove it from the queue is there any harm in deleting it entirely? 

Type Defs: I've heard that thrown around and I looked up very briefly their use and it appears to be a very good idea. I have run into that problem already with having to triple check all of my bundle/unbundle commands for consistency after changing that case. I tried adding my front panel to a type def control file but it was giving me an error because of multiple controls. How do I combine my front panel controls into one master control that it will accept?

Or am I just going about it wrong? 

I did fix all of the broken error data flow issues. 

Now that last issue: I would love to combine those two steps but I have not had much luck so far. The LIA has not consistently needed the same steps to configure, but I will look into that further. The other is a function generator that does not support LabVIEW and required significant searching to even get to work on 64 bit windows. It comes with a small program that turns the device on and allows for the user to select and modify the output. Is there a way to embed this program into my VI? Perhaps in another tab or as a popup? The program does need to continue running or the signal is lost.

In a perfect world I would dig around and interface the device with LabVIEW directly, but that is far beyond my abilities. 

Thanks for the help!

Nukem

LabVIEW 2010