LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Error Ring Error in

It would help if the Error Ring had an error in.

Error Ring Error In.PNG

 

Now we always have to use a merge error (A).

 

This does hurt performance as well (B), as Error Cluster From Error code is always called (and isn't lightweight).

 

With an error in, no more merge errors (C)!

 

And performance gain (D) as a bonus.

 

Guess this input is deliberately not there? Can't wait to hear the arguments against it...

17 Comments
Proven Zealot

> Now we always have to use a merge error (A).

 

Not exactly... you could put the error ring inside a case structure.

 

This idea is essentially a duplicate of this one:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Error-Ring/idi-p/2351100/page/2#comments

Proven Zealot

No arguments against. Just didn't include it in the original, and the case structure has sufficed, so no priority, especially given the annoyance of the mutation and save for previous code.

Trusted Enthusiast

>This idea is essentially a duplicate of this one:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Error-Ring/idi-p/2351100/page/2#comments

 

That one is with Booleans (didn't find it when searching), it won't help with the merge errors.

 

If the XNode would accept both (maybe even at the same time?), that would be great! Then we can conditionally add it, but it won't previous existing errors.

Example Gatekeeper
Status changed to: Declined

National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.

DNatt, LV R&D
Trusted Enthusiast

That's unexpected.

 

The proposed solution of putting it in a case structure will clear warnings. The case in the XNode could prevent that. So to avoid automatic performance, clear wire flow and convenience, we need to wrap each and every error ring in a case structure, AND use a merge error.

 

I'm confused.

 

Not sure what the downside is of the proposed idea? (except "save to previous", which hopefully should not stop progress.)

Proven Zealot

Darren was trying to state the workaround, not state a reason why this wasn't going to be done.

Trusted Enthusiast

Declined: National Instruments will not be implementing this idea. Given the execution overhead of the node, the Error Ring should be called conditionally in a case structure whenever its value is needed at run-time.

 

Sounded like it to me.

 

So what is the reason?

Member

You mention putting the ring in a case structure clearing warnings.  How would that be?

 

If you are appending an error to the wire, the error will override the warning.  If you are appending a warning to the wire, the previous warning will take priority.  If the wire already has an error, the error case would be called and the previous error would pass through.  This would be the case regardless of whether you use a case structure, a select node, or your idea.

Trusted Enthusiast

You're right. I was already caught up a bit on the conditional error ring idea:

Error Ring Clear Warnings.PNG

Then the warning will be lost, even if the ring produces no error. Maybe in some corner cases it will still be an issue, but normally it won't.

 

The hole optimization problem is not really an issue altogether, as it will only save time when there error in is true. There's usually no need to optimize for exceptional (error) cases. It will help the flow and speed up development though.

Proven Zealot

As much as I'd use this, I agree that leaving it up to the developer might be the best way to handle this.  Forcing them to add a merge error and then figure out what error should take priority is probably a good idea, rather than having a brainless developer (myself included) just wiring in errors instead of thinking about why and the consequences. 


Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
Interesting in learning all you can about automotive CAN bus communication? Checkout my 12 part CAN Blog series.
Checkout and help contribute to the community driven LabVIEW Wiki.