Since TestStand 2019, it's possible to configure an action step with a LabVIEW Module to switch between using a source VI and using the same one but compiled into a LabVIEW Packed Project Library (PPL).
The option, accessible in two ways, is called "Always run VI in Packed Project Library".
That's a neat possibility since it's allow to switch between a development version with easy debugging of a classical VI, and an optimized and locked production version with PPL. One non compiled VI One compiled VI into a PPL One LabVIEW project One TestStand step
However, when LabVIEW Adapter is set to Run-Time, a tight coupling between the compiled VI and the non-compiled VI is maintained for no reason.
Example 1) -A VI is developed and compiled on a development machine A -It is called as the module of an action step -The VI, the PPL, the .lvproj and the .seq are pasted on a production machine B with fresh installations of LabVIEW and TestStand -LabVIEW Adapter set to Run-Time on machine B -Always run VI in Packed Project Library set on machine B --> The execution will not start, since the classical error -17600 appears on the call. The reason is because the LabVIEW cache of the machine B does not contains data from the .lvproj. Simply opening then closing the .lvproj updates the LV cache, which solves the issue. However, it makes no sense to depend of the LabVIEW development environment on this production machine since the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled.
Example 2) -LabVIEW Adapter set to Run-Time -Always run VI in Packed Project Library --> If source VI is deleted, it takes a long time to preload the modules. See here
Proposition : When the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled, it should be possible : - To not install the LabVIEW development environment (only the LV Run-Time) - To keep only the PPL (and eventually the .lvproj) and to delete the source VI (no source code on production machine)
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.
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.
When opening a version of TestStand which is not the current version, an error dialog shows. It would be helpful if this dialog included a button to open the version selector and/or a button to open the active version.
Handling arrays in TestStand is pretty limiting and more often that not you have to pop into a code module to perform any sort of array handling.
The following is the default functions that can be used in expressions:
[Array GetArrayBounds(array, lower, upper) Retrieves the upper and lower bounds of an array. GetNumElements(array) Returns the number of elements in an array. InsertElements(array, index, numElements) Inserts new elements into a one-dimensional array. RemoveElements(array, index, numElements) Removes elements from a one-dimensional array. SetArrayBounds(array, lower, upper) Changes the bounds of an array. SetNumElements(array, numElements) Sets the number of elements in a one-dimensional array.
I would like to see this expanded to avoided have to resort to using code module. The following is some suggestion:
Array Subset function Array Max & Min Replace Array Subset function Search 1D Array Sort 1D Array
I was in the middle of creating an ugly expression that was parsing a string and building a file path from other standard file paths and realized that I can clean up the expressing by creating a few local variables. But then I thought do I really want to create these local variables in my sequence that only exist for the purpose of this one expression. Then I thought, what if I can define a variable within the expression itself, kind of how a variable is defined in C or something similar. It only exists during the evaluation of the expression.
When loading large sequence files, TestStand does not display progress and appears to "lock up" both TestStand and the LabVIEW OI.Sequences with hundreds of steps can take minutes to load. Operators often incorrectly conclude the application has stopped respoding during long pre-loads.
I am suggesting to implement a responsive progress display, allowing the LabVIEW OI to proceed execution, and post the following UI Messages during step pre-load.
UIMsg_ProgressPercent–(Value: 11) TestStand step modules post this message to the user interface to notify it to update its progress indicator associated with an execution.
UIMsg_ProgressText–(Value: 12) TestStand step modules post this message to the user interface to notify it to update its progress message associated with an execution.
Because of the way .NET applications and assemblies are invoked in TestStand they are a child process of TestStand. This means that they share TestStand's resources. For most applications this is not an issue but if the application or library being instrumented by TestStand is resource intensive this creates a significant problem. In the scenario that served as the impetus for this suggestion we saw performance 1/10 that when running the target application outside of TestStand.
To correct this I recommend the .NET adapter architecture be changed or be able to be configured such that instead of directly instantiating target applications a call to create an object with a .NET adapter would create a separate process that consisted of a TestStand WCF client wrapper process that would host the target .NET process and communicate with the parent TestStand instance via WCF.
Here is a simple block diagram of the intended architecture:
I have a bunch of times that I need to round a numeric variable in TestStand
example: Locals.A = round(Locals.B)
However, it's actually more complicated than that because I need to round it at the Nth position after the decimal point (for example). This means my expression becomes something like Locals.A = pow(10,-Locals.Digits) * round (Locals.A * pow(10,Locals.Digits) ) (for Locals.Digits == 3, this means that Locals=A becomes 0.123 when Locals.B is 0.1234)
This is a lot more code than I really want to write. If I am doing the same thing in MS Excel, I just say $B5 = round($B4,$A$1) or something like that. Notice how the digits of precision to round to is built into the round function. I'd love if TestStand round function could be expanded the same way
The output messages are a good way of sending status messages from the test solution to the end user. However the control is not available as one of the controls that can be added to user interfaces.
Can this control be made available to be quickly added to a UI and linked to the execution view manager.
Also adding some kind of API interface to be able to capture these messages to a log file would remove the need to implement any custom logging mechanisms. If possible ability to open multiple file logs within the engine at the same time with each file given some kind of filter rules (for example Severity=”error” or ExecutionId=5). If logs had to be attributed to an execution ID then they could automatically be closed when the execution ended, otherwise the user would have to manually close each file which could get forgotten and TestStand end up with lots of open file references.
When you develop custom step types in LV, you often need to unload all modules in order to modify your LV code (it's faster than going on your step type definition, clic Properties -> substeps -> specify code module -> edit...).
A keyboard shortcut to 'Unload all modules' would be so nice to even speed up the process !
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. 🙂