04-12-2010 04:19 PM - edited 04-12-2010 04:26 PM
I am not really in the business of writing nuggets (nor do I plan to be soon) but this one is something I wished I had learned a lot sooner in my developing "career" and I hope it can help some new users start at a point further ahead of where I did. This little nugget is about the power of using type def clusters to keep code clean, concise and maintainable. This can be done with 3 simple steps.
Step 1. Create typedef cluster. Do this immediately. It is not worth the headache and broken wires later if you forget this step. Create a type def cluster with any values you will need to pass between subVIs. This includes data, control values, file refnums, etc. Anything you may need to access in multiple places.
Step 2. Have a read front panel control values state. By having this state, you can keep all your control terminals in one place. Also, this state can be queued up any time there is a value change. This ensures the most recent (and the same) control values will be read by all your VIs on that iteration of the loop, and eliminates race conditions. If you need to access the control value in the producer loop, use the newval terminal in the event structure.(oops, i'm showing the wrong case in the event structure. Hopefully you can figure it out though)
Step 3. Add the typedef control to all necessary subVIs within your code. Doing this allows for much cleaner block diagrams. For example, the scenario below. In an init case maybe you open the log file and read the initial temp and pressure values. Well, rather than pass each of these 3 things out of the subVI in individual wires to be used in data logging, bundle them into your cluster and pass that out. This results in one indicator node instead of 3. Then in the data logging subVI, it only needs to accept the cluster and the error cluster rather than a refnum, two data values, and an error cluster. As you can imagine, this becomes incredibily useful if you have more than just two data values to log.
You can also queue up the entire cluster, rather than just the state enum, but techniques for producer consumer queues can probalby debated all day. Also,
obviously there needs to be more state machine logic to determine which state to go to next etc, but the goal of this was to get across the point that typedef clusters are your friend in keeping LabVIEW code easy to work with and modify. Hopefully this does that.
There you have it, a simple way to make diagrams maintainable and clean. If anyone else has comments, suggestions, or methods they like to use please feel free to post them.
04-13-2010 02:20 AM
Nice nugget. Only one thing to add:
When working with latching buttons, removing the terminal from the value change event can possibly lead to unwanted graphical issues (button seems to stuck pressed). I don't think that your approach is likely to run into such an issue, but it is possible....
@aeastet: Strict typedef versus (weak) typedef has only one difference: The strict typedef also defines the visual appearance of the control. So you may not resize/recolor anything from that type.
The (weak) typedef already updates the instances just like the strict one.
04-13-2010 08:12 AM
04-13-2010 10:26 AM
04-13-2010 10:29 AM
Excellent, I hadn't seen that one before.
Very little over-lap between the two. I think they fit nicely together.