Updating the LabVIEW Error Handling Core

[Stobber]

1 hour ago, Manudelavega said:

Come on! 

Trivial examples have trivial impact. Anyway, this is still a derailing of the thread's topic, so let's agree to disagree.

Edit: Found this on an article linked below and just had to post it as a counter-point: https://i1.wp.com/www.notatamelion.com/wp-content/uploads/2015/07/Read-and-Decimate-Big-Data.png

Edited June 15, 2016 by Stobber
Beating a dead horse

[ShaunR]

Three points jump out at me from an implementation point of view..

1. The user is expected to propagate the error list. This is fraught with foot shooting possibilities (forgetting to wire a case through, for example, will clear all the errors). Try and encapsulate the errors into your API so that storage is handled and managed by the API itself.
2. Creating and passing arrays around as you have will become a performance and memory concern as the array grows and is not deterministic. This will make it a no-go for real-time systems.
3. Instead of just a string for your labels. Consider using a typdef'd string combo box. Then you can give the user a drop down list to choose from to avoid spelling mistakes but still allow them to enter their own custom labels.

Edited June 15, 2016 by ShaunR

[Neil Pate]

2 hours ago, Stobber said:

The magic pattern is when you use unbundle by name on the same items, in the exact same order, in a path of unconditional logic (i.e. bundle node not in a case structure). If you change the order, or fail to bundle an item, or bundle an extra item, or put the bundle in a case structure the compiler will duplicate the entire cluster in order to finish the operation. If you follow the pattern, it'll update the items in-place.

Interesting, do you have any official documentation to back this up? Not that I don't believe you, I am just super curious about optimizations the compiler can make, and things that can be done to help. For example see this discussion about using the Swap Values prim.

[Stobber]

1 minute ago, Neil Pate said:

Interesting, do you have any official documentation to back this up? Not that I don't believe you, I am just super curious about optimizations the compiler can make, and things that can be done to help.

No, I don't have documentation. I learned about it when I worked at NI as a Systems Engineer and had access to unpublished documents about LV, as well as people who had developed the language. I verified it with an NI R&D engineer while developing a project in March of this year.

IPE does add logic for other nodes, like the DVR node that adds a mutex when popping the value from the pointer.

[Neil Pate]

1 hour ago, Stobber said:

No, I don't have documentation. I learned about it when I worked at NI as a Systems Engineer and had access to unpublished documents about LV, as well as people who had developed the language. I verified it with an NI R&D engineer while developing a project in March of this year

That is good enough for me. 

[Stobber]

Test it with a cluster full of big arrays. You should see an allocation when you unbundle/bundle without the magic pattern.

[hooovahh]

I have no sources but also have heard R&D mention how IPE for clusters just forces the compiler to do something, where using an unbundle modify bundle, will have the compiler do what it thinks is best, and in simple cases like this the compiler will choose to do the same thing as what the IPE would force it to do.

The most recent thing I remember AQ saying is something along the lines of, tell the program what to do, and not how to do it, and the majority of the time you will be better off.  There are of course cases where the compiler will choose to do something it thinks is better, but with some testing you can force the compiler to do something more efficient.

On topic a bit, I do commend your implementation for not over engineering.  Most of these improved error things I've seen involve many layers and layers of objects of objects with so much overhead I can't imagine using it.  As others have said the ever growing arrays could be an issue, and I also share the comment that the most important part is the error being logged.  In the past I also had a system where the last 4 states of the state machine would also be logged when an error happened, so you could see what states it when to leading up to the error.

[smithd]

On 6/15/2016 at 8:28 AM, Argold said:

1. The Labview native error system can only carry one error at a time, this carries an array of errors.

2. This uses a tag for severity <sev> and a tag for priority <pri>.

   1. I decided to make the severity tag a string rather than a enum so programmers can create their own severities on the fly.  They may or may not choose to modify the error handler to accommodate these.  An enum of severities might be better, I'd like to hear what folks think.

   2. The error handler dialog has native support to the following severities

3. The priority tag is used to sort multiple errors.  The ParseErrors.vi will place the lowest number priority first in the array so they can be handled first.

 The test application is only one way to use the library, there are many other ways.  For example, in the test program, when multiple errors occur, all of them are shown to the user before the program exists or continues.   Another application may want to stop on a fatal error without trying to show the lower priority errors to the user.

Theres some interesting additions -- I like the built-in sorting and filtering idea -- but one thing I can't get past, and its the issue with every error improvement I've seen, is that it still doesn't really work with the standard error cluster since you pass around arrays rather than the base cluster. Its not compatible anyway without adding a node to convert between them, it seems like making bigger changes is appropriate.

Edit: thinking about Shaun's q below, the versions I've seen seem to be either (a) not the same data type or (b) the same 'type' but used in a fragile way. In both cases you have to isolate either (a) your new data type or (b) your carefully crafted 'source' string from the errors provided by built-in functions or functions in most any other library. And doing this conversion is itself a challenge as theres a billion different error generators -- code to error function with or without various options, stephen's xnode, and the custom ones built by a lot of different groups. Its quite a challenge to convert these various data types and honestly I think its more challenging to deal with the variety of ways the standard cluster is used. Maybe I'm missing something, thats the impression I've gotten.

Edited June 18, 2016 by smithd

[ShaunR]

5 hours ago, smithd said:

but one thing I can't get past, and its the issue with every error improvement I've seen, is that it still doesn't really work with the standard error cluster

Can you clarify? There are a couple that work with the standard error cluster so what is meant by "really work"?.

[smithd]

1 hour ago, ShaunR said:

Can you clarify? There are a couple that work with the standard error cluster so what is meant by "really work"?.

Tried to clarify above but I see your point.