8.2 Block Diagram

   

---

8.2.1 General Layout Standards

• Make diagrams as compact as possible while still having a visible flow.

• Don't cram your block diagram.

• Enforce Sequences. Don't leave structures floating. As well as looking bad it can lead to inconsistencies in the program.

• Place any terminals that have no wiring in the first structure of the diagram. They can look like mistakes if left floating.

• Try and keep the overall size of the diagram to one page of your screen. If it's bigger, try and keep 1 page wide or 1 page deep so that you only need to scroll in one direction. A page can be whatever your standard screen resolution is; we try to keep it to 1,280 by 1,024 pixels.

8.2.2 Wiring Standards

• Use left to right data flow. Resist the temptation to stick data into structures from the top or bottom.

• Wires should only overlap if there is no alternative.

• Keep wires as straight as possible.

• Never route wires through an icon to a terminal on the other side of the icon.

• Never route wires underneath structures or icons.

• Don't use local variables just to avoid long wires! Every local variable that reads the data makes a copy of it.

• Reduce the number of zigzags by aligning inputs and outputs. Use the cursor keys to take kinks out of your wires.

• Delete excess wires, such as loops .

• Try to keep parallel wires evenly spaced even around corners.

8.2.3 Labeling Standards

• Every frame in a Sequence, Case, or Loop structure should have a descriptive comment. These should be indented if there are embedded structures.

• Use free labels on long stretches of wire to label the data. Place the label right on top of the wire with a transparent background.

• Comments for wiring shall have a white background with no border. A bordered comment could be mistaken for an icon.

• When a VI is loaded on a different platform, the fonts adapt to that new platform. On the front panel, LabVIEW tries to move the labels so they don't overlap the controls. It does not do this on the diagram. It's best to place labels below the objects they describe, so when they grow and shrink on the bottom and right sides, they stay next to the object. If you place a label to the left of its object, right-justify it so that it grows to the left.

• Use the labels for Boolean cases to document the case states. This not only improves the readability of your code but it also helps with a program's logic. You will find that the simple act of documenting a logical case will stop you from getting tied up with the ORs, ANDs, and negative logic.

• Use the labels on While Loops and For Loops to document their purpose.

• Label shift registers with their data contents.

• For labels and constants use Size to Text and Carriage Returns for each line.

• Standardize on Fonts and Styles.

• Highlight comments with a yellow or pink background to emulate a highlighter pen. We don't use this but thought it was reasonably neat and worth suggesting.

8.2.4 Self-Documenting Example

The simple diagram in Figure 8.4 is not actually conveying any information, and there are also several uglies in there as well. A little bit of tidying up will work wonders for its readability. LabVIEW is an iconic language ” spend a couple of minutes on an icon and it's time well spent. Enforce the left to right rule, add a few labels, and you'll witness a vast improvement, as Figure 8.5 demonstrates . If you do this from the start, it takes about the same amount of time to do it neatly as it does to make a mess of it.

Figure 8.4. Can you guess what it is yet?

Figure 8.5. Aha, it's a scope.

By changing the Select Channel U32 to an enumerated type we can make the case statement more descriptive. We can also apply clear constraints on the Channels as a postcondition (you can also do it using the data range option for a number, but it isn't particularly visible and can lead to unpredictable program behavior).

Hey, where are all the labels in Figure 8.6? If you think about it, the typing of labels is a weakness. It's extra work that doesn't add anything to the program. It is purely there for the reader. If there is complex logic or algorithms use labels to explain them, but the use of enumerated types in your programs actually reduces the need for manual labeling.

Figure 8.6. Get rid of the constants and we'll be in business.

---

Top