When writing TestStand UI components using LabVIEW, there are a lot of scenarios where using a callback VI to handle a TestStand event is the right move. As of writing this, that's the only way.
There have also been plenty of times when I would have preferred to handle a TestStand event directly within a LabVIEW event structure. In these kinds of scenarios my code would be less complicated if we had the ability to directly register TestStand engine events with LabVIEW's "Register for Events" node.
Years ago when learning TestStand, I tried to do this out of intuition and I was kind of surprised that it wasn't supported.
Many SW-Tool providers have realized that how comfortable it is for a programmeruser to work with dark backgrounds. Microsoft did it in 2013 for visual studio and now browser companies are doing the same. Unfortunately, I can Change background color of MAX and TestStand. This makes longer working painful for eyes.
An example of such a bakground is attached with the message.
TestStand File Diff and Merge Utility has the ability to produce reports in XML format with a slew of dependencies on TestStand (stylesheets, button images, etc.) making them not very portable. Yes, I know they can be packaged with the extra utility, but that's a hassle too. Now instead of managing a file I have to manage a folder of files.
Additionally, these reports only seem to work with Internet Explorer which I'm hearing is going away. Not sure if it's just me, but Edge's IE mode doesn't seem to work for these reports either.
Can NI do something to address this?
Make a browser extension that works with at least chromium based browsers.
Figure out a nice PDF format.
Ideally, I want to upload the file type into my code review platform of choice (git, perforce swarm, crucible, network folder share, etc.) and not require my reviewer to have TestStand installed on their machine.
The current placement creates confusion about what you’re actually closing out of when you click it. It makes me hesitate and wonder what I am about to close.
If you click it when there are multiple files open, it just closes out of the tab on top. If you click it when there is only one file open, it closes out of the whole pane, including the Sequences and Variables windows.
It would eliminate any ambiguity if the X for each file were on the tab for that file and if there were a separate X for the pane, like you typically see in tabbed programs.
You could also just put an X next to the pin on each little window instead, like the X in the Step Settings pane and the Insertion Palette in the screenshot above.
...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.
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.
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?
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.
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.
Forgive me for the cavalcade of suggestions this week...
One of my favorite options in the LabVIEW development environment is the "Find all Instances" context menu option, whereby one is able to locate all calls to the particular SubVI.
I have long wished that something similar were available in the TestStand Sequence Editor. I'd like to propose a "Find All Sequence Calls" context menu selection when right-clicking on a sequence in the Sequence pane. This could leverage the Find tool, but save the user from copying and pasting the name of the sequence. (And save the user from configuring the search options to narrow down the results) It'd be nice to be able to define the scope of the "find" operation to either the selected sequence or all sequences in memory, but I'd settle for a simple search of the open sequence.
How many times have you found yourself typing double backslashes "C:\\Windows\\System32\\cmd.exe" or even worse, going through a copied path to change every backslash to a double backslash (and inevitably missing one), just so you can pass a file or directory as a constant to a code module or another sequence?
I'd like to see a symbol for 'explicit string' in the TestStand expression language, much like C# does with the @ symbol.
So if we typed @"C:\windows\temp" we would actually get the string "C:\Windows\temp" instead of "C:\Windows<tab>emp".
To really go the extra mile on this:
Drag and drop could be enabled, so that any file dragged from another window into an expression box would automatically paste the filename.
A browse button could be added to the expression browse dialog which would bring up the usual file open dialog and insert the selected filename.
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 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.
This idea mostly goes along with this idea. I use type def all the time in LabVIEW, especially with enums. TestStand can interact with my VIs with enums, but they are handled as a number. Furthermore, if the enum gets changed, the wrong value of the enum is often used. I really like the idea of custom data type of an enum. The ultimate would be if I only had to alter the enum once (in ctl file) and TestStand would automatically update its data type. This should be the same for clusters.