It would be really nice to be able to call LabVIEW functions (primitives) directly from TestStand steps instead of having to create and call wrapper VIs for them.
When creating custom step types, it is highly recommended to use Post-Step for calling execution module instead of Default Module.
Thus, when instanciating a custom step type, parameters passing is not saved within the sequence but only in the step type definition.
This allows to change parameters passing without having to update all the step types instances.
In some big test benches, it is intersesting to have low-level step types and high step types based on low level step types.
High level step types execution modules are sequences using low level step types.
Since sequence adapter is not available for Post-Step, we are obliged to call the sequence through Default Module.
Thus it can generate problems when adding parameters in sequence call.
I suggess to allow Sequence Call in SubStep creation :
Jean-Louis Schricke, MESULOG
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
In current TestStand version (2012), it is possible to view the list of enum values of dotNet adapters parameters.
This is great ....
But it should be nice to add the enum corresponding numeric value in the dropdown list.
This could be helpfull if you had to create a numeric TestStand variable to map to the enum parameter ... and because there are no correspinding enums in TesStand !
Thank for help.
I think it would be a great idea to allow the sequence adapter to expand containers like the CVI and LabVIEW adapters do when you are editing the module for the step.
The menu to create a new variable (right click on variable in an expression edit control and select Create "VariableName") contains all the data types you can use for the variable, however, in the LabVIEW Panel (and other similar panels or dialogs) there is enough context information about the variable to suggest a data type, for example, if the variable is in a control of type Double we know we should create a Numeric variable. TestStand should add the contextual suggestions to the top of the context menu and bold them so that I can more quickly select the data type I want most of the times, then have a separator and put the normal menu so if I don't want that data type for some reason I can still choose the other data types (see attached image).
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.
It would be nice to integrate VeriStand into TestStand with a VeriStand Adapter.
This would make developing with TestStand and VeriStand much easier. The adapter would provide a lot of the VeriStand .Net api natively to testand:
- Deploy a system
- Set/Get Channel(s)
- Stimulus Profiles
The adapter would be especially nice for integrating the new Stimulus Profiles in VeriStand 2011. It would allow for you to create the Stimulus Profile sequence and the Real-Time sequence. The Real-Time sequences would only be able to use a subset of TestStand steps, and would have to be different than a normal TestStand sequence because they are executed by the VeriStand engine, but the Stimulus Profile sequence could be a normal TestStand sequence.
The integration of the Stimulus Profiles would leverage a lot of features TestStand already has like source control, requirements, reporting, etc. Also, it would just give the user a much more intuitive experience when using the two together. Their test development would be centralized in TestStand instead of having to switch between the two different editors. It would also give better access to the parameters being passed into the Real-Time sequences at the TestStand level.
There are probably more benefits that could be realized by integrating TestStand and VeriStand, and this is a feature I would love to see as a user of both TestStand and VeriStand.
I am a new user of TestStand for about 6 months or so. Please pardon me if this post is duplicate ... I did a basic search to make sure it wasn't.
Test Stand is able to load a cluster from LabVIEW and show its elements, very cool.
It might be awesome if a Container in TestStand can be loaded into LabVIEW that'd do the same.
The NI-VISA Adapter could present steps that would related to the VISA Interactive Control application (Write, Read, Write from File, Read to File, Assert Trigger, Read STB and Clear). This would allow a developer to create a sequence that checks/calibrates a test station consisting of source, sense and fixture loop-back elements with out dependence on a particular adapter or version of an adapter.
I admit that the IVI adapter is already available, but not everyone uses ( or likes ) IVI technology.
LabVIEW recognizes any cluster of <Bool, I32, String> as an error cluster. TestStand should recognize this as well and default any such cluster output to Step.Result.Error.
With the addition of the Silver controls in LabVIEW 2012 "error out" was changed to follow the style guide recommended naming convention of leading caps and is now labled "Error Out" which is not intercepted and assigned to step.result.error.
support capture of std output and std error to variables while displaying normal 'dos' window
maybe by integrating duplication or cloning of the std output and std error streams, like the tee function provides in unix
It is nice to have a dos window visible while running executables that take a while to complete.
Often it is important to capture output from executable for parsing.
Currently, if you assign output to a variable, the dos window is not visible.
The usual Insert Step menu in TestStand:
What the menu might look like with a Insert VISA step:
A VISA>>Write step would replace a LabVIEW Action Step such as the one I used below for direct Instrument control from TestStand. Queries would look similar and be able to set limits on the returned value.
LabVIEW VI for the power supply command to the VISA instrument setup from M&A Explorer.
This is “PS1” in Measurement and Automation Explorer uses Alias Name.
Example of Query instrument to an Agilent 34970A using Alias Name “DM1” setup in MAX.
However, a little more complicated than a single string command from the menu. Might take several Write steps first.
When LV throws an error, it's all very easy to catch via callback and/or is auto propigated through the system to Runstate.SequenceError etc.so it can be detected.
When LV throws a warning... the data doesn't seem to go much of anywhere in TS... and unlike LV it doesn't propigate from step to step either.
I'd like to catch and log these warnings in my error handlers (naturally with different logic, but I don't want to lose the data either, it's important sometimes!)
from poking around, it looks like my options are:
(1) creating a custom steptype wrapper around all LabVIEW step calls,
(2) editing each VI called by TS manually
(3) some fun expression(s) in the 'add additional result' or 'post expressions' sectionsof each LV step, to create new variables in TS on the fly... (or using a post-step callback to do the same)
It would be nice if the LV adapter / LV steptypes had some native way of catching this 'almost error' behavior and getting it into the report at least. I don't know if leaning on the error callback is the right answer, since, afterall, these aren't errors... but having a warning callback feels too LV specific...
How about a checkbox in the LV adapter, where you could specify 'treat warnings like errors' and then in the Error callback you could check to see if the bool was false, and punt as desired?
Is there something I'm not seeing that would be a better solution?
Allow the configuration portion of steps that call DLLs to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).
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.