error ring "format into string"

[QFang]

It would be very handy if there was a way to get the descriptive text 'out' of an error ring constant.  It might not be possible on an error control/indicator since it (presumably) involves a (database) lookup of some sort, which may not be available at run-time on certain targets, but for an error ring constant, it should be possible to pass it into a "format into string" just like you can do with enums to get the string.

This is similar to, but not the same as this idea on the format into string taking the error cluster

(Note that currently, there is no way (that I can think of) to get the "descriptive" text that you can read some of above ("Not allowed whil...") from the error cluster/constant, which is rather anoying.)

[crossrulz]

Did you try to put in a %s or %d or %f into the description for the Error Ring?  Guess what, it will work like the Format String.  Go ahead, try it!

[QFang]

I don't remember what the limitation was, but last I tried to do that, it would not reckgonize/work for custom errors. Again, I don't remember exactly what the limiation of that functionality currently is.

At any rate, that is not the functionality I am going for. Rather, I am trying to get the "description" string out of the error ring constant, not put additional parameters into it, if that makes sense?

(The reason for this is that I'm doing some additional system logging and reporting beyond just monitoring the error cluster for errors, code and call-chain, and it would be very handy if I could get that descriptor string out without hardcoding/hand typing it for each one. And again this is all for custom error files loaded in the ..\\LabVIEW 2013\user.lib\errors folder)

[crossrulz]

And just playing around with the error ring, you can only do the parameters on custom errors (or so it seems).

For a normal error, doing an unbundle of the source gives me the call chain, but not the description.  Ok, I'm convinced now!

[QFang]

Thanks crossrulz! 🙂

[AristosQueue (NI)]

QFang: Just to make sure... you do NOT want the information that comes out of the General Error Handler.vi because it has the "source" information attached, right?

[QFang]

AristosQueue, correct, I don't need nor want those extra strings, and while it is fairly trivial to use search and split strings etc..  

TLDR;  we don't want to and were adviced (NI) not to use these on RealTime targets (back around early LV2011?).  

In all fairness, I am so rooted in the cRIO/RT world that I stopped relying on those VI's for a couple of big reasons:  

From benchmarking I have done, the General Error handler and simple error handler are terrible performance wise on an RT target.  I'm not sure how the "Error Code Database.vi" is organized, but I suspect the database lookups are what drags it into the mud on RT targets. 

I'm not sure if it was fixed, but there used to be an issue where if the error handlers were called "a lot" with an error on the input terminal, performance would degrade until it would take 20-30 s or longer to return (on cRIO's).  It's been a couple of years since we were in talks with NI over a different memory leak issue when that surfaced, so I could have the specifics wrong on it.

Lastly, they seem to on occasion break RT projects (which then gets fixed if I close LabVIEW and re-open) because once in a blue moon LabVIEW gets angry about some front panel stuff burried inside of the error handler VI's.  

And to nitpick since I had my coffee and my fingers fly faster than my mind: while I like readable code and don't like to "hide" to much functionality, I think my example above is cleaner and more readable than chucking in the general error handler on the wire, and the "compound" nature of the error wire and how it parses shouldn't be any less readable than say a time-stamp and how that is handled in those string functions.

[AristosQueue (NI)]

> TLDR;  we don't want to and were adviced (NI) not to

> use these on RealTime targets (back around early LV2011?). 

I have no information about that... this is the first time I've heard such advice, and I am the owner (though not the original author) of the GEH. I have been slowly refactoring it for years, but its basic functionality remains the same. The Error Code Database.vi does not suffice to translate the errors into descriptions, but there's a lot of weight that could be pulled off of the GEH for just translating the error to a description.

I would not expect that we would ever add a % code for the error cluster, for a long list of complex reasons.

[AristosQueue (NI)]

(That's not to say we would never do it, just that I would be surprised. The idea stays open as a not-bad idea, but technically there would be a lot of backpressure against it.)

[QFang]

Going back, the details for the advice is in a word document referenced in my NI Service ticket, but I can't find it at the moment. What I can see is that it is related to "Error Cluster from Error code.vi" not the error handlers.  The service Req# is 7360168 in case you want to go digging.   I was adviced to avoid using it (repeatedly) and replied back how that can be hard since it is used internally in a lot of (locked and unlocked) NI VI's. 🙂

I suppose I can create a VI' tool that runs the general error handler in a for loop to strip out the strings I care about on my dev PC, save the output string array as a constant string array, and ctrl drag array elements to the block diagram where I need these strings.. more labor, harder to maintain, but this should be the leanest way to include those descriptive elements.  

I still think my idea is good, but between it not being something a lot of people are likely to use, and the existence of workarounds, I'm not holding my breath.

Thanks for the comments and suggestions!

[AristosQueue (NI)]

AH.... that's a different VI. "Error Cluster from Error Code.vi" includes call chain information, which can be expensive to harvest on RT and uses strings, which can over time fragment memory. For that reason, some RT programmers avoid it.

I can break out the ability to get the description of the error cluster as a separate VI. I'll look into doing so.