NI TestStand Idea Exchange

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,

When putting values into an array of number local variable, there is little documentation specifying the correct way to input values in an array. The documentation needs to be improve and/or the error message that pops when evaluating your statement should be fixed to better demonstrate the problem. The current error states "Variable or property types do not match or are not compatible. This value will cause a run-time error." A getting started documentation that addresses variable syntax would also be helpful, these ideas will improve ease of use for people working in TestStand. The typical syntax when working with arrays is the use of a bracket [] and the error that appears when using a bracket for arrays is even less helpful. Attached is an image of an example of the fixed error that would demonstrate this problem more thoroughly (The red highlighted section would be a potential change to the errors).

Finding syntactical errors -- missing arguments, arguments of the wrong type, ... -- involves either manual inspection or running a sequence to see where it croaks.  TestStand could use the equivalent of a broken run arrow from the LabVIEW environment.  As in the LabVIEW environment, clicking on that broken run arrow would present a list of the syntactical errors, and double-clicking on one of the entries in that list would take you to the entry itself.