Allow Array of Error Rings

[Hooovahh]

I realize this might be a technical limitation of LabVIEW, but I would find it helpful at times to be allowed to have a constant on the block diagram that had the data of a 1D array of Errors, but interacted in a way like an array of Error Rings.  An Error Ring is an XNode, and I doubt NI thought about allowing an array of them, since behind the scenes this can be thought of as a normal VI.  But still if possible I'd find this feature useful for readability of software since you can see the error code, and see the error it corresponds to.

[AristosQueue (NI)]

The problem with this approach has nothing to do with limitations of LV tech -- I could make an array hold onto an XNode given enough code. But each one of those error values is going to call the Call Chain primitive to populate their error cluster. That's very expensive when you're only going to keep one. Also, stacking them in an array like that would remove one of the prime uses... adding parameterization to the various error values.

I don't think this idea is the right direction to be going unless you wanted to retain all of those errors. The case structure with an error cluster in each frame is preferable syntax, I believe, if not for coding space then for functional correctness.

To achieve your goal of having all the errors on one diagram and then picking one, I think perhaps we would have to build a new XNode that was growable to show multiple error rings (with parameters) and incorporated a top-most enum terminal for selection so that only one of those values actually got built. In other words, the array constant and the Index Array in a single node.

Do you have any suggestions for what that might look like?

[AristosQueue (NI)]

PS: You can achieve your goal today by dropping N error rings and then using Build Array to create the array. The performance overhead will be the same as if we had built an array "constant." I put constant in quotes because the Call Chain information makes this not a constant at all.

[Hooovahh]

So honestly I thought of this idea after posting this idea.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Clear-Errors-Polymorphic-Inputs/idi-p/3129183

There I was requesting the Clear Errors accept an array of errors to clear.  And I thought for readability if all errors to be cleared could be seen as an error ring, then it would make it even better.

When posting this example I had to come up with an image that expressed taking an array of errors, and the first thought was a selector.  In this case you are right I would probably just stick with a case statement with one error ring in each.

And the build array with error rings isn't terrible which can be done today.

Is Call Chain a huge over head?  Or did you just mention it because it can be optimized away if you are not going to use its output?  I've never really thought about what it takes to perform that operation and assumed it wouldn't be too bad, maybe because it is a primitive.

[AristosQueue (NI)]

Call Chain is a pretty serious function compared to most primitive operations. It's a lot of pointer following (climbing from dataspace to dataspace), which means it isn't just operating on local data... that can cause register cache spills. The information that we collect as we do the climbing triggers array building and string copying. Then that array gets built into a single formatted string by the Error Ring -- more movement.

Is that a lot of work? Depends on the overall work of your application. It's certainly pretty hefty when compared to doing nothing. One "no-op" is pretty fast. 🙂

[Darren]

 National Instruments will not be implementing this idea. See the idea discussion thread for more information.