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

[Ben]

I will let the others speak to top level VIs and pop-ups but as to sub-VIs that are expected to handle large data sets we have to get down into the mud that is discussed in the classic post "Clear as Mud".

Ben

[Kyle97330]

Something I am a bit surprised that nobody has mentioned yet is that you probably don't want to put indicator terminals inside of case statements or event structures, or at least not ones that aren't guaranteed to execute (i.e. if the only way to stop a VI is to go through a "Stop" frame in the structure).

The reason for this is that the VI will behave differently when one of the terminals is wired to the connector pane as an output.  If you run the VI with an unconnected terminal and the case with the terminal in it doesn't execute, the value remains the same as it was before the VI ran.  However, if you run that same VI as with the connector pane hooked up and the terminal's case doesn't execute, the default value from the terminal is the output instead.  

This is mostly a problem if you're using a VI that you sometimes run as a sub VI and sometimes as a top VI (i.e. for debugging) but can also cause issues if you're using local variables or property node to read back the values of the indicators on the screen (though as was said before, this should be rigorously avoided).

Plus, if you bury your output terminals in frames where you can't see them for SubVIs with multiple outputs, it's possible to forget about that one particular output and fail to check to see if you have to adjust its value when altering the VI to change some of the other output values.

So for that reason I always put my indicator output terminals at the right side of the screen outside of all frames, but I will quite often bury input controls inside the code whereever they need to be used (especially if there's only one relevant frame of a case or event structure that uses that input).

[Ben]

Hi Kyle,

If I reacll corectly that is touched on in the Clear as Mud thread that I linked above.

The simple take-away mesages from that thread (it is a good read from Greg McKaskle one of the top R&D guyes for NI and someone I count as an early mentor) is;

All terminals on the Icon connecor should be located on the "root" of the diagram.

Where:

Root = The blank part of the diagram, not inside any structures

There is a check in VI Analyzer that will search for and find all instance where that rule is broken. 

Take care,

Ben

[James.M]

---

@Kyle97330 wrote:

Something I am a bit surprised that nobody has mentioned yet is that you probably don't want to put indicator terminals inside of case statements or event structures, or at least not ones that aren't guaranteed to execute (i.e. if the only way to stop a VI is to go through a "Stop" frame in the structure).

---

I think this just goes along with understanding how an indicator works. It holds whatever value you've last written to it. Putting it outside your structures forces you to set a value to it even if the main case you care about doesn't operate. Leaving it inside a case means it will hold the value from that case.

Also, what you're describing is the effect of indicator location within a subVI. I put my indicators all over the place in my top level VIs because they get updated from all over the place.

[pretech]

---

@altenbach wrote:

---

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. 😮

---

You're sort of right! I did want a discussion, but  "Initiate a sensible discussion" rather than "incite  flaming discussion" would be closer to my reason.

I haven't got any particular problem with my programs (in this regard at least!) but as a self taught programmer who comes from a different discipline

one of the principles I'm discovering that just because something seems sensible to me doesn't mean that it is the most sensible way to do it.

And the code usually works, so there's no indication that there is a better way.

Many of my advances in LV programming have come from looking at VI's which people have posted, and reading the discussions on the forums.

These are a goldmine for me because I work for a very small company which cannot afford the luxury of training courses for a software tool which we

don't even use all the time, just when a project requires it. So, a big thank you to all who contribute to the website, people like me really appreciate it!

[Blokk]

Just some reading for you:

http://download.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf

Pay special attention to page 6.

Also this is valuable reading:

http://www.ni.com/newsletter/51735/en/

[pretech]

---

@Blokk wrote:

Just some reading for you:

http://download.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf

Pay special attention to page 6.

Also this is valuable reading:

http://www.ni.com/newsletter/51735/en/

---

The CLD exam document looks interesting. Some of the topics I would have no trouble with, but others are still beyond me!

I'm probably between CLAD and CLD level.

I've read the rookie one before. Always good to revise these things though!