closed review Filter Error Codes (Error Package)

[Wouter 11]

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.

VI Name:

Supress error

Total VIs:

2

Description:

This VI has a integer (array), error code, as input and when the error code matches the error code on the error wire it supresses the error.

Note:

-

Blockdiagram:

Scalar:

Array:

Code:

Supress Error.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

Edited October 19, 2011 by jgcode

[jcarmody 205]

I use the Structured Error Handler Express VI when I want to supress specific errors. It has quite a bit of functionality. This idea on NI's Idea Exchange is similar. Hopefully, NI will add the SEH to the default pallets. Your post prompted me to submit this idea.

[jgcode 322]

FWIW, I have a similar reuse VI in my library (I think it was originally based on one from an NI course)

Anyway, I would recommended clearing the error as opposed to using the constant (just in case there is anything NI handles under the hood in the future etc...)

I never created an array version (as never have the need) - not saying one wouldn't be useful.

Clear Specific Error.vi

Code is in LabVIEW 2009.

[ShaunR 838]

There is nothing special about the clear error. It is just a control and indicator unwired.

These are my versions of the clear error and clear specific error (you can find them in many of my submissions to the CR) that uses far less realestate and can be placed between property nodes (and similar) without having to route wires around.

Edited October 6, 2011 by ShaunR

[crossrulz 77]

I've had two versions of the array type.

My first attempt uses a for loop. It has the added benefit/feature of inputting an empty array will remove all errors.

My second attempt uses the Search 1D Array and check to see if the resulting index is greater than or equal to 0. This should be a little faster than comparing all of the array and OR the results.

Similar to Shaun, I made the icons small so I can fit them between property nodes.

[jgcode 322]

These are my versions of the clear error and clear specific error (you can find them in many of my submissions to the CR) that uses far less realestate and can be placed between property nodes (and similar) without having to route wires around.

Really?

I had a hunt as to aid the discussion. I could only find this in OPP from your LAVA CR files but I may have missed it?

Your snippet obviously is missing your reuse subVIs - do you mind posting?

Cheers

-JG

I also think the we should polymorphize the API here too for the Error Code input.'

Should we support an array of Errors In too?

This would mean a total of 4 VIs - most likely with the Error In array as a thin wrapper around the above mentioned VIs (no function changes).

I have made this into an OpenG Review.

[ShaunR 838]

Really?

I had a hunt as to aid the discussion. I could only find this in OPP from your LAVA CR files but I may have missed it?

Your snippet obviously is missing your reuse subVIs - do you mind posting?

Cheers

-JG

I also think the we should polymorphize the API here too for the Error Code input.'

Should we support an array of Errors In too?

This would mean a total of 4 VIs - most likely with the Error In array as a thin wrapper around the above mentioned VIs (no function changes).

I have made this into an OpenG Review.

Ahh. I see what you mean (I thought it was at least in Dispatcher-have to check)

Here they are).

Edited October 6, 2011 by ShaunR

[asbo 156]

Only thought is that it's suppress.

[crossrulz 77]

I just updated my second implementation from above to add a check for an empty array being passed in. So now all errors will be cleared if the array is empty (which is currently the default). Is this a desired feature to clear all errors?

Clear error.vi

[jgcode 322]

I also think the we should polymorphize the API here too for the Error Code input.'

Should we support an array of Errors In too?

This would mean a total of 4 VIs - most likely with the Error In array as a thin wrapper around the above mentioned VIs (no function changes).

I think we all agree on the functionality of the VIs which is good.

The only functionality I am unsure of is this:

I just updated my second implementation from above to add a check for an empty array being passed in. So now all errors will be cleared if the array is empty (which is currently the default). Is this a desired feature to clear all errors?

IMO: If you want to clear all errors then you should use the Clear Errors VI.

If an empty Error Code Array is passed in, then it contains no Error Codes and therefore no Errors should be cleared?

Ok, here is the API I am envisaging...

I have gone with the standard size/shape VI given that other Error VIs are of this size (Clear Errors, Merge Errors, Build Error Cluster etc...)

It seems to me even an inline VI size/shape would still get in the way of the outputs of the Property Nodes anyway?

E.g.

The core VIs:

The thin wrappers for Error Array support:

The Polymorphic API:

Documentation:

Here are some examples of inputs/outputs of the API:

Here are the results:

Clear Specific Error.zip

Code is in LabVIEW 2009

[Wouter 11]

Looks good JG. I think we have left one discussion... what kind of icon should the VI have? One that is fits between property nodes or the one we have now?

And I would change the label of "Error Code Matches" to "Error supressed?", I find the first terminology pretty vague namely.

Edited October 7, 2011 by Wouter

[crossrulz 77]

Looks good JG. I think we have left one discussion... what kind of icon should the VI have? One that is fits between property nodes or the one we have now?

I'm for the smaller icon personally.

And I would change the label of "Error Code Matches" to "Error supressed?", I find the first terminology pretty vague namely.

Since this VI is called "Clear Specific Error.vi", it should really be "Error Cleared?".

For the error array VIs, would it make more sense for this indicator to be an array so the user can figure out which error was cleared?

[asbo 156]

I'm for the smaller icon personally.

Since this VI is called "Clear Specific Error.vi", it should really be "Error Cleared?".

For the error array VIs, would it make more sense for this indicator to be an array so the user can figure out which error was cleared?

I'm onboard with everything here. Especially since NI's verbiage uses cleared, that's what users starting with OpenG might look for.

[jgcode 322]

Since this VI is called "Clear Specific Error.vi", it should really be "Error Cleared?".

I agree - I will change Error Code Matches to Error Cleared?.

For the error array VIs, would it make more sense for this indicator to be an array so the user can figure out which error was cleared?

The depends - what are your use cases? Are you going need that information to go back through the array and index out that cleared error or make a decision based on that error etc...? Or do you care that an Error was cleared in the Error Array you passed in? That information is there - you could wrap the Core VI in your own For Loop if needed, it guess its a question of what is the main use case.

We made a similar design decision for e.g. Compare Two Paths when polymorphizing the API:

I'm for the smaller icon personally.

I am still not convinced about this given:

• We currently have two inputs and two outputs, and 4x2x2x4 allows for future expand-ability (not a requirement but a nice to have as we have other methods for dealing with this).
  
• Other Error VIs are of this size (Clear Errors, Merge Errors, Build Error Cluster etc...)
  
• An inline VI size/shape would still get in the way of the outputs of the Property Nodes anyway (from the above images posted)?
  
• New users would be familiar with the iconography in the palette as it is similar to Clear Errors etc...
  

If anyone can provide a list of pros/cons for the smaller icon, please do.

[Jim Kring 111]

Hi All,

This is a great discussion!

In an effort to support this, JKI has decided to donate (to the community via BSD license) a couple relevant VIs into the mix, in the hope that they might contribute some design inspiration to this discussion:

JKI - Clear All Errors and Filter Error Codes.zip

The first VI is called Filter Error Codes and filters either a scalar or array of integer error codes. It also returns the information about the error that was filtered, which is useful for handling that error.

This is what the array implementation looks like:

And, here's what the scalar implementation looks like -- you can see it just calls the array implementation.

The second VI is called Clear All Errors, which is just like NI's Clear Errors, but a lot more compact, which is nice

Cheers!

[jgcode 322]

In an effort to support this, JKI has decided to donate (to the community via BSD license) a couple relevant VIs into the mix, in the hope that they might contribute some design inspiration to this discussion:

Awesome - thanks!

Quick design question - why pass out and maintain a new data-type (which is a subset of Error cluster) when an Error cluster could just be passed out?

Cheers!

-JG

[Jim Kring 111]

Quick design question - why pass out and maintain a new data-type (which is a subset of Error cluster) when an Error cluster could just be passed out?

Great question! We actually had a long debate about this at JKI, back when this function was designed.

If I recall correctly, here is the thinking behind it:

• it avoids the possibility of accidentally confusing (miss-wiring) the filtered error details with error out
  
• most of the time (e.g. the scalar error code to filter use case) you only care about the Boolean output error filtered? (e.g. wiring it up to a Case Structure's case selector or similar) so we decided to make that raw Boolean an output of the VI, rather than requiring the user to unbundle it from the filtered error details.
  
• in the case where you want more information about the filtered error (like if you passed in an array of error codes to filter and need to know which one occurred), then you can unbundle the code or source string from the filtered error details cluster.
  
  • We didn't include the Boolean error filtered? in the filtered error details cluster since that would be redundant (the Boolean is already an output of the VI). And, if we did actually add the Boolean error filtered? to the filtered error details cluster, then it would look a lot like an error cluster and we would then probably want to name the Boolean status (since that's what it's called in a normal error cluster), which does not convey the intent nearly as well as calling it error filtered?.
    

And, after years of using this VI, I don't have any complaints about the design of the VI (and haven't heard any complains from others at JKI)

[Wouter 11]

What is exactly the functionality/use of the 'upstream error'?

[jgcode 322]

What is exactly the functionality/use of the 'upstream error'?

It e.g. allows you to check for an error from a specific task, handle it (e.g. clear it) whilst persisting error information from previous code (upstream).

Normally I would merge this external to the VI, but I like the fact that the merge is included in the VI (one less thing to do).

[Jim Kring 111]

It e.g. allows you to check for an error from a specific task, handle it (e.g. clear it) whilst persisting error information from previous code (upstream).

Normally I would merge this external to the VI, but I like the fact that the merge is included in the VI (one less thing to do).

That's right. It's a real space saver to not have to merge errors as a separate function call. And, this is a standard that I hope can be adopted, if others agree that it makes sense.

Note: I think we should add this "upstream error" to the "Clear All Errors" function, too.

[jgcode 322]

That's right. It's a real space saver to not have to merge errors as a separate function call. And, this is a standard that I hope can be adopted, if others agree that it makes sense.

Note: I think we should add this "upstream error" to the "Clear All Errors" function, too.

Here is an example of Clear All Errors with the Upstream Error, pretty simple BD:

Can anyone help with the Connector Pane

3x1x1

Shows the Upstream coming in from the top in context help (although you can wire it from the bottom).

5x3x3x5

(Note: Upstream will actually be optional, I was just playing around with the CP).

What are peoples thoughts on the VIs that Jim has donated?

Personally aside from the Upstream Error feature, I like that the core VI is the Array and the Scalar is the wrapper so there is only really one lot of code to maintain.

Another question following on from my previous ones - there is enough CP outputs to output all three cluster elements separately (as opposed to the boolean and new cluster) - was there a specific reason not to do this?

Clear All Errors.vi

Code is in LabVIEW 2009

[Jim Kring 111]

Can anyone help with the Connector Pane (note: Upstream will actually be optional, I was just playing around with the CP).

Here's a conpane that gets one step (another pixel or two) closer.

Clear All Errors.vi

One comment that I want to make, that's actually a case for note adding an Upstream Error, is that it's possible to easily misswire the Error in (error to be cleared) and the Upstream Error. And, if misswired, the result is exactly the opposite of what users would intend -- that would lead to quite an insidious bug. However, Error In (error to be cleared) should probably be made a Required Input, which would certainly help users identify if they accidentally misswired in a way that left Error In (error to be cleared) unwired.

[jgcode 322]

However, Error In (error to be cleared) should probably be made a Required Input, which would certainly help users identify if they accidentally misswired in a way that left Error In (error to be cleared) unwired.

Yer, that was my though too from the initial CP I posted:

Or we could leave it out (no Upstream Error as per the example you posted)?

[Jim Kring 111]

Yer, that was my though too from the initial CP I posted:

Or we could leave it out (no Upstream Error as per the example you posted)?

The pitty is that in almost every instance where I use Clear All Errors, I use Merge Errors to merge in upstream errors. So, I think it's a really useful design pattern. My vote would be to make the Error In a required input.

[Wouter 11]

Maybe make the icon just as large as the normal clear icon...