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]

---

@cy... wrote:

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. 

---

I still don't understand this. How do you change the 'name'? Changing the labels (with scripting probably?) doesn't make the functions use the change labels in their errors. At least not the functions I tested. What does changing the labels gain?

[cy...]

frankly, I haven't test it out yet, but kinda wished that the label will do the trick... wouldn't that be nice? but since you mentioned that it wouldn't... then... I'm out for the moment 😐

[cy...]

a very bad one would be replacing all the functions with subVI calling those functions, adding a layer of subVI purely for appending the sub/structure name... 

[AristosQueue (NI)]

Weibe: Are you trying to store the diagram path on every level of the call chain? I don't think that's a solvable problem.

[wiebe@CARYA]

>Wiebe: Are you trying to store the diagram path on every level of the call chain? I don't think that's a solvable problem.

No, I agree that wouldn't be possible to do. At least not at compile time. One VI can easily have multiple call chains...

The LV functions report their name in the errors, and OP is trying to change the label in order to change the reported name in the errors. That doesn't work. The label does not change the name of the function reported in the errors. It could, but it doesn't (I tested that to make sure).

[cy...]

what about the bad approach? using pre-build action to execute a scripting VI that opens the main.vi as a template, integrate bundle BD location indicators in if error cases (for VIs that can generate errors, especially when it appeared in more than one instance on the main.vi), save it as source VI and build the application?

[wiebe@CARYA]

>what about the bad approach?

Well, that would be a bad approach .

• Saving the source VI isn't required (IIRC), but would change SCC.
• The scripting would need to be able to clean up it's own mess, to allow repetitive actions.
• It might be a lot harder to make than you'd initially thing. Scripting usually is.

[cy...]

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.