LabVIEW
Trying to meet the best practices
- the error wires of property nodes are useful to define execution order. Most properties never generate errors, but some do, e.g. if you select an active plot that does not exist. Wires in general are a central part of LabVIEW code, not sure why you think they are messy.
- Static references are constants, but things that only need to be done once belong before the loop. The question might be why you need all these references?
- Switch until released is rarely a good choice, because a press can be missed or recorded multiple times, depending on the loop rate. Are you using an event structure? The most typical mechanical action to trigger something is "latch when released" (and also "switch when pressed" to toggle the value).
- You create subVIs to isolate reusable code into logical segments.
- A FGV does not update indicators. It is not clear how you are using them. Is that where all the references are going?
I would recommend to solve a few CLD example using what you think is best, post them in the certification forum, and ask for feedback.
@AldhairGarza wrote:
1. Property Node Error wire?
Should I wire the error input and output of the Property Nodes? I think it looks messy when I do so.
If you want to pass the CLD, you have a better chance wiring at least the error out of everything.
It might makes little sense to wire the error of a "value" property (unless for synchronization), but you'll loose CLD points if you don't.
@AldhairGarza wrote:
2. Bundle Control and Indicator References outside of the Main Loop or in a case inside of the Main Loop?
Before the loop.
Might as well put the references in a Init VI, part of a class. Than use a Update VI to set the values.
If you insist of using a FGV, you'd set the FGV references before the loop, or in a init state of the state machine. It really doesn't matter that much.
I prefer a class, because at least I can track the wire and see where it is used. Also, you can copy (or clone) the VI and have it run two (or n) times in parallel. A FGV can't do that, you need copies of the FGV or an indexing mechanism.
@AldhairGarza wrote:
3. Event Case
If I have a Switch until Release Button I use a Selector to select the the next State depending on the New Value. Is that correct or should I rather do something else?
If it's a switch, Switch until Release Button might be appropriate. I agree, it usually isn't.
Events are more solid\reliable. I'm not sure if you can pass the CLD without an event structure, it might be expected.
@AldhairGarza wrote:
4. Should I really create and use SubVI's?
I think I don't really need to make them most of the time.
Are there any signs to realize "Oh, this must be in a VI"?
You shouldn't make them most of the time. That will give you a few thousand VIs in the four hours 
!
You should make sub VIs when appropriate.
When appropriate, you should make sub VIs.
I think 5-15 VIs are good for a CLD.
I'd wrap most of the functionality in classes, and probably end up with 20-40 VIs for a CLD. All very, very simple VIs!
A good VI should do one (and just one) thing very well.
@AldhairGarza wrote:5. Update Indicators
I use a Case callled "Update Indicators" in order to update the indicators like the Status Message and other indicators. Is it ok? Or should I use a FGV to Update Indicators? I Think a FGV is easier but I don't know if it is recommended.
A state (case in a SM) would work. The FGV will work. A class will work (better 
).
I don't think this matters much for the CLD. As style goes, a 5 out of 10 is sufficient to get all the points (15 IIRC).
I wouldn't worry about it too much. If you feel confident about FGV, use them. If you don't feel confident about other techniques, don't do that for your CLD. Pick it up at a later time, because even if you don't like them (OO, AF, (D)QMH, etc.), learning about them empowers you as a programmer.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:It might makes little sense to wire the error of a "value" property (unless for synchronization), but you'll loose CLD points if you don't.
You will lose points for using the Value property node. Direct terminal or Local Variable (if you MUST).
@crossrulz wrote:
wiebe@CARYA wrote:It might makes little sense to wire the error of a "value" property (unless for synchronization), but you'll loose CLD points if you don't.
You will lose points for using the Value property node. Direct terminal or Local Variable (if you MUST).
Yep. I know, because I lost some points on that 
.
I'm not sure about the current style guide, but some rules where pretty silly.
Like not allowing to use the default value on outer terminals (of multi case structures).
Or, even worse, the rule that you should always use "size to fit" on comments, and use enters to get multiple lines. A really terrible idea, IMHO.
wiebe@CARYA wrote:
@AldhairGarza wrote:
1. Property Node Error wire?
Should I wire the error input and output of the Property Nodes? I think it looks messy when I do so.
If you want to pass the CLD, you have a better chance wiring at least the error out of everything.
It might makes little sense to wire the error of a "value" property (unless for synchronization), but you'll loose CLD points if you don't.
@AldhairGarza wrote:
2. Bundle Control and Indicator References outside of the Main Loop or in a case inside of the Main Loop?
Before the loop.
Might as well put the references in a Init VI, part of a class. Than use a Update VI to set the values.
If you insist of using a FGV, you'd set the FGV references before the loop, or in a init state of the state machine. It really doesn't matter that much.
I prefer a class, because at least I can track the wire and see where it is used. Also, you can copy (or clone) the VI and have it run two (or n) times in parallel. A FGV can't do that, you need copies of the FGV or an indexing mechanism.
@AldhairGarza wrote:
3. Event Case
If I have a Switch until Release Button I use a Selector to select the the next State depending on the New Value. Is that correct or should I rather do something else?If it's a switch, Switch until Release Button might be appropriate. I agree, it usually isn't.
Events are more solid\reliable. I'm not sure if you can pass the CLD without an event structure, it might be expected.
@AldhairGarza wrote:
4. Should I really create and use SubVI's?
I think I don't really need to make them most of the time.
Are there any signs to realize "Oh, this must be in a VI"?You shouldn't make them most of the time. That will give you a few thousand VIs in the four hours
You should make sub VIs when appropriate.
When appropriate, you should make sub VIs.
I think 5-15 VIs are good for a CLD.
I'd wrap most of the functionality in classes, and probably end up with 20-40 VIs for a CLD. All very, very simple VIs!
A good VI should do one (and just one) thing very well.
@AldhairGarza wrote:5. Update Indicators
I use a Case callled "Update Indicators" in order to update the indicators like the Status Message and other indicators. Is it ok? Or should I use a FGV to Update Indicators? I Think a FGV is easier but I don't know if it is recommended.
A state (case in a SM) would work. The FGV will work. A class will work (better
I don't think this matters much for the CLD. As style goes, a 5 out of 10 is sufficient to get all the points (15 IIRC).
I wouldn't worry about it too much. If you feel confident about FGV, use them. If you don't feel confident about other techniques, don't do that for your CLD. Pick it up at a later time, because even if you don't like them (OO, AF, (D)QMH, etc.), learning about them empowers you as a programmer.
1. I totally agree with you here. I wire the error input and output of a property node only if I need to enforce dataflow or I'm expecting a runtime error, but you will lose points if they aren't wired. The reasoning here is that they need to see that you understand dataflow. Not wiring the property nodes can either be the result of "advanced" programming methods, or rookie mistakes. A related subject: you run the risk of losing points if you don't have error/no error cases for your subVIs.
2. I kind of disagree. The ROI on creating classes just isn't there. For me, at least. Simple is better, here. Just make a typdef'd cluster for all your references.
3. I don't think you need an event case to pass the CLD. Simple state machine works, but I used a QMH because that's what I'm used to.
4. For the CLD, make a few subVIs so they know you know how to make subVIs. Make more if you don't think you'll get all the functionality points. You can make placeholders for all your functions and leave them with notes if you haven't started them, or simply remove them if you haven't completed them.
5. Again, I don't think the ROI on classes is worth the effort. Simple is better. They don't expect you to be able to wield classes, and you don't get "extra credit" for them.
@billko wrote:1. The reasoning here is that they need to see that you understand dataflow. Not wiring the property nodes can either be the result of "advanced" programming methods, or rookie mistakes. A related subject: you run the risk of losing points if you don't have error/no error cases for your subVIs.
I'm not sure that is the reasoning. I always thought that you simply loose points because the style guide says "you must wire output error". You could be right, of course.
@billko wrote:2. I kind of disagree. The ROI on creating classes just isn't there. For me, at least. Simple is better, here. Just make a typdef'd cluster for all your references.
I could have been more clear on that.
When saying "I prefer", I mend that I'd make classes. Simply because I'm so used to doing that, it's the default for me.
@billko wrote:3. I don't think you need an event case to pass the CLD. Simple state machine works, but I used a QMH because that's what I'm used to.
IIRC, there is actually a requirement that you must use a type defined enum used in a state machine? And "instant disqualification" if you don't. Just like when you remove the staples (which is the silliest thing ever, IMHO).
@billko wrote:
4. For the CLD, make a few subVIs so they know you know how to make subVIs. Make more if you don't think you'll get all the functionality points. You can make placeholders for all your functions and leave them with notes if you haven't started them, or simply remove them if you haven't completed them.
The placeholders work great for CLA, I'm not sure if it does anything for CLD.
@billko wrote:5. Again, I don't think the ROI on classes is worth the effort. Simple is better. They don't expect you to be able to wield classes, and you don't get "extra credit" for them.
I'm not sure why a class with two functions (e.g. "init" and "set values") would be more work than a FGV with two functions? I'd make a class faster actually. There'd actually be less nodes\wires in total. The two VIs will be two simple VIs in stead of one more complex VI. YMMV of course, we're all opiniated towards what we're used to. But I did "old school" for 15 years, so I do know both sides very well.
But by all means, if you are not used to programming properly object oriented, don't start on or right before the CLD!
OO helped me a lot with the CLA. The CLA requires a more advances strategy, without actual implementation. OO fits the requirements really well (based on the example(s), we're not allowed to talk about the real exams).
For CLD, OO is indeed tricky. The CLD, as I see it, is realistically a 2 days project (when it includes a few iterations of testing, bug fixing, etc.). It's not uncommon for a OO project to spend 25%-40% on analysis and design. That means at a CLD, you don't get past the OOA and OOD in the 4 hours you get, unless you can literally dream the solution in OO. It's a bit sad, because I think it discourages proper engineering principles (design, not OO per se). The CLD is mend to test your LV skills, not the engineering skills, but still...
wiebe@CARYA wrote:
But by all means, if you are not used to programming
properlyobject oriented, don't start on or right before the CLD!
A-ha! That's what I was trying to get at, but I wasn't quite sure what I was saying until I read that. It's part of what we were both talking about going with what you feel comfortable with.
@billko wrote:
wiebe@CARYA wrote:But by all means, if you are not used to programming
properlyobject oriented, don't start on or right before the CLD!A-ha! That's what I was trying to get at, but I wasn't quite sure what I was saying until I read that. It's part of what we were both talking about going with what you feel comfortable with.
Especially at a CLD. Outside the CLD, getting out of your comfort zone every now and than is highly recommended 
.
I thought I had a good grasp of OO when I did the CLD. I used it a lot in an existing application. At the CLD, I figured I could do a state pattern (not a state machine). I didn't practice it, I just read about it in a C++ context. I do not recommend that. The state pattern is great, but it's not something you want to figure out during the CLD! I figured it out in time, but it was close.
wiebe@CARYA wrote:IIRC, there is actually a requirement that you must use a type defined enum used in a state machine? And "instant disqualification" if you don't. Just like when you remove the staples (which is the silliest thing ever, IMHO).
Nope. You can use whatever design pattern you want. What matters is that you meet the requirements and show good style and documentation. But the CLD exams tend to be a perfect fit for a simple State Machine.
