Does it matter where you place terminals on the block diagram?

[pretech]

Something I haven't seen discussion on is where to place control and indicator terminals on the block diagram.

My preference is to place them all in one place, initialize them, and connect them with variables, property nodes, references, etc.

I used to use a stacked sequence and put them in the first frame, but now I tend to use a state machine.

I realize that these actions aren't always necessary, but doing it this way with everything seems clean and logical to me.

But a lot of programmers have terminals all over the place, sometimes wired and sometimes not.

Why do people place terminals the way they do?

Are there any technical or performance issues which would have a bearing on where to place terminals?

Jonathan.

[James.M]

The short answer: you can put terminals wherever the hell you want unless there's a functional reason to put it elsewhere.

In subVIs, I always put my controls on the left, and indicators on the right. This is usually corresponding to how the pane terminals are arranged and makes the dataflow easy to track.

You should always read or write using the terminal (wire it) unless you have no need for the data that way. Example: Tab Control, if purely cosmetic, doesn't need to be wired.

You should place your terminals in a location best for finding relevant code. If you have an event structure case for a control, put the terminal inside the event case.

There are no performance issues, just functional issues, that can arise from terminal placement. If you have a boolean control that is latching, it won't latch if the terminal isn't in the right place.

[Bob_Schor]

A general convention (borne out by most of NI's functions) is that inputs are on the left, outputs on the right, and data flows from left to right.  In placing terminals on the Block Diagram, your objective should be to make it easy for the Human reader to quickly find the Inputs and Outputs, and to have the order have some mnemonic meaning.  If you use the 4-2-2-4 connector pane, with Error In and Out on the lower outer corners, then you may find it "easy on the eye" to group all the inputs on the left, in the order they appear on the Connector Pane, and all the outputs on the right, with corresponding terminals at the same level (which tends to make the Error Line run straight, left-to-right, with no bends or kinks).

Grouping (and aligning) the inputs and outputs makes a "cluster of important stuff" that draws the eye to the inputs and outputs.

Note that this is how I would organize a sub-VI, which (in my hands) rarely has more than 6-8 inputs and outputs.  A complex Top Level VI, with hundreds of controls and indicators, ... never mind, with hundreds of controls and indicators, it's a Mess Waiting for a Disaster ...

Bob (my $0.02) Schor

[RavensFan]

The statement "place them all in one place" scares me.

Don't use property nodes, local variables, or references unless you absolutely have to.  Use wires.  Put terminals where they are most useful.  You can always right click on a control/indicator (or a local variable on the block diagram) to find where the terminal is.

I've seen many diagrams on the forums where all the terminals are nice and neatly stacked on the left side of the diagram, unused, then the programmer proceeded to abuse local variables within their actual code.  That is a bad programming practice.

[James.M]

If you have a specific VI with a bunch of terminals that you are questioning, feel free to post it here and we can give you pointers on if you're doing anything funny.

[crossrulz]

---

@pretech wrote:

My preference is to place them all in one place, initialize them, and connect them with variables, property nodes, references, etc.

---

I find that harder to read.  The terminals should be with their relavant code.  If you are using local variables, you just at least doubled your memory footprint (each local requires a copy of the data).  If you are using property nodes for the value, you just slowed down your system A LOT (a property node is 10,000x slower than a local variable).

If you have a proper state macine, then you usually only need to access a value in one state.  So the terminal belongs in that state.  If you are using an event structure, the terminals belong in their related value change event case.  This is especially true for latching boolean controls.

But the biggest reason I find for NOT putting all the terminals in one place like you describe: it makes it really hard to find the relavant code.  There is nothing quite like double-clicking on a control and be instantly taken to the terminal of on the block diagram and seeing the relavant code.

[pretech]

No, I'm not referring to anything specific. It's just how I have evolved my default way of creating a VI.  I'm mostly self taught, and as I delve deeper into the discussion forums

I find all sorts of things which I'm doing "wrong". It's good to knock bad habits in the bud before they produce too much fruit!

[pretech]

Yes, I know the value property node is heaps slower than using a variable, and I don't use it unless I really need to force sequencing for that reason.

That begs another question. Are other property nodes also slow? I guess they are, but they have to be used to do the things they do.

[crossrulz]

---

@pretech wrote:

That begs another question. Are other property nodes also slow? I guess they are, but they have to be used to do the things they do.

---

Using a property to anything on a front panel will force the panel to redraw.  This accounts for some of the slowness when it comes to the value property.

[altenbach]

---

pretech wrote: 

I realize that these actions aren't always necessary, but doing it this way with everything seems clean and logical to me.

---

That's probably an illusion. I would love to see some of your typical programs to see if you are actually serious or are just trying to incite a flaming discussion. 😮

Having the controls and indicators disconnected and writing via local and value properties can cause many problems.

• The use of local variables blurs he distintion between controls and indicators, becaue their usage mode is not related to the mode of the terminal.
• The lack of data dependency can cause race conditions. At any given time, it is difficult to tell what part of the code modified the data last or where it has been. Using wires between terminals tells you immediately where the data is coming from.
• Local variables force extra data copies in memory. This can get very expensive for large data structures (clusters & arrays).
• Value property nodes are extremely expensive because they execute synchronously. Local are better but using the terminals is best.
• In a proprly designed code the wire is the variable. Abusing front panel objects for data storage is almost never necessary. Their purpose is user interaction, not data storage.