It would be nice to be able to "fold" control flow blocks (like if - else -end, while - end etc.). Despite the vertical lines connecting the control flow steps on the same level, it is sometimes very hard to find where a long control block actually ends or what the condition for the "end" is you are currently looking at.
In such cases it would be helpful, if the entire control flow block could be hidden under its first line, tree-view like with a +/- icon to show/hide the interior of the block.
The settings field can easily become too long to see every active option and there's not necesarily any consistency between steps if they have differing options. What I mean by that is if you only set the "Do Not Record Result" (my favorite) option in one step, it will be on the left of the settings field. But if you now set several options on another step, the settings are not lined up so that it becomes hard to see at a quick glance which steps I forgot to not record (because TS still doesn't default to not recording steps). You have to analyze the settings line for each step.
I propose something more graphical and ordered. Here's my idea of at least ordered. The text could be replaced with icons representing each setting.
Then it would be graphical, ordered, and concise. What more can you ask for?
Obviously it's not a great idea to have loads of nested conditional steps, but for longer sequences even with only a few nested conditions, I find it hard to find the matching END for example when an if-statement. Sure I can count the number of lines, but I think it would be a lot easier if the "scope line" that indicates the scope would stand out more and become bold or blue (like the selected line)
Here's are two mockups (bold line)
An alternative indication could be to highlight the ending line of the scope like below.
Having a keyboard shortcut for jumping between beginning and the ending within a scope would also be very helpful!
In Microsoft Visual Studio there's a keyboard shortcut (CTRL + [ ) which toggles the cursor position between the and and beginning of a scope, and it works with all things that encapsulates a scope or a string or expression. e.g. curly braces in code sections, quoted strings etc.
The built-in Wait step currently causes TestStand to simply stop at that step until the specified period has elapsed. For steps longer than a few seconds, it would be nice to have some sort of indicator to show how much time is left to wait (and to show that the computer hasn't locked up on those waits that are more than 15 seconds).
It would be really nice to have a check box option to show some sort of wait indicator, even if it was simply using the progress indicator in the lower right corner of the screen (something that simple could even just always be enabled).
On a related note, could the progress bar be made wider so that there is more resolution as to how much progress has been made? If there was a ten minute wait for something, the bar would be moving very slowly and hard to tell progression was being made.
I've encountered on several occassions, especially with complex testing, customers who are frustrated by the inherent 'flicker' that happens when stepping into and out of subsequences of logic. This leads to people opting to not use sub sequences, or creating complex replacements for the execution view that has a more persistant way of presenting the executed step data.
I'd like to see an optional setting for execution viewing that allows for sub sequences to be shown as expandable nodes (perhaps defaulted to 'collapsed') so that low level test operators can see the overview results at the sequence-call level, but so advanced users can expand for details if they're interested without added pulldowns or tabs for additional information. this could be one more API property similiar to showing one-stepgroup or showing all, so that developers can chose whether to be more efficient, or display-heavy....
In scenarios with dynamic sequence loading, the display might simply show a 'no pre-loading possible' sort of message until the execution actually gets to that portion of the sequence.
Right now, you really can't reliably use anything other than a basic ASCII character set in TestStand, which means that some SI units (such as ohms) cannot be represented in their preferred way (with an omega). It also means that you can't put non-english characters in your sequence file and reliably have them show up if your sequence file is opened on a different computer with a different language localization (which causes a huge problem if your customer demands support for non-English languages, and has more than one site -- that speaks a different language -- around the world).
Make TestStand support Unicode, so we can use the full greek character set for things like units, and so we can type characters from any language in our sequence files, and not have them change to a different character if we open them on a computer with a different localization.
When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help. While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help. I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.
This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users). Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.
...but at present the latter is tedious because one has to insert a lot of whitespace manually or worse yet, use another text editor and paste it into TestStand. It would be nice if TestStand's expression editor supported this basic feature available in almost every text editor or IDE.
I would like to enhance the TestStand Message Box step to add a 'Preview' button. When selected, it would show how the currently configured message box will look when run.
I find that I am often switching around the text, fonts, and other aspects and would like to get that straightened out before run time. I know you can run the step individually by selecting 'Run Selected Step' but that is tedious, plus you have to take into account preconditions and other functionality. Normally, I have to remove the precondition (if there is one) as often the step cannot be run by itself.
So here is my example with the button added. Not exactly sure what tab it would belong on.
In order to keep file clean, sequence analyzer helps in finding "potentially unused variables". To delete such variables, each warning in sequence analyzer result has to be double clicked and then delete has to be pressed to finally remove that variable.
In many cases with large sequence file, there could be dozens of unused variables and in a single work-space there are dozens of .seq files.
Is it possible to provide a button or some option to remove all unused variables from a sequence file?
Currently, if you create a step type and name it OnNewStep, it will execute when an instance of the step is created. This is pretty confusing to new users - why don't we just have an OnNewStep substep type (like prestep, edit, etc)? Custom steps would then just be meant to be called manually using the Step.ExecuteSubstep() Method as documented in the help.
We could keep the "onNewStep" custom step functionality to maintain backwards compatibility with older step types.
TestStand now works incredibly well with LabVIEW Classes, but there is a slight annoyance with the fact that you cannot call a Dynamic Dispatch VI with an empty Object Reference. The implication of this is that when you want to use a .lvclass, for every class instance you have to call a VI that does nothing more than return a wrapped class constant which then populates an Object Reference. Technically this is not a problem, but it means that your Sequence becomes very quickly littered with these VI's and it would be nice if there was a way within the LabVIEW module adapter settings for a class member call if when you first call a Dynamic Dispatch VI that, as within LabVIEW you can just pass in a class constant rather than a previously populated Object Reference.
The Problem - All the LabVIEW calls prefixed with 'NEW' are simply returning a class constant.
A Potentially more integrated way of doing this
The Dynamic Dispatch input has the option of either passing in an Object Reference, or a class constant.
All compatiable classes are listed in the value box now - either as .ctls, or alternatively as .lvclasses. This could also possibly be more akin to what happens in labVIEW when you call a Class which has available overrides that it gives you a tree view of the class hierachy to choose from.
Another way you could do this is to have a checkbox adjacent to the 'Class Path:' or 'Member Name:' named 'First Call' or 'New' or 'Construct' that then changes the 'Derived Class
NI has gone through a lot work to get the IVI Components integrated within TestStand as step types. I was wondering why NI has not incorporated the NI-DAQmx technology into TestStand as step types. I realize most TestStand developers would just create TestStand Adapters in the sequence step written in CVI or LV to interface to NI-DAQmx functions. Even the more advanced TestStand Developers would create their own custom step types to interface to NIDAQmx. I have just done that to where I have created a framework of custom DAQmx step types that I use as a small subset from all the NIDAQmx functions used from the NI-DAQmx library.
Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use.
This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.