On the Error Ring primitive

[X___]

I recently ran into an interesting problem: some calculations I was doing in which I used parallelized loops were taking an inordinate amount of time (and consuming 100% of my i9 cores).

Turning to profiling to figure out where I might be bugging out or able to find some optimization, I realized that the most active subVI was this:

 Error Cluster from Error Code.vi

There is an interesting discussion elsewhere about why this VI is a nuisance (even in its modernized version), which is compounded by the facts that:

- it is randomly used by NI in its code (some error codes are never converted, let alone passed, so good luck to figure out why your code fails)

- there is no particular discipline (from NI) on how it is used (for instance, random error codes (aka 1) are plumped on the diagram and connected to said ECfEC VI

- it is used in locked VIs (super secret ugly code, presumably)

For kicks, I zapped it and replaced it by a simple version of mine everywhere I could (that is, except in the locked VIs) and reran my calculation. Same symptoms.

The locked VIs were for sure not the problem, as they were not called during the calculation, so I had to find out where this VI was called from and narrowed it down to one caller. I opened up the diagram... and did not find it there.

However, I had two Error Ring "constants" on the diagram which, you probably know that or have figured it by now, I didn't, calls ECfEC.vi. One of the Error Ring, O Irony!, was a "no error" Error Ring "constant" (no comment):

Therefore, merely running that subVI (which was supposed to be quasi-instantaneous), was now launching LabVIEW into the ECfEC.vi maze and hogging my computer.

I have now removed the incriminating Error Rings and moved on, but I thought this potential issue should be better advertised.

My 2 cts.

[Darren]

During code reviews I always tell people to remove 'No Error' error rings and replace them with error cluster constants. As for non-0 Error Rings, they should always be in a case structure that only executes in the situation where you need that Error Ring value.

[X___]

1 hour ago, Darren said:

During code reviews I always tell people to remove 'No Error' error rings and replace them with error cluster constants. As for non-0 Error Rings, they should always be in a case structure that only executes in the situation where you need that Error Ring value.

That's good advice, which could be added to the Help for the Error Ring, for instance...

[thols]

On 4/10/2021 at 1:24 AM, Darren said:

During code reviews I always tell people to remove 'No Error' error rings and replace them with error cluster constants. As for non-0 Error Rings, they should always be in a case structure that only executes in the situation where you need that Error Ring value.

Very interesting. Error rings are so large I am tempted to put them in a sub-VI just for that reason. And if they also always should have a case structure around them...

I agree that it should be documented, and I had a look in the help to see what it said and found that LV2020 displays:

However, LV2019 works. Is it only me? (its only on the error ring, everything else in the help seems to work)

Edited April 12, 2021 by thols
add info

[LogMAN]

1 hour ago, thols said:

Is it only me?

Got the same issue in LV2020 SP1

The page exists, it is just incorrectly linked

[X___]

As a note, a quick performance test comparing dropping a constant or an error ring in a case and running this over and over doesn't seem show much of a difference in  terms of CPU (but benchmarking could probably done more carefully), so I may have just used up bandwidth for not much, as usual... 🙂

[Darren]

I have reported the documentation issues (both the 'page not found' error, and the suggestion about placing error rings in case structures) to R&D as Bug 1413653.

12 hours ago, thols said:

Error rings are so large I am tempted to put them in a sub-VI just for that reason.

Don't forget you can deselect Visible Items > Error Explanation Text if you need your Error Rings to be more compact:

[thols]

10 hours ago, Darren said:

I have reported the documentation issues (both the 'page not found' error, and the suggestion about placing error rings in case structures) to R&D as Bug 1413653.

Don't forget you can deselect Visible Items > Error Explanation Text if you need your Error Rings to be more compact:

 

Thanks Darren, I didn't know that. Maybe because that is also not in the help.

[Darren]

9 hours ago, thols said:

Thanks Darren, I didn't know that. Maybe because that is also not in the help.

I updated the Bug report to mention that this should be in the help. Also, I talk a lot about use cases for the Error Ring (including mentioning several of the points I brought up in this post) in my What To Expect When You're Expecting an Error presentation here: http://bit.ly/dnatterrors

[Darren]

6 hours ago, Darren said:

I updated the Bug report to mention that this should be in the help. 

Hmm, I should have actually looked at the Help before doing that... our tech writer kindly pointed out that Visible Items > Error Explanation Text is already present in the Error Ring help.

[thols]

7 hours ago, Darren said:

Hmm, I should have actually looked at the Help before doing that... our tech writer kindly pointed out that Visible Items > Error Explanation Text is already present in the Error Ring help.

 

How could I miss that... I'm sorry for that. 

[X___]

Another interesting tidbit: you cannot "Find All Instances" of an error ring.

And you cannot search for an error code (or an error message for that matter) and expect error rings to be returned as part of the search results.

The error rings live in a separate...ring (the mathematical structure).

Yet, they are pretty much indispensable if you use custom error codes...

Edited December 12, 2022 by X___