Hi! Feature request that I hope is fairly simple to slide into the next rev. It's incredibly frustrating that a Combo Box's values (for a control wired to the connector pane of a VI) aren't selectable like Enums and Rings in the LabVIEW Adapter. Instead of seeing a drop down with selectable options, I have to open the VI, (open the control if it's a typedef), edit its values, then see what the values are, close that dialog out, close the VI, back to TestStand and put in the value. This is all so I can just hard code a value. This is crazy. I tested this out in 2019 64-bit, btw, so maybe it's available in later versions, if so, please let me know.
TestStand File Diff and Merge Utility is not very useful for code reviews on its own. It seems adequate for notifying the user that a sequence was added, however from the tool itself the user cannot actually review the newly added or removed sequence's contents. Why is there no + on the item tree to go deeper.
If I have to right-click a sequence and select "Go to location" then why bother with the separate tool to begin with? Why isn't the diff utility integrated into TestStand's sequence editor itself? Seems like a side-by-side comparison within Sequence Editor would allow a reviewer to poke and prod around all the hidden settings that are often missed using the existing utility.
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.
TestStand is in dire need of a way to quickly and effectively find broken steps in long sequences.
I'm working on large sequence files which often call and utilize other long sequences. Needless to say, I often need to address steps which have become broken due to code rework. As of now (TS 2017), there are only two ways for me to know if a step will not run.
Text is red within the Step Settings window.
Sequence Analyzer reports an Error.
I would like to suggest a third option, one that would be more readily available than either of the other two options. If the step itself was highlighted, text reddened, or somehow otherwise flagged as an error, then the operator won't have to hunt through each of the step settings windows or the sequence analyzer results. All the operator would have to do is open the sequence file and notice that a step appears out of place.
It would be nice if sequences could also show if they have broken steps.
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?
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.
You can run TestStand sequences headless currently from LabVIEW, but it would be nice to have more detailed documentation and examples on how to do it properly since it is not straightforward. There are some end users that do not need to see the TestStand execution in the operator interface and just want to run a sequence without showing all of the TestStand UI components.
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.
We have multiple sequences in a file to perform steps that are common to particular subsystems. It would be nice to have the ability to group sequences within TestStand. I could envision this to look like a treeview or folder/file structure within the Sequence Pane. Currently, we have to use a common naming convention to group the sequences together like below:
With grouping, it could look similar to below:
In addition, there could be a toolbar menu item to switch between showing the grouping or all so you could sort to find
CSV Input Stream allow to parse CSV files to input data into a Stream Loop for instance. By default, the separator is a comma (,). I use a non english version of Excel to edit a CSV file, and every CSV format write a semi-colon as separator (;):
I think it could be more convenient to have a direct access to this parameter in the configuration pane, allowing also to check the content of the file before execution with Parse Record Prototype funtions.
The Search Directories.Insert method should only insert the directory if it is not already there.
The Method includes an index argument, if the directory is already there, then it should move the existing directory to the requested index.
While we were working on the shipping examples for DQMH, we discovered that the insert method was creating duplicates every time it was called. We implemented a work around that includes a for loop to check each of the items in the search directories list to see if it is the directory we are trying to insert, if it is, we delete it. Once the for loop ends, then we insert the directory where we want it.
The "Report Options" dialog box provides a lot of flexibilty in the way reports are generated for sequences executing under the Batch model. A new report can be generated for each UUT, for each socket, etc. One option that appears to be lacking, is to flat out not generate a Batch Report. Doing a brief search, I found at two other folks who were trying to do the same thing:
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.
The property loader step allows the source location to be defined via an expression. However, if that expression does not evaluate to a file on disk at compile time you get an error. This isn't always desired behavior, for instance, when used in a plugin architecture.
The current workaround is to include a dummy file which could unnecessarily complicate the software & deployments. A dummy file also has the potential to mask errors that should be presented to the user.
The only validation TestStand does of the property loader source location file is that it exists. It doesn't do any validation on the file contents. So is there any benefit? TestStand properly throws an error if the expression doesn't evaluate to a valid file.
Alternatively, a developer could deselect the sequence analyzer rule "Property Loader source should be proper", but this would disable it for all analysis not just the ones that use expressions
The TestStand API doesn't provide a simple, robust mechanism allowing developers to programatically run sequences outside of the ActiveX UIs.
On many an occasion I've wanted to wrap the following basic functionality:
Run a specific sequence file (with or without a [typically custom] process model)
Wait for it to complete.
Retrieve the result.
It's something I've needed to do in all of the following situations:
Integrating into a customer's existing framework
Integrating into my own automated test framework
Providing a simple API to a customer
Creating customized UIs that rely on UI messages and events rather than the ActiveX Controls
The solution I've ended up defaulting to in the past has been some variation on:
Start with the full-featured C# UI.
Scrape out all visible ActiveX Controls, and hide the window so that it's running in the background.
Integrate a TCP/IP (or equivalent) client into the application that has the ability to listen for requests and then implement them through the AxApplicationMgr.
Build a TCP/IP server assembly that launches the client application and exposes the necessary API for simple interactions.
The approach above is time-consuming, error-prone, and feels like a hack -- but given that TestStand does not expose any easy mechanism for simply running a sequence, this is what I've ended up having to resort to.