Like described in this article I have to build Custom Data Types manually to pass enum strings to TestStand.
It would be very nice if I could import LabVIEW Enum TypeDefs into Teststand as Custom Data Types. This way I could save a lot of time.
In the Sequences sub-window in the sequence editor along with the Sequence Comment and Requirement columns it would be good if we have another one with the number saying how many callers that sequence has.
In this days I have been developing some applications in LabWindows/CVI and I noticed one tool that could help in TestStand. Including an Splitter Bar in the Steps Pane would facilitate building complex sequences with many steps inside.
It could look like this:
When I get called to look at an issue that has occurred with a test, the account logged into TestStand is typically a restricted user (i.e. Operator). Since the Operator account has very limited options, in order to really do much immediate troubleshooting I need to stop the test and re-run it in the Administrator account. At best this is inconvenient and inefficient if the spot the error occurred is late in the test. However, it is extremely frustrating when it's an intermittent run-time error and I can't do any real-time debug because Operator is logged in. The only real alternative I can think of (when the problem is intermittent) is to leave it logged in as Administrator so I can debug whenever it happens to occur. This is not really an acceptable practice in most cases.
It would be fantastic if there were an override that let's an Administrator provide the proper credentials to perform the desired task that would normally be off-limits to the Operator. The basic premise of this suggestion is similar to the functionality within Windows; if you try to connect to a secured location or perform a task that requires administrator privileges, a dialog box pops up asking you to enter authorized credentials.
I run into many situations where I wish this feature was present. The issue is not always within TestStand (could be a database connection issue, etc.), but it is TestStand that throws the error and in Operator mode the only option is "Run Cleanup". Significant time, effort, frustration, and efficiency could be saved if I could simply enter my credentials as an administrator to perform the tasks I need to do.
On an unrelated side note, I find it humorous that "TestStand" is considered a misspelled word when using the forum spell checker.
Exactly as in subject.
I thought that it will be good if the developers could collapse blocks of code which are in between of the Flow Control or/and Synchronisation step types.
I think about the mechanism we know already from TestStand which hides block of code: i.e. Setup, Main, Cleanup section in the sequence, or it can hide variables. It is a little "+" and little"-" to expand the content of the type of variables.
The types of steps I think of were mainly types from Flow Control and some types from Synchronisation. It would be good if for example we could collapse If-Else-ElseIf-End, Select-End, Case-End, While-End, DoWhile-End, etc statements
I think this functionality could improve the readability of the sequence, and helps the developers to have a better view on the whole sequence.
I find myself creating arrays alot and I usually have the array already made in excel or note pad or another type of file in which the list might be around 20 or more entries. Now in the past I've come up with a simple way to import the arrayed data from a file, but however i don't believe everyone is doing this and generally I don't need the file in which gets imported (usually a simpler version of the master). So i suggest could we add the support to copy from excel or from notepad and paste special into an array.
This idea might not be the best, fastest, or easiest way to import arrays from other programs, but the idea would be to find an easy way to import arrays.
Within the Teststand workspace it would be reall useful if the "Code Modules" under the sequence could auto-populate and also if it could display the filepath of the code module. That would make it much easier to keep track of what code a sequence is calling and where from on disk.
Today the UUT container and other Socket important informations are only available at run time and using long expressions.
The access to these properties is not valid ate edit time but will be valid only at runtime.
It would be nice to give a rapid access to these informations using a kind of direct pointer access.
Something like this would be nice ...
Using always existing properties would also be nice, in order to use Expression intellisense !
Thanks a lot.
Running batch model sequences it would be nice to be able to "Step Into", "Step Over" or "Step Out" for all testsockets with one click instead click instead the need to click on each testsocket before stepping into/over/out.
I have a sequence file that contains hundreds of sequences. It would be nice to be able to logically group and organize these sequences, such as in a tree control with virtual directories (hierarchy), instead of them being in a single long list.
Some test sequencing tools incorporate the idea of configuration based variant handling, where you could define different test variants (e.g. testing at ambient temperature, hot, cold), each variant having it's own set of test limits.
Individual test steps can then be assigned to the previously defined variants. By chossing the desired test variant, the according steps will be executed without having the need to implement additional logic within the sequence.
Now, when error happens (not during the execution but during the parsing) TS sequence editor displays message like below.
This message can be very meaningless and misleading as it doesn't indicate what is really wrong, it doesn't lead to any file.
It is very difficult to track, because it can happen that after switching the to the development mode this step can be perfectly fine.
Request: please do better description and explanation why particular VIs doesn't work with the RTE.
It's a very likley to happen that during the test the one LV module is called more than one time. As well it is very likely to happen the during the development we have to modify the module itself by changing the input/output from the VI or the connector pattern of the VI. If we have to Reload VI Prototype in one or two instances it's fine but when the step is in more than two or three places it is very painfull to update all of them.
So, I'm proposing to extend the Step Settings-->Module menu by adding the button with action Reload VI prototype in all instances.
Would be nice to have a possibility to skip execution of SequenceFileLoad callback by sequence editor configuration. It happened to me, that I've got 'dirty' programmed sequence files, which crashed sequence editor. Loading & debugging required additional work than.
When editing the Value text within Step Settings for a parameter, the Undo command completely reverts back to the state of the step prior to any entry modification. This is frustrating when a notable amount of code has been added/edited to an entry box and you want to "back up" a bit to a point somewhere between now and when you started editing. This functionality is already present in the expression browser: activating the Undo simply steps back into the process of the code you are writing. Can this functionality also be present in the Step Settings pane when entering code there? Once you press "Enter" to complete the entry, then the functionality could be as before (Undo reverts the entire edit). But when you're in the middle of typing code, Undo seems like it should just reverse the last steps of the code you are writing rather than completely abolish everything you've done during the edit.
Essentially, while actually editing the Value entry there should be a temporary Undo stack that is used for the text edits. This stack can be abolished and the main Undo Stack is resumed when the entry is submitted (press Enter, select a different field, etc.).
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.