Certification
Show labels on drop
Trying to get all ducks in a row before the CLD this friday. I would like to quick drop items, such as Get Date/Time In Seconds, or Search 1D Array, onto the backpanel, with their labels showing. For some reason I cannot find the LabVIEW backpanel option that will enable the labels showing. Any help appreciated!!
Thanks
As a first step you should not call it "backpanel". I assume you are talking about the block diagram, right?
I am not aware of any option to show labels by default, exept for created diagram constants.
Not exactly a "Label" but my best guess as to what you want. It does show the same text as the help window VI Info "Name" without the Show Paths option. As I recall, this is also the text in the title bar of VIs that show title bars. It is not quite the function's "Label" nor a sub-vi's Name on disc (Although name on disc is default)
But WHY? leave the help window for displaying that information "On-Demand" and have less BD Clutter
For the CLD, I'm trying to make sure I have good comments and documentation. If you could drop, say, a Search 1D Array function, onto the block diagram, with the label showing, it would help do that. Of course I can always just make the label visible, but i was just looking for a quicker way to do it.
Hi Jim,
you will not get any brownie points for displaying vi names as they are not giving any more information than the icon.
You should however give constants appropriate naming labels (or at least a comment next to it) to indicate what they are for.
Generally speaking:
- no default icons (vis and controls) and the icons have to have a header (you could use lvlibs to do that for you)
- subvis with error case structure around it to catch input errors
- all error terminals wired (and if there is a good reason not to wire one: add a comment)
- in subvis all controls/indicators outside of the error case structure (this is actually style)
- every vi needs descriptive comment (5-6 words might be enough) on the BD and every structure also needs a comment (this includes a comment in every case of every case structure ... including every error case structure in subvis ... no slacking off)
- every vi/control needs a description in the vi documentation
- every UI control needs a tip strip (you will have to add them to the existing UI controls)
- last but not least print a help file to html and link the html in the vi documentation (yes, worth 1 point)
There are plenty of points where you can add sensible documentation but in my opinion there is no merrit to displaying vi names for the sake of having more text on the Block diagram.
(This comes from someone who passed his CLD with 10/10 in documentation ... I was less diligent in the other grading areas ;))
Do practice good documentation, it's easy points that you really don't want to throw away.
cheers
Mathis
edit: I dug out a sample exam I did last year preparing for the CLD. It's not perfect, I would have got 7/10 for documentation on this (Better Controls description needed), vi documentation too short (I tried to get away with 2-3 words) and structure documentation too short (same problem). But according to an ex NI employee I would have passed with this.
Meaningful icons are a better method. LabVIEW primatives are easilly recognizable and showing the label would be less helpful than the help window.
Structures should have comments. Either integrated or attached does not really matter (Personally I don't like the Integrated comments in For Loops- to me they look funny for that structure and get worse when your show P and C terminals:smileyfrustrated)
Labels just are not really "Documentation." Comments about what the code does to the data are documentation.
As an example:
The top would be what you produce with showing Labels. The lower is "documented code" I could even Google it if I did not understand the algorithm.
As A side note, just because its a new feature, You can Ctrl+A, Right-Click and set all labels visible.
Thanks for tips! I will need all the points i can get in the easy categories. The verified functionality category scares me the most!
Jeff's point is also very good. The comments I recommended to put should always describe what is happening.
I do however think that labels make sense with constants. In calculations it makes it a lot easier to understand the equation by commenting what the constant is (I use the label as it moves with the constant) or the constant which initialises a shift register in a state machine in which case it is important to know what the function of the shift register is.
If you have a standard architecture that you use (e.g. queued message handler or state machine) it also makes sense to practice to get the skeleton up as quickly as possible. Try to finish coding about 30 min to the end and really concentrate on documentation and correcting style (If you are comfortable with using VI analyzer it can help you to find possible problems). In these last 30 min you can probably easily gain 5-10 points in style and documentation while if invested in coding you can be grateful if you manage to get another 2 points. After all it is a race for points and functionality is only worth 37.5%. So if you would get full marks in style and documentation you would only need 2.5 points of functionality. My peers considered functionality so unimportant that they never even bothered to check it when I asked them to look through my practice exams.
Main advice: Don't panic about functionality. If you submit a fully working piece of code with lacking documentation and bad style you will fail. If you have a piece of code which has half of the functions implemented and good style and documentation you will likely pass.
Good luck tomorrow.
Best regards
Mathis
@JÞB wrote:
The top would be what you produce with showing Labels. The lower is "documented code" I could even Google it if I did not understand the algorithm.
Of course instead of quoting an obscure (:D) algorithm, you could also simply say in plain English what the code segment does. Often a literal code translation of the algorithm is not even needed.
Here's what I would have done....
As I always say: Complex is simpler. 😄
