How do you make straight wires vi very quickly

[sunflower2772]

I heard 2 things about CLD exam:

1. Many more logics than the sample questions, no time to complete all functionalities in 4 hours, even with very fast coding. 

2. The graders are very anal about straight wires. 

Having a brain with not much RAM ..... In order to code (real) fast, I tend to code in order to complete functionality first, without caring for beautiful wires. If I code for style simultaneously with functionality, my low RAM brain tend to loose track of what I am doing.

So, I first make a real big while loop and case box, complete functionality coding, producing the diagram below...and then :womanhappy:...click the Clean Up Diagram...but it tends to output even more uglier wires, I have to CNTL-Z... arrange the icons and tunnels one by one to a straight line and then use Clean Up Wire.

But this probably take more time than necessary?  So what is your way of coming up with striaght wires vi real fast? Thanks. 

[Ben]

1) Shut-off auto-routing of wires

2) Drop functions so the allign easily.

3) Allign objects wired together.

4) Right-click wire >>> Clean-up wire

5) When moving an object using the wire keys, the ctrl arrow makes it go 5 pixels but slwo down as the wire gets close to straight. LV will move the bend to half way.

Ben

[smercurio_fc]

Two words: selective cleanup. The only time I ever use the block diagram cleanup is when looking at VIs that inexperienced coders post on these forums. Garish is one word that often comes up. The block diagram cleanup does a pretty good job at making the diagram easier to read. Not sure if it will get past the "anal" () graders of the CLD. What I have found is that selective cleanup does work from time to time. For example, right-clicking on a wire and selecting cleanup wire. Also, lining up subVIs helps a lot. For instance, in your screenshot you can select the 4 subVIs and align to bottom. That will straighten up some wires. You can also select tunnels and align them, straigthening wires. Just some thoughts.

[JÞB]

Sunflower,

speed and style are co-dependant.  The examiners are really looking to see if you have two basic qualities: A firm grasp of software development principals and familiarity with the LabVIEW IDE.

The level of knowledge of the IDE needed to sucessfully complete the CLD exam is really not much more that required to pass the CLAD.  The ability to demonstrate applying that knowledge by translating objectives into requirements, software concepts of the language, dividing it into modules and finally "slinging wires" is what you attempt to prove when you sit for a CLD exam.

Choosing the best archetecture for the objective gains a lot of speed-  (Analogy ahead:  I have a basement that leaks in spring and during heavy rains.  Talked to a contractor about repairs and learned that the house was basically poorly designed and the original plans had included a brick facing that was scratched out - leaving the cinder block foundation protruding beyond the front wall.  I spend a lot of time patching a poorly executed design)

On the other hand- I have, IMVHO, established some level of mastery of software design concepts and the LabVIEW IDE.  I document my code first- then write shells for the modules, then sling wires.  Last, I prove functionality by methods that were pre-determined from the original objective.  Coding by intention-  Its a practice that seams to differentiate abstract art and quality LabVIEW code.

OH By the way-  look at the Options on auto-clean-up tuning.  Play with them and you'll see that changing the "Compatness" both horizontally and vertically can achieve better BD.  Also, turn on the BD grid and enable Snap to grid to help align sub vis controla and tunnels on a BD- Change the grid spacing too! 

[Mark_Yedinak]

I have to agree with Jeff. Truly profient and top level LabVIEW programmers will also be thinking about style as they code. Just throwing stuff on the diagram and needing to come back to do a massive cleanup is double work. WIth practice you start to visualize the code as you write and can generally wire the initial code up pretty cleanly. The cleanup required is minimal (no one can place everything perfectly all the time).

[SteveChandler]

I could not say it better than Mark and Jeff but I will add some comments.

When doing the practice exam (or any code for that matter) pay attention to style as you go. This will slow you down and maybe you will not have enough time. If not then you have identified an area that you need to work on. Very few people complete all the requirements on the exam so don't get too hung up on that. You just need the right balance in the three exam categories to pass.

Some specifics. Learn how to select pieces of code and how to use the alignment tool. Click and surround a section of code to highlight it. Don't worry that you are selecting things you do not want to align or move. Now hold the shift key and click on the things you do not want to align to unselect them. That will toggle the selection so you can add and remove things. Once you get everything of interest in your selection you can drag the whole thing or move it with the arrow keys. The alignment tool will work only on that selection. I find myself frequently holding the shift key, clicking on each vi in a row and aligning to bottom edges. This usually makes all the wires perfectly straight but if not just right click on the wire and clean it up.

Not directly related but I will also add the suggestion that when you create a subvi or typedef fill in the description, tip-strip and icon right away. Don't just think you will come back to it later. When you first create it you already have it open. Coming back to it means extra time.

[JÞB]

---

@Ben wrote:

5) When moving an object using the wire keys, the ctrl arrow makes it go 5 pixels but slwo down as the wire gets close to straight. LV will move the bend to half way.

Ben

---

Of course Ben meant to say "Holding Shift + Arrow"  (Ctl+Arrow does some debug stepping stuff.)  And it will move an object 8 pixels (Thats why I set my grid spacing to 8 ).  This is BD only-  With Snap to grid on the FP Jump size with Shift + Arrow behaves differently