LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Error In and Error Out Clusters within VIs

Quick question for the LabVIEW experts - I try to include Error In and Error Out clusters ICON terminals in all of my VIs.  My question is however, if I have a VI with code that does not use any error terminals do I need to include Error In and Error Out clusters in that VI?  If my code does not use those terminals I would think that I'd just be passing errors right through this VI and I don't see a purpose of including them.

 

Thanks!

0 Kudos
Message 1 of 24
(1,293 Views)

I can think of two reasons you still may want to carry the error though.

 

Data Flow, this helps keep things in order by passing the error around forcing VIs to be called after other VIs.  If you really want them to run in parallel then don't wire in the error.

 

Skip if error, pass in the Error In, then wire it to a case structure, and put all your code in the No Error case.  This will at least keep your code from running if there is an error.  Just like DAQmx, no need to perform the Read VI if the Init returned an error.  Also it helps speed up a shutdown in case of an error because once the error happens all your code essentially skips doing the stuff it wants.  Just make sure things like Cleanup still run if there is an error.

Message 2 of 24
(1,289 Views)

I fully agree with Hooovahh.  But I do find myself putting less and less error clusters in my VIs simply because I don't need to handle errors in those VIs and/or nothing in my VI with throw any errors.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 24
(1,272 Views)

@crossrulz wrote:

But I do find myself putting less and less error clusters in my VIs simply because I don't need to handle errors in those VIs and/or nothing in my VI with throw any errors.


Not all VIs need Error In and Error Out that's cool.  But If you really don't need Error In or out, you are saying, the flow control through other means is sufficient, no errors the VI can generate are ever useful, and if an error occurs there is no need to skip the VI.

 

For me very seldom does real code not need the things I mentioned, so I'd say in a medium to large sized project I may have written 0-5 VIs that don't have error in or out.

0 Kudos
Message 4 of 24
(1,263 Views)
Basically, the rule of thumb In use is that I include error clusters in one of two situations:

1. The VI can generate an error.
2. The VI might reasonable need to be able to respond to an error.

The first case is pretty clear. A good example of the second case are VIs that I have for things like Wait (ms). If an error comes in, the wait is bypassed. Likewise I have wrappers for the one and two button dialog functions.

Having said that I was hoping that NI was going to follow through with their stated intention to put error IO on the native functions. But that didn't happen -- guess a new icon was more important.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 5 of 24
(1,246 Views)

@mikeporter wrote:

But that didn't happen -- guess a new icon was more important.

SHOTS FIRED!

0 Kudos
Message 6 of 24
(1,231 Views)

@mikeporter wrote:
Having said that I was hoping that NI was going to follow through with their stated intention to put error IO on the native functions.

In case you missed it, there was a good explanation of the choice not to do so, at least in regards to the Wait functions: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idc-p/2772856#M26878

0 Kudos
Message 7 of 24
(1,224 Views)
I hadn't seen the discussion, but I can sum it up in two letters:

B and S

There was not one even halfway legitimate argument in the entire thing. The comment that if we provide the error clusters people will use them, was particularly comical. We have a hard time here getting people to connect up the error clusters on functions that already have them, but suddenly putting them on the wait function is going to cause a mass stampede to using error clusters?

This is one of those times where a decision was made to not implement this change for some reason they didn't want to share and somebody was desperately (and unsuccessfully) trying to reverse engineer an excuse that didn't sound too absurd.

Which brings us back to the real mystery of NIWeek 2014: Why were there no changes in LV that were of any real substance?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 8 of 24
(1,207 Views)

 


Quick question for the LabVIEW experts - I try to include Error In and Error Out clusters ICON terminals in all of my VIs.  My question is however, if I have a VI with code that does not use any error terminals do I need to include Error In and Error Out clusters in that VI?  If my code does not use those terminals I would think that I'd just be passing errors right through this VI and I don't see a purpose of including them.

 

Thanks!


 

I think this is an easy rule that many don't follow: If something can't, and never will, act on an error or create an error, the error wire has no place in the code. The "and never will" becomes more important with objects/dynamic dispatch but is otherwise an easy enough rule to follow.

 

@mikeporter wrote:
I hadn't seen the discussion, but I can sum it up in two letters:

B and S

I can't say I agree with (m)any of the things that aristos posted on the idea exchange, but I've never once gotten the impression that he was BSing people. 

 

As for the idea itself, I personally argue against it. LabVIEW should be a language. Adding a sequence structure and a few wires to a VI is not a language feature.

0 Kudos
Message 9 of 24
(1,174 Views)

@dems wrote:

 As for the idea itself, I personally argue against it. LabVIEW should be a language. Adding a sequence structure and a few wires to a VI is not a language feature.


It's a primitive.  There is no wires nor sequence structure in a primitive.

 

This is one of those that NI and I are just going to have to agree to disagree.  When I see every company out there have a wait function in their library just so they can sequence the wait with the error cluster, that tells me there is something wrong with the core language.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 24
(1,149 Views)