LabVIEW
General Labview Efficiency and layout question (with example)
First of all, nice front panel! I can't even guess the number of times I've seen "hot dog stand" looking interfaces where people get excited about the color picker and insist on using red yellow and green all over the place. You have managed to make it look somewhat professional and I respect that. I would suggest tightening up the panel a bit to eliminate all the space around your tabs unless you want this to be full screen.
Your diagram is functional, but it could use some style guidance. I couldn't fit it all on my screen (and I use REALLY high resolution). It looks to me like you could simply shrink it down bt bringing things close together, but there's a better way. I want to address your questions about state machines. For most unser interfaces in LabVIEW they are simply a must. I see your several case structures here and I'm thinking that they could all be combined into one with a separate case for each change event (I see you're checking for control value changes). You get to name your cases in state machines such that they have meaning. With a boolean case you only get the T and F of it all and it doesn't tell me what your going to do about it.
Towards the right side of your while loop you've got this bundle with all the control values wired up. For my state machine I like to bundle my controls on a shift register too. However, you should note that the property nodes created for each control are not necessary. The bundle you create with the control nodes themselves is sufficient to place back on the shift register. You can use that bundle in your event cases whenever you want to manipulate a value or read one for a calculation or something. There are lots of good state machines out there. I recommen using a while loop with a large case structure inside. Make one shift register for your all you data and one for the error cluster. Use a queue to keep track of your states and wire a remove queue elements output to the case selector. Have a "Main" case set as the default for when the queue runs dry. Place all your user controls in the Main case and do your checking for changes there. Build an array of booleans (change or no change + any boolean controls) and an array of states with which to associate the changes or boolean switches. Search the array for TRUE and get the index, and then choose the element of your state array to be inserted on the state queue.
The state machine has many advantages. It organizes your code and makes it easier to debug. Also, if you use the queue method briefly discussed above, you can take control of your VI with another VI by creating a queue with the same name as your state queue. A parallel VI can add elements and your state machine will pick them off. It's all very cool.
I know some of the other LabVIEW-heads out there have oodles of documentation on thier state machines. There is a good article about them in the LTR as well.
Isn't there a discussion ongoing about LabVIEW stlye guides around here too?
Have fun,
Dan Press
www.primetest.com
Your diagram is functional, but it could use some style guidance. I couldn't fit it all on my screen (and I use REALLY high resolution). It looks to me like you could simply shrink it down bt bringing things close together, but there's a better way. I want to address your questions about state machines. For most unser interfaces in LabVIEW they are simply a must. I see your several case structures here and I'm thinking that they could all be combined into one with a separate case for each change event (I see you're checking for control value changes). You get to name your cases in state machines such that they have meaning. With a boolean case you only get the T and F of it all and it doesn't tell me what your going to do about it.
Towards the right side of your while loop you've got this bundle with all the control values wired up. For my state machine I like to bundle my controls on a shift register too. However, you should note that the property nodes created for each control are not necessary. The bundle you create with the control nodes themselves is sufficient to place back on the shift register. You can use that bundle in your event cases whenever you want to manipulate a value or read one for a calculation or something. There are lots of good state machines out there. I recommen using a while loop with a large case structure inside. Make one shift register for your all you data and one for the error cluster. Use a queue to keep track of your states and wire a remove queue elements output to the case selector. Have a "Main" case set as the default for when the queue runs dry. Place all your user controls in the Main case and do your checking for changes there. Build an array of booleans (change or no change + any boolean controls) and an array of states with which to associate the changes or boolean switches. Search the array for TRUE and get the index, and then choose the element of your state array to be inserted on the state queue.
The state machine has many advantages. It organizes your code and makes it easier to debug. Also, if you use the queue method briefly discussed above, you can take control of your VI with another VI by creating a queue with the same name as your state queue. A parallel VI can add elements and your state machine will pick them off. It's all very cool.
I know some of the other LabVIEW-heads out there have oodles of documentation on thier state machines. There is a good article about them in the LTR as well.
Isn't there a discussion ongoing about LabVIEW stlye guides around here too?
Have fun,
Dan Press
www.primetest.com
