Error Locator

[cy...]

good day forum

it would be nice if an error locator can be used together with the current indicators. in medium and large applications, where multiple operations are executed in parallel, it could be a challenge just to locate where the error originated from, especially due to modularity, where the error causing function could be from any of the instance within the block diagram. instead of just reporting the function name that encounters the error, perhaps the option to include the nesting structure's information can be beneficial, especially for post deployment investigations, where debug application cannot be used (unavailable/lost source code, etc) and end user can do some self-checking first

several approaches came to me, which mostly revolve around VI scripting during development, that include:

• renaming functions to include nesting structure information (eg. label for structure, sub-diagram, etc), or
• including numeric identifiers in function names and building custom error table (identifiers for location)
• traverse and filter error wire references, terminal tracing until nesting structure and and probing these wire per update during run-time

can be a nice feature to have, especially for remote support

[wiebe@CARYA]

So basically a call chain on VI\structure level? Doesn't sound too bad.

However, the label of the structure might not be useful. If a case structure has 30 cases, I'd want to know the case, not the label of the structure.

I usually do this manual, simply overwriting the error (if there is one) with a more verbose message. One or two simple subVIs facilitate that.

Changing every node in LabVIEW is unlikely to happen... I wander if this functionality could be provided with an XNode, that can be added after each node that you want to expand? The XNode could traverse the structure hierarchy at compile time, so it wouldn't be too hard on execution performance. Compile time could go up though.

[cy...]

@wiebe you are spot on... I refrained from using the term call chain earlier, as that function can not get me what I want, but you have described it accurately no doubt

yes, one can consider the approach of using either the structure label or sub-diagram label mentioned in the 1st approach

the manual method can be challenging, especially when there is structural changes in BD due to end-user ever changing requirements. my current method is enqueue subvi with queue reference in global; but the subVI still requiring manual input to specify location and location specific messages. that said, maybe it is just personal preference to use default documentation... knowing the location, although with default documentation, one can prolly figure out the cause

what is your take if the BD function labels are renamed to include subdiagram/stucture information? that way the existing error cluster and functions can still function as norm

[wiebe@CARYA]

>what is your take if the BD function labels are renamed to include subdiagram/stucture information? that way the existing error cluster and functions can still function as norm

Changing the BD function labels (already possible, manually) won't make the errors more descriptive. The functions don't use the labels to make their errors.

[cy...]

I mean more an automated way of doing it, for instance, VI scripting to change the label property of the label based on the sub/structure information that nesting it. that would at least give the developer a better indicator in providing support for end users remotely.

another one that I am trying now is to link error wire with the sub/structure information to return additional information (eg additional strings) from another table the wire value matches the entry in the table

nonetheless, if BD level call chain (based on nesting sub/structure names and level) can be used, I am for it also

[wiebe@CARYA]

>I mean more an automated way of doing it, for instance, VI scripting to change the label property of the label based on the sub/structure information that nesting it. that would at least give the developer a better indicator in providing support for end users remotely.

A script could already change function labels to include the diagram hierarchy. That's no problem, although it would require a manual action...

But that would still mean all functions with errors need to be change, to actually use the given label in their errors. That is just very unlikely to happen. The risk of unforeseen side effects is just to high.

>nonetheless, if BD level call chain (based on nesting sub/structure names and level) can be used, I am for it also

That's only going to work with an XNode. And those are not very future resistant. I'd only use it if NI provided it, preferably shipped with LabVIEW.

[AristosQueue (NI)]

I gave this question some thought over the last couple days.

My first thought was that this was insurmountable because the compiled code of a VI knows nothing about the block diagram, and it is the same code that runs in the IDE that runs in the runtime engine. And because the error source string has a generally arbitrary format, appending to it freely would be tricky for LV to add.

But that's if we tried to solve this for 100% of cases. I think we could help some cases.

Every node in LabVIEW has a unique ID number that is unique within that VI block diagram. You can access that UID while scripting using the UID property:

If an error source string included that ID, that plus the name of the VI would uniquely identify the node. I don't think we need the IDs of all the enclosing structures. But the node ID it isn't something we draw on every node, so we'd need to add some sort of interpretation button to the General Error Handler dialog that could interpret that ID and do the jump-highlight. The UID for a given node is stable across edits to the diagram and is a saved part of the source code, so it would work.

For functions that are built into G, when we generate the code that fills in an error code cluster, we are at a point where we can get the node ID of the node that is populating that error code cluster, and when we create the source string, we could append that ID.

Where we run into trouble is error code clusters that are built up in VIs. There are two use cases for that built into LabVIEW: the "Error Cluster From Error Code.vi" and the Error Ring. There's also plenty of customers that have written their own "make an error cluster" VIs.

Let's consider "Error Cluster From Error Code.vi" since y'all can look inside it and follow along. I cannot just add a call to Node.UID property into this VI: I don't have a refnum for the node. And the node that I need is on the *caller* diagram, not the local diagram. So even if I wanted to, I can't get that caller node. And that's before we consider the performance overhead of scripting calls in a heavily used function or the fact that asking for a node's ID is impossible to do at run time in the runtime engine because no block diagram exists!

So, that's not an option.

We would need is something on this diagram that gets the UID of the caller.

We could introduce a node whose sole job is to compile its own edit-time UID into its code and then return that value at run time, and then we could wire that value into the "Error Cluster From Error Code.vi". But that that would require another input on the subVI's conpane. That seems like a bad solution -- none of us wants to have to wire something extra to every call to this function. Or any other error-generating function.

So that demands we ask: can we have the caller *amend* the error cluster when it is returned to the caller? We could, although there's no guarantee that the cluster's string is formatted such that appending to the end is meaningful (even if we backup before the <err> and <append> tags, for those of you who know about such trickery).

But there's nothing that makes "Error Cluster From Error Code.vi" be special from any other subVI. Do we want to do that appending to *every* subVI that returns an error cluster that is not "no error"??? That seems like overkill at first, but it would give us the complete chain of nodes from the point of return up, something that would be useful when debugging. But then the negative is that we wouldn't know when we were handling an error as data -- we wouldn't want a function that reads an error cluster from a log file to be modifying the cluster that it reads!

So that idea fails.

Which leaves us with adding an VI Properties option to a VI that says, "I am an error generator", and any error cluster returned by such a VI will be automatically amended by the caller to include the UID. Such VIs would need to promise to format their error strings in such a way that appending the node ID (ignoring the <err> and <append> tag sections) is meaningful and can be interpreted by General Error Handler, or else it'll just be a junk integer at the end of the string.

That seems viable. It's a bit weird, but it would get us across the line for most generated error clusters.

[AristosQueue (NI)]

To be clear, I'm not sure if I'm proposing this or not. It's really a strange way for a feature to work, and it's not exactly discoverable, but at least it is a starting point for a conversation.

[wiebe@CARYA]

Your story made me think how useful this is going to be in practice.

Consider a node that reports an error, including the call chain and the 'diagram chain'... This sounds great, as the error would explain exactly where the error occurred. Except... it doesn't. The error is supposed to be something like "Main.vi>SM loop>SM case>case 'init'>Open File, File not found". but as soon as the error occurs in a sub VI, the diagram chain of the main is lost, and the diagram chain of the sub VI is used: "Main.vi>SubVI>Open File", File not found"...

Of course, we could propagate the hierarchy, but that would not be possible during compile time (as a node is likely have more then one chain). So that would imply constant overhead, gathering the chain hierarchy, even when there's no error.

Here's a VI that I use. It's so simple, it feels like cheating:

I think doing it manually isn't proportionally inconvenient enough to justify the problems. Manually will probably give better results as well.

I do thing an XNode that returns a 'diagram chain' would be useful, so it can be included (manually) in the error code.

[cy...]

@wiebe & AQ: thanks for the inputs

the idea initially started off as an error locator, as I took somewhat similar approach to wiebe's subVI method, difference being instead of custom error clusters as descriptive, I manually included 2 string inputs, one for location identification (typically name of structure, etc), the other for a short supporting message to further elaborate the location, (typically name of state/cases, etc) and append it to the cluster string; and still felt like it can be better if it can be somewhat simplified. doing that, I do rely on standard non-descriptive errors because:

1. knowing the location on where a standard error from a standard function should normally be descriptive enough for the developer to provide support to the end user
2. having a sub/structure label appended as the location identifier can be applied to all functions contained within it, though this may not be applicable for all cases
3. replacing the standard errors may require a complete rebuild of the list and possible some undocumented and unhandled cases, especially for external function calls; and users instinctively search online when encounter errors

Currently looking at using an external VI to change the name of functions capable of generating error to include its immediate sub/structure for trial. renaming-wise, is done either during development or pre-deployment. it may be messily usable, but it should involve the least change; while waiting for other methods to become available, if any. 

@wiebe: the cheating method seemed to pose an risk of losing the flow error in case of an error cleared but inherited a descriptive error from the previous, its current error in would seemed to have gone under the radar. 

the manual approach is a good method nonetheless

[wiebe@CARYA]

---

@cy... wrote:

@wiebe: the cheating method seemed to pose an risk of losing the flow error in case of an error cleared but inherited a descriptive error from the previous, its current error in would seemed to have gone under the radar. 

---

That is by design. It enables forced flow, while executing code that should be executed regardless any previous error. The error is not lost, as it will be in the descriptive error. If that's feels like a danger, ditch the Boolean, but I put it there because it was good to have.