Connecting Error Cluster to Bottom of VI

[jhoehner]

Hello All,

First time LAVA poster here with my first question. Why do some LabVIEW programmers insist on wiring the error cluster to the bottom of their VI as opposed to the sides as shown in most NI documentation. Is there any benefit to it? Is it 100% a preference thing? Is there a way to make LabVIEW connect error wires like this automatically?

I've only seen it in advanced LabVIEW code from experienced programmers and some parts of the Actor Framework.

Your insight and experience is appreciated! 

[Jordan Kuehn]

A good use case is when you encapsulate code in a case structure based on error/no error. Common in SubVIs. The error case will usually have the error wire running straight through, while the non-error case may have many VIs that *do stuff* and don't necessarily align error wires together. I don't usually drop the line back down to the base reference in between VIs, but there are times that I'll put a few in a row, drop back down, and then come back up for another batch. It's purely cosmetic. 

[hooovahh]

Purely cosmetic.  That being said I do have a preference.  Inputs go in on the left, and outputs on the right, not from the bottom unless the terminal is on the bottom.  I think it is easier to read this way, but don't get hung up on it.

[smithd]

11 hours ago, jhoehner said:

I sometimes get something like B when I start with A and then I ctrl+drag up in the wrong place :/

Personally I only ever get A, because I use block diagram cleanup, because life is too short. People have a semi-constant level of irritation with me and my code as a result, but 

Edited August 23, 2018 by smithd

[Benoit]

In some cases B is useful like said previously in case structure. especially when type def constant are used and over lap the error and other wire.

cosmetic, but code readability is not only cosmetic.

[Neil Pate]

I generally prefer to lay out my block diagrams with the error cluster in a straight line. It provides a nice datum for aligning code and is the wire most common across diagrams. Having this datum on the diagram results in fewer wire bends which to me "feels right".

I found in the past that if I did not use the error cluster there was generally a slightly messier feel to the diagrams.

Completely personal preference though.

[jhoehner]

Thanks for the insights fellas. 

I think the main points are that it's mostly a preference based thing but could also help/hurt code readability depending on the situation. I will say, after programming this way for about a month (method B in the image above), I do find that I have less wires overlapping the error cluster wire especially when LabVIEW class wires are thrown into the mix. The nodes that live in between the class wire and error wire much more accessible when the error wire comes out of the bottom of the VI. I think my visual preference is to prevent overlapping wires whenever possible...

Different strokes I guess.

Thanks again!

[Neil Pate]

Speaking of classes and style... http://www.walkingthewires.com/2016/02/15/just-passing-through/

[smithd]

Theres also the argument that you should just get rid of any error wire that has no immediate purpose. So...open file? wire it up. Write to file? wire it up. Close file? Why do I care if close file has an error? Nothing hurts my soul more than someone making a math function that has an error in, a pass through to error out, and a case structure around the math. Whyyyyyyy?

Edited August 24, 2018 by smithd

[Neil Pate]

Some interesting reading for those who have not seen it yet.

Turn off Automatic Error Handling :-)

 

An End to Brainless LabVIEW Programming.pptx

[Darren]

9 hours ago, Neil Pate said:

Some interesting reading for those who have not seen it yet.

Turn off Automatic Error Handling :-)

An End to Brainless LabVIEW Programming.pptx

There's also a recording of this presentation available here: http://bit.ly/brainlesslabview

 

[Rolf Kalbermatter]

On 8/24/2018 at 5:05 AM, smithd said:

Nothing hurts my soul more than someone making a math function that has an error in, a pass through to error out, and a case structure around the math. Whyyyyyyy?

It may be valid. The math function may behave badly on wrong or empty data sets. Sure you could detect the actual input arrays to be of valid sizes etc., and a solid algorithme definitely should do that anyways, but the error in is an immediate stop gap to trying to process on data that may have been not even generated because of an error upstream.

I understand that not every function needs an error in/error out but I prefer to have a superfluous error cluster on a VI that may never really be used for anything but dataflow dependency than none, and later when revising the function and having to add one anyhow, having to go everywhere and rewire the function.

Edited August 28, 2018 by rolfk

[hooovahh]

Another reason to have them (but a poor one really) is that using probes I can check the time it takes to execute functions.  These probes generally just operate on the Error data type, but with adaptive probes could likely be made for any anyway.

[ShaunR]

On 8/24/2018 at 6:18 AM, Neil Pate said:

Some interesting reading for those who have not seen it yet.

Turn off Automatic Error Handling :-)

 

An End to Brainless LabVIEW Programming.pptx

Yes and no. I find it useful to find the unhandled errors. When I build the final solution I have a scripting VI that turns it off along with others (like debug enable, VI short names etc).

19 hours ago, hooovahh said:

Another reason to have them (but a poor one really) is that using probes I can check the time it takes to execute functions.  These probes generally just operate on the Error data type, but with adaptive probes could likely be made for any anyway.

There are two error practices that may be being conflated from what you describe and what smithd is concerned with (and Darren describes in his talk) . Having a pass-through error (error in/out with no affecting code) and having a case structure around code with a switch on error; one case of which passes through.

Edited August 29, 2018 by ShaunR

[ShaunR]

On 8/22/2018 at 2:20 PM, jhoehner said:

Hello All,

First time LAVA poster here with my first question. Why do some LabVIEW programmers insist on wiring the error cluster to the bottom of their VI as opposed to the sides as shown in most NI documentation. Is there any benefit to it? Is it 100% a preference thing? Is there a way to make LabVIEW connect error wires like this automatically?

I've only seen it in advanced LabVIEW code from experienced programmers and some parts of the Actor Framework.

Your insight and experience is appreciated! 

The second is usually used when there are multiple inputs and the terminal spacing forces bends in the wires. If you are forced to have bends because otherwise the terminals would overlap to keep the tram-lines, then you might as well make more room on the diagram for labels and controls/indicators so it doesn't look cluttered.

[hooovahh]

2 hours ago, ShaunR said:

There are two error practices that may be being conflated from what you describe and what smithd is concerned with (and Darren describes in his talk) . Having a pass-through error (error in/out with no affecting code) and having a case structure around code with a switch on error; one case of which passes through.

Yes I was referring to smithd stating:

Quote

Theres also the argument that you should just get rid of any error wire that has no immediate purpose.

I was saying one reason (again not a great one but one nonetheless) is that if you do wire up errors with no immediate purpose, it does allow for checking the timing between nodes easier by using the error timing probe.