Having the ability to have line numbers for all steps in the left hand gutter would help in troubleshooting, code reviews, and any time when communicating about a sequence. There seems to be a gutter there already, so adding there seems to be a place for them already. Error messages can also post the line number too.
We have several sequences which are too long to execute (test stand crashes during the initial load) using the preload option. These are often sequences with 50-100 subsequences which define contiguous tests to be performed.
If Test Stand had a 64 bit version additional memory would be a solution to this problem.
How many of you would benefit from the addition of a feature similar to LabVIEW's Quick Drop?
The functionality that initially comes to mind would be typing to search for your desired step type or step template and dropping it into the sequence you are developing. Please add comments for any additional functionality you might like to see in a TestStand step Quick Drop (for example, you may want TestStand to automatically navigate to the Step Properties of a step after it is dropped from Quick Drop).
Please also add comments for any other situations/scenarios (outside of adding steps to a sequence) where you might benefit from a Quick Drop-like functionality. Thank you.
I think this Thread should be placed here.
The aim of this is that users can create the same powerful steps like that once which comes from NI.
Biggest enhancement of this would be that i can get rid of the "edit" - button and there is no floating panel
The second enhancement is that i may use drag and drop between the edit and variable panel (if this is neccessary).
Like Manooch_H I am interrested in comments, too
When you set the Post Action On Pass | On Fail in a step to use Call sequence, the only ways to pass data to this sequence is either use some sort of Global (StationGlobals / FileGlobals) or use Locals with the setting "Propagate to SubSequence".
There should be a cleaner way and that is to beable to pass parameters as you do with SequenceCall step type.
When you are running an execution and you want to check if a step will execute or not depending on the precondition you have to go to the step, browse to the precondition, copy it and paste it in the Watch View...
Wouldn't it be great if you could add your step precondition the the watch view with a single click (like VS "Add Watch")... ideally I'd have another entry in the menu below called "Debug" ot "Watch View" with submenu-items: "Add Precondition to Watch View", "Add Pre-expression to Watch View", "Add Pre-expression to Watch View"
Vote for me!!!
<<- N --.>
It would be nice to beable to define a variable as constant.This could apply to Locals, FileGlobals, StationGlobals.
Once set mark it so as to be easily identifible as a Const.
The API would also need to include either a Property or Method so that one could determine if a variable is a Constant.
LabVIEW recognizes any cluster of <Bool, I32, String> as an error cluster. TestStand should recognize this as well and default any such cluster output to Step.Result.Error.
With the addition of the Silver controls in LabVIEW 2012 "error out" was changed to follow the style guide recommended naming convention of leading caps and is now labled "Error Out" which is not intercepted and assigned to step.result.error.
I have extended the multi-numeric step type to use the string and Boolean comparisons. We have several tests that require string verification to match the exact string and to verify the string format. Therefore I have added the ability for the multi-numeric step type to use string comparisons, including regular expression for string testing.
TS does not allow the ability to rename steps that are of the Flow Control type (i.e. If, Else, For, While, etc.). In a report, these generic names are then used, making it very difficult to know what condition the step was evaluating to determine whether to enter or continue within the flow control block. A step name would normally give the reader of a report some indication as to what is being tested or reported on. This is not the case for these step types.
For example, an "If" step that is determining whether a condition is met (and whether to enter into the subsequent steps within the flow control block) simply shows up in the report as:
|Low Limit||High Limit||Comparison Type|
There is no indication of what it evaluated to determine it was True, meaning someone reading the report has no idea what the purpose of the step is. As designer of the test, I can look through the sequence to determine exactly what it was doing, but a report is a useful tool to be able to show to someone not familiar with the test and allow them to be able to see what happened. A report gives the reader the history of the test. Without knowing what a step is for, a lot of the "story" being told by the report is either lost or becomes much harder to follow.
I would assume there is a reason as to why these step types are not able to be renamed, but I'm not familiar with what that would be. It would be nice to be able to modify, or at least add to, the step name so that the report gives some indication of what it was that it evaluated. If that is not possible, there should be a simple way to include the parameter/expression being evaluated with the step name in the report. This can be somewhat accomplished using other methods, such as the Additional Results of the Properties tab, but this is not intuitive or clean and I would think this behavior should actually be default, not something the user has to manually create and enable.
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.
Right now, the breakpoints/watches window (Debug >> Breakpoints/Watches) is modal against sequence editor. This makes my life harder because I can't keep that window open to enable/disable a bunch of breakpoints scattered across a sequence(s) during an execution -- I need to be stopped at a breakpoint, open that window, enable/disable other breakpoints as desired, close the breakpoint window, continue execution, and repeat. I'd like to be able to just keep that breakpoint management window open the whole time (Just like I can with LabVIEW).
Another related thing that would be nice is to be able to manage breakpoints per execution. At this point I can have multiple simulatenous executions, and I can add breakpoints at run time that are specific to that execution. However, I can only manage those breakpoints easily through the execution view windows, and not through the breakpoint manager. It would be nice to see individual executions show up in the tree structure of the breakpoint manager the way each sequence file does.
It would be nice to make Sequences public or private within a SequnenceFile.
With this you where able to make powerful SequenceFiles librarys. The biggest advantage of this
is you can show the consumer of the library only the "important" public sequences. The
private ones where invisible. This will help to avoid errors.
It should be nice to be abble to view the UIEvents directly in TestStand SeqEdit.
This could be helpfull during debugging a sequence.
The idea could be done like a Debug / Trace window.
It should also be interresting to have such a "UIEvent callback" in the process model.
It should be nice to be abble to refresh the STEP default options, according to it's STEP TYPE.
=> This should be made using a "REFRESH TYPE" command in the contextual menu (Right CLICK) of a STEP.
The current method of viewing the contents of a 2D array variable can be difficult to read if you have many elements. My suggestion is to add a feature that allows a right click on the 2D array variable and select a popup to see the array in a row/column format. It would be nice to able to edit the contents with this view as well.
I have uploaded an image of a TestStand view of an array and a LabVIEW view for comparison. Looking at the LabVIEW version, by having the contents in a row/cool format, adding the scroll bars and index display, I can easily see my array contents.
I've got a bunch of variables in StationGlobals. Many of them are types. I want to edit the type of one of the variables to add a parameter.
Open StationGlobals pane by clicking the "world" icon along the top.
Find the variable instance. I right click on the variable instance, and this is the listing I get
Darn. I was hoping to be automatically linked to the type definition.
Frustrated, I was convinced I had right clicked on instances of types before and been able to directly link to the type definition for that variable. So I go to my empty dummy sequence file, and try doing the same thing from the variables pane of "Sequence File 1"
Ah Ha!!! that's what I wanted.
So how about this -- why don't we just take this "Right click -> view -> type definition" ability that exists in the variables view, and get that feature added to the station globals view, kinda like this:
The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.