Preloading errors need better usability

[Raydur]

When a step cannot be preloaded due to the prototype being out of date (if, for example, a VI was updated after it had been placed in a sequence), an error message pops up telling the user what is wrong. This can then be used to track down where the step is that is causing the issue. Some of the error descriptions get quite lengthy.

While this does provide the user with information as to where the error is occuring, the only option is to click "OK", which then closes the message. In long sequences with many subsequence calls and steps (many of which may be similarily named), it is cumbersome to find the specific step that was listed in the error message that is now no longer viewable. At times I find myself having to get to the general area where I thought the error was listed as occuring, and then click RUN again just to get the error message to pop up again, and then continue narrowing it down (repeating this process several times). This is very cumbersome.

There is a simple solution to this issue. The easiest method would be to simply include a second button in the error message that brings you directly to the step that is causing the issue (with it selected in the step window). This would solve the main issue of trying to find the step that was listed in the error message as being the problem.

To go a step further, there could be a button that simply activates the "reload step prototype" that you have to do once you are at the step that is out of date.

To go even a step further, and solve another issue I would like to see remedied, there could be the option of reloading all steps that call that module (since they are now likely all out of date and need the prototype refreshed). Currently, if a VI is called repeated throughout the sequence, then each one must be found and have its prototype reloaded manually. This is very tedious.

There may be other preloading errors besides the "prototype out of date" issue (ex: VI not found, etc.) that could use the same functionality of a button that brings you to the offending step, but this is what I am running into at the moment.

Regards,

[warren_scott]

Definitely in favor of a "take me to the step causing this error"

also would like to see the engine be able to give a "there are 14 steps that had errors preloading", and be able to list all of them and a "take me to this step" for each one.

To some extent this can be resolved with running sequence analyzer and it will give an error for the steps that have errors loading the module, and you can sort by that error type and easily get to each step.

To update all those problems in mass, the Tools -> Update VI Calls utility works great, especially if the VI prototype change is only cosmetic.

[WireWeaver]

I'm closing this as already implemented - the Update VI Calls tool can force a prototype reload (as warren points out). If there is a more specific request, feel free to reopen this for discussion.

Thanks,

Trent

[Raydur]

Hi Trent,

This should not be closed as Already Implemented because the Update VI Calls tool does not at all address the issue - while I agree the Update VI Calls tool is able to force a prototype reload, that was a secondary (third-ary?) side request once the main issue was actually solved. It also, as Warren notes, does this en masse - this blanket approach to update every VI is often not a desirable option. Finally, the Update VI Calls only works if the offending step is within the same sequence file (or you specifically know where it is, which is the root of the original issue). It does not have the ability to update VI calls in external sequences (relative to the one I am trying to run), which is most often when I encounter this issue.

The main issue (which Warren stated they were "Definitely in favor of" and actually expanded the request) is that when you click run and the window pops up saying there is an issue with a VI it is very cumbersome to try and find where the issue that is listed exists (especially when it is in a different sequence file that is called from the one you're running). Running the sequence analyzer does not find issues in external sequences calls that have a step with an out of date prototype, which again is often what I encounter.

Try this as a simple example:

Create and save a sequence (A) that calls a VI. Then modify the VI (add an input) and save it, but do not reload the VI in the calling sequence (A). Now create a 2nd sequence (B) that calls the first Sequence (A).

When you run the analyzer on sequence B it will not have any errors, but when you try to run Sequence B it will pop up an error message that is quite cumbersome to read and figure out where the offending step is. The error window is modal, so the only thing you can do is click OK, which closes the window. If you try this (and think of the situation where you have thousands of files/folders with lengthy paths and don't readily know where the offending step is), I think you'll clearly see the issue.

The main request is to simply have the ability to "go to the step causing this error" from within the error window. TestStand obviously already knows where this is - It seems it would be a very simple addition to be able to open and go to the offending step directly from the error message.

[WireWeaver]

I just tested what you mentioned and got this error dialog:

It lists the step in question. If the main request is "Go to the Step Causing this error", does choosing "Break" above solve this?

[Raydur]

I do not get that error dialog. I get an error while TestStand is trying to load the sequence immediately after pressing the Run button (before it ever gets to the point of trying to explicitly run the step). This is a white box with black text that only has an OK button option. I do not see a way to include an image in this response - How do I do that? Figured it out...

The error you show says the VI is broken. The VI should not be broken - it should be a good VI, but the TestStand sequence that calls it would simply not have the correct prototype loaded.

[crossrulz]

WireWeaver,

It looks like you have a "Load Dynamically" setting on the VI call (ie load when running).  The issue is when you have a "Preload When Execution Begins".

[WireWeaver]

I have the VI and sequence set to preload... I'm only able to recreate the error when running the sequence containing the error and not the parent sequence.