Recently I came accros situation like that:
I have a local container called AAA with the subproperty called "Name".
Then I'd like to change the name of the AAA container using the API function ".Name".
However, when I call Local.AAA.Name, instead of changing the name of AAA container I'm accessing the subproperty with this name.
I think the name "Name" should be reserved as a name of subproperty.
A coworker of my is taking the TestStand training for the first time and I asked him what he thought. He has been developing software in Visual Studio for some time now (C#, VB.net, etc). One of his feedback was the extra steps needed to create variable seemed excessive. His point gave me an idea that I thought would be very nice to have.
Currently, in the expression editor, when you start typing there will be a small popup suggesting existing variables to select. Wouldn't it be nice that it also gave you the option to create the variable right there.
Say for example I'll need to place my module return data into a variable but I didn't think ahead and create a local variable. Now, I am in the expressin editor and I start typing 'local.' and then the name of my none existing variable "newVar". The little popup that shows the existing varialbes detects that what I've typed doesn't exist and gives me a new button where I can create it and assign a data type. No going over to the variable editor window...
Recently I wanted to iterate through ALL my subproperties in the container.
I've discovered that the function GetNthSubPropertyName accessing only first level of subproperties and it doesn't get deeper into hierarchy.
I wonder if it could be an extension to this function - and to all similar functions - allowing iterating automatically over ALL subproperties. For example a new option could be applied here.
It would be good if TS could allow to do a variable multiassociation. By this I mean developers can aassociate output from a module to more than one variable at one go directly from the Step Settings window, from the Module tab, as below.
It would be very useful to be abe to specify a custom project or workspace when creating a new test using the LabWindows/CVI adapter.
This would allow developers to always ensure that any custom macros and source files are always included during development
The vi templates should use the NI reccommeded 4x2x2x4 connector
Also sequence Context should be a required connection and there should be some default documentation
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.
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.