simplifying my vi

[McMurray]

Hello everyone,

I'm quite new to LabView, and really programming in general.  Attached is a copy of the VI I'm working on.  I know it's ridiculously over complex (while loops inside of while loops, etc), but it works.  I'd like to simplify it so that my colleagues can easily understand it and so that it's easily expandable in the future, since all of my functions are currently hard-wired in.  I thought I might thow it out there for anyone who might be interested to make their suggestions and improvements.  I know everyone has their own style, and clearly mine is still developing, so I'd like to develop good habits early.  Remember, I don't really know any jargon yet, so please explain things that you think I might get tripped up on.  Fire away and thanks for all the help!

Matthew

[McMurray]

I'm toying with using a queued state machine to simplify my command sequence.  Thoughts?

Matt

[nathand]

Hi Matthew - it looks like you have some experience with text-based languages, as you've tried to adopt that style to LabVIEW.  Have you worked through some of the LabVIEW example code?  You should spend some time learning to think in dataflow.  Your code is neatly arranged but there's no need for all the sequence structures, nested while loops, and shared variables.  LabVIEW code doesn't need to be that complicated.  To cause the prompts to occur in the correct order, use the "Error In" and "Error Out" terminals to chain one of them to the next in the order in which you'd like them to execute.  You can remove all of the sequence structures.  You can also remove most of your nested while loops, and with a little more work you can (and should) remove the shared variables as well.  Read about state machines; you might want to re-implement in that form.  You probably don't need a queued state machine for this application; a simple one will work fine.

[nathand]

A few other, more minor points:

The timing function you're using (Wait) doesn't guarantee much precision since it only waits a minimum number of milliseconds; it may wait longer if the operating system is busy.  You also can't guarantee that your two loops match; they may reach 10800 at different times.  If you convert to a state machine, use a shift register to track the time at which the current stage started, then subtract from the current time to determine when to advance to the next step.

You can clean up the graphing code, removing the transpose array and some conversions, as shown below.

 

Message Edited by nathand on 01-13-2009 04:31 PM

[McMurray]

nathand,

Thanks for the tips.  I didn't realize that the error wires can be used to set up a sequence of events.  That'll really help for sure.  LabView is really taking a lot of getting used to, and the documentation isn't really helpful.  I'll give this a shot and see how things unfold.  Any other wonderful tips?

[RavensFan]

One problem you'll have is with the shared variable stopping all the nested for loops.  It will appear like the program runs one more time than you intended.

When your program first starts, the stop program shared variable will be false, so all loops will run.  The shared variable in the outer most while loop will immediately be read as false.  The outer while loop won't iterate again until all of the inner structures have completed.

Those inner structures will complete only when the Stop program shared variable becomes True.  Then the inner loops will stop.  But because the outer loop as already read it as false, the outer loop will run again going into the next iteration, thus restarting all of the inner structures again.  They will only run once because the variable is still false, but that is probably one more time than you intended.  Except some of those loops that have different stop conditions will have to wait until those conditions are satisfied.  That outer while loop doesn't do anything different than the next layer down and should probably be eliminated right away.  It looks like just a big wrapper that will definitley cause the double running I just mentioned.

Embedded while loops can be an extremely difficult thing to control, and you are generally working 3 loops deeps.  Much of the code could be combined.  And as nathand said, you should look at the state machine architecture

[McMurray]

Thanks Ravens Fan,

Your comment is indeed true, and I've noticed it happening when I run the vi, although I didn't know why until now.  I'm working to shift the entire organization into a state machine, which should allow me to get rid of all of my imbedded while loops and shared variables if I do it right.  I'll post it once I've got it done, and I'd really appreciate it if anyone has time to look it over.Thanks!

Matt

[McMurray]

I've made some considerable changes to the program, eliminating my global variables, and reorganizing everything.  Some issues still exist (too many while loops, etc), but I feel like it's much easier to follow.  The new version is attached (no Sub-vi's).  Does anyone have any other suggestions?  I like the feedback and ideas.  I've learned so much already just by fiddling with it, and every comment only helps more, so post away!  Thanks for the help and feedback!

Matt

[Joe_H]

Since you are doing a lot of polling of the front panel controls (ie turn chamber on/off) I would look into using a Qued statemachine with events type of architecture. this will eliminate the need for polling the controls.

[nathand]

Hi Matt - your updated code is very difficult to look at because it takes up so much space on the screen!  A good rule to follow is that a VI's block diagram shouldn't be larger than your monitor.  Also, while you have rearranged your code, you don't seem to have taken many of the recommendations made earlier, so I'm hesitant to make further comments.  Take the time to follow the suggestions made earlier in this thread.  Remove your sequence structures.  They're not necessary, and once you understand why you'll have a much better understanding of LabVIEW and dataflow.  Do make a state machine.  Avoid local variables, especially when your front panel terminals are sitting unused in a corner of your block diagram.  Wire directly to and from front panel terminals wherever possible (and where it's not, consider restructuring your code before using local variables).  I know this will be painful to hear, but consider copying only the front panel objects into a new VI and starting with a clean block diagram - actually, I've done it for you, and added the bare beginnings of a state machine.