02-23-2016 04:21 PM
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.
02-23-2016 04:27 PM - edited 02-23-2016 04:31 PM
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.
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
02-23-2016 04:34 PM
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
02-23-2016 04:40 PM
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.
02-23-2016 04:41 PM
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.
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
02-23-2016 04:47 PM
@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.
02-23-2016 05:00 PM
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!
02-23-2016 05:06 PM
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.
02-23-2016 05:36 PM
@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.
02-24-2016 12:40 AM
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.