Jump to content

On the Error Ring primitive


X___

Recommended Posts

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:

1399289690_ErrorClusterfromErrorCode.PNG.1254ff4ee7ff25c69e43acb498375721.PNG 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):

1542612157_NoError.PNG.b06a0401321743e8eb70cc9cc957a098.PNG

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.

  • Like 2
  • Sad 2
Link to comment

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.

Link to comment
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...

  • Like 1
Link to comment
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:image.png.f9e13461a2b2ece111101d5020422d09.png

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

Edited by thols
add info
Link to comment

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... 🙂

  • Haha 1
Link to comment

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:

image.png.a91a6f0925b89b326e63b7a18d35eaf8.png

  • Thanks 2
Link to comment
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.

Link to comment
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

  • Thanks 2
Link to comment
  • 1 year later...

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 by X___
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.