We work with Teststand and Visual Studio 2012.
We would like to have an option to switch between the use of the debug dll or the release dll.
Now we have to change this step by step and that's a lot of work.
Recently I've discovered misleading TestStand behavior.
In the case where in the sequence we have two steps with the same name and we'd like to refer to the SECOND step via its name like shown below:
TestStand allows us to do this, but during the execution, this reference is bind to the FIRST instance of the step:
In this caseTest D should fail showing result 12 not 10.
So, TS allows me to pick a step I want, however it looks like TS binds it to the first match on the list; so it is a lie.
In my opinion TS should either:
--don't let me do this, or
--implicitly bind it using unique step ID.
Anyway the current behavior (TS2014) is ambiguos and shall be treated as a bug.
It looks like there is no "gentle" way to access the results of the executed tests in ongoing execution during this execution.
Sometimes there is a need to access the test results during the execution, before the data will be committed to the database, and execution is still ongoing. The reason for that could be we can reuse the some data of the test in other tests, or we can use for example the status of the test to drive the flow in our sequence.
It looks like there is no other general way to do that as only described by Sasha here: http://forums.ni.com/t5/NI-TestStand/RunState-Proc
So, theoretically, - please read Sasha post - we have recipe to access all results we want. However, problem with accessing the result list is that, that it is done via the index of the ResultList array.
It leads us to two problems:
1. the elements in that list depends on the step position in the sequence file, which makes the editing sequence almost impossible,
2. if our sequence contain loops the problem from the point above is even more impossible.
Therefore, the idea:
Please prepare the easy accessible, not index based as it is now, method (container?) which developers can access the Results containers of the steps on the fly during the execution.
Handler proposal 1:
Step name (binded as unique ID) + execution order number
Handler proposal 2:
Callers path + StepName +execution order number
where execution order number could be the handler which could be number 0 by default unless the step is called few times.
In thw Sequence editor, in Tools -> Update VI calls - > Type of calls To Update -> Process Standard VI Calls another two entries could be added in the combo box. Apart from existing:
* Report Problems Only (No Changes Will Be Made)
* Reload Prototype if Modified
* Force Prototype to Reload
These two options below shall be consider to be added.
* Resave (recompile?) Code Module (VI)
* Resave (recompile?) Code Module (VI) with all dependencies
I think this feature could be used in case like happened to me:
I had to update one of my global TypeDefinition (*.ctl) which is called by a lot of VIs from my project. When I did it, a lot of VIs were suddenly unable to load under RTE. So, manually I had to open every VI called by TS and do Open and Save (accepting recompiling) actions. I don't have to tellyou that was very boring and long task...
In the bottom right corner of the Sequence editor window (or in other place if you find more suitable) please display information about type of the adapter server.
For example for LV Adapter it would be information about whether Adapter is set to wok with LV Development System, LV Runtime Engine or other executables. For HTBasis Server it would be HTB Runtime Server or HTB Development Server.
During the development I have to often switch between LV Dev environment and RTE. To do that you have to click three times to go trough modal window to get this information. If you do this often it's getting painful.
It'd would be good if in the Step settings for LV modules we can have a button which can trigger the test saying is that module going to work when we change Development Environment (DE) to Run Time Engine (RTE).
Now, in case like this, we have only a dry information saying TS cannot load the module because probably VI is broken. Problem is, when we switch over to DE VI is NOT broken.
Of course the reason behind is that RTE has not enough information to call one of dependencies, or there is ambiguity in calling a sub-module - for example a dependent sub-module is used called by step earlier.
So, summarising, the test like that would be quite needed (saving time of development), and information returns shall be more detailed indicating the sub-module cannot be loaded by RTE and why.
Now, the PropertyObjectType.TypeName property returns the type name of the named type only.
I propose to extend the list of the returned type names to ALL types: build-in, custom named data types, standard named data types.
Moreover, it would be good if the NI can be more clear in documentation reminding users what the named type is, as it can be mixed up with the build-in data types.
As in the subject: Get the focus out from the OK button in the Expression Browser window.
Now, when you write an expression in the Expression Browser and you'd like to go to new line by hitting Enter, instead of going to new line the Expression Browser closes down.
O course we can use Shift+Enter combination to get to the new line, but the habit is to hit the Enter key.
However, if the focus would be not on the OK button but inside of Expression window the problem would dissapear.
In some cases it could be handy, if you were able to convert a container you've constructed in the variable pane into a type directly from the variables pane.
One case could be, if you chose to store some settings in the sequence file, but the settings are dependent upon fx equipment or the product variant. It can be handy to have a variable with the settings, and an array of settings specific to various configurations from which you can choose. But the 'settings' container and the type in the array of settings containers, of course have to align. And this is best achieved by a custom data type.
Often sequences start out for one configuration only, and later on the need for multiple configurations occurs - and that's why I think it could be handy - if you were able to convert a container, already in the variable pane, into a custom data type.
I suggest being able to group steps in a sequence:
Steps that are grouped should in interactive mode be forced to be handled together, e.g. "Run selected steps" would always select all the steps in the group. This way you could re-use certain steps multiple times down the sequence without allowing such steps to be executed by themselves (or the opposite, make sure certain steps were never executed without surrounding safeguards).
Today we'd usually enclose such must-work-together steps inside sub-sequences, but that solution does not safeguard against selecting a single step within that sub-sequence for execution by itself, and sometimes putting steps in a sub-sequence is non-optimal (one such case is when you have disabled tracing into subsequences, but this particular set of steps you'd like to have tracing on - I know there are ways to go about this, but these are cumbersome and non-trivial to spot when editing the sequence).
I wouldn't add any extra configuration options to a group, it should simply be a group/ungroup thing - all settings still being on a per step basis.
The use cases for a group could be expanded into making it easier to select a co-working set of steps for copying and pasting, it would be a good way to document co-working steps and so on.
One of the only paths (if not the only path) that can't be specified by expression in TestStand is the substep module in a custom test step. A substep module must currently be statically defined.
For advanced architectures it would be nice to be able to define substeps by expressions instead of statically (in one project this was a showstopper to the flexible architecture we attempted to implement).
I'd prefer TestStand worked the same way as LabVIEW, such that it'd allow multiple versions open at the same time. Other than probably some stuff internal to the TestStand architecture* I don't see any reason for the version selector.
* It's probably due to the ActiveX API having the same server and method names between versions, but that can be worked around if necessary.
As NI has acknowledged (here, here) for more than 5 years, the Build .sql File button creates schemas with errors. This is even true for the default schemas in the left of the dialog. Would be great if NI would go ahead and correct this. BTW - to create default tables in the meantime, a developer should use a SQL file located here: <TestStand>\Components\Models\TestStandModels\Data
I'd like to see a "No Comparison" comparison type added to the String Value Test.
Currently there are only two options for comparison type on the String Value Test: "CaseSensitive" and "IgnoreCase". I have often wished there was a "No Comparison" option similar to what is available for the Numeric Limit Test. Sometimes you want to pass a string to the test report in the result field that neither passes nor fails the test.
When you select the "Unlod modules" in the module, you have no result message: user can't know if modules were really unloaded or not.
You can see the situation with a sequence that load a .DLL extension is opened and has run: if you want to delete (or update) the DLL file windows prevent you to do. Make Unload, Windows sometimes still prevent you.
I've not found the real conditions to reproduce the situation but I think you should improve the user information with that Unload Modules function to shos, as ex, which modules have been really unloaded and which ones not.
Sometimes I can find difficult to access arrays using indexes. Although straightforward it can be difficult to maintain in certain situations, like calibration data for a lot of frequencies. Lets imagine you have a table of sixty calibration factors per frequency and forty frequencies, generated by third party software to the excel file.
It would improve accessibility if we could name columns and rows and use their names instead/along with the indexes.
We can access the array data like AnArray now. In this idea we could access the data like that: AnArray["63dB”]["125MHz"].
When we would like to import the data using property loader it would be easier to access the data with defined names of colums and rows rather than indexes. (data binding)
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.