Jump to content

Connecting Error Cluster to Bottom of VI


Recommended Posts

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! 

Capture.PNG

Link to comment

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. 

  • Like 1
Link to comment
11 hours ago, jhoehner said:

Capture.PNG

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 :rolleyes:

Edited by smithd
  • Like 2
Link to comment

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.

Link to comment

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!

Link to comment

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 by smithd
  • Like 1
Link to comment
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 by rolfk
Link to comment
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 by ShaunR
Link to comment
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! 

Capture.PNG

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.

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.