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.
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.
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.
For the moment the runtime error handling can be managed by using ...
It should be nice to add such a kind TRY CATCH block, in order to modify the error handling in a local section of a sequence.
case 35 // Error code = 35
case default // All other error codes
Doing so, could be a way to handle runtime errors, in an other way that the global configured way.
Since not every path on the hard drive can be in the drop down list, and some may be higher up in the tree from paths that are in the drop down list (and some may not be there at all) it would be great if we could specify relative paths and/or environment variables.
TestStand Application Data (for Windows 7) = "C:\ProgramData\National Instruments\TestStand". But, I want to install a file structure starting at "C:\ProgramData". Currently, my only options are to write a custom command to copy the files over after install to some other directory that's in the combo box. But this isn't great because things can be easily left behind on uninstall.
With a relative path, I could specify the subdirectory of to be "..\.." and with Windows environment variable support, I could specify %ALLUSERSPROFILE%. Either would take me to "C:\ProgramData".
Having tried both of these in TS2010sp1 installer builds, neither of these seem to be supported, and it would be awesome if they were in the future.
The current placement creates confusion about what you’re actually closing out of when you click it. It makes me hesitate and wonder what I am about to close.
If you click it when there are multiple files open, it just closes out of the tab on top. If you click it when there is only one file open, it closes out of the whole pane, including the Sequences and Variables windows.
It would eliminate any ambiguity if the X for each file were on the tab for that file and if there were a separate X for the pane, like you typically see in tabbed programs.
You could also just put an X next to the pin on each little window instead, like the X in the Step Settings pane and the Insertion Palette in the screenshot above.
To change the adapter settings every time instead of traversing from configure tools menu it would be extremely convienent to launch the adapter configuration dialog box by just double clicking on its icon available in the insertion palette.
Present implementation :
Left single click on icon sets it as the active adapter. (Requires 4 clicks)
New request :
Double click this to launch the adapter configuration dialog box.(Requires one double click)
This execution analyser ( an option since it may slow down execution) will analyse the UUTGener executions and recomend user for improving the perfomance.
Few things that i can think of is :
1) If a debug DLL is running which if replaced will improve speed.
2) Check for memory leaks.
3) Generate list of steps which are logged many times ( example in loop which may not be requied to log)
4)List out steps which are taking long time to execute( say top 5)
5)List out steps whose execution time is inconsistent ( varies considerably from execution to execution
These are few of the things that i could think of.There maybe others.
Recently I've discovered that it would be very useful if developers can have a function which allows them to re-initialise all variables and limits containers for all test steps to the default value.
By default value I mean the state as the variables and limits containers are just after the sequence file is open.
This function would be used in the situation when the test station is testing a lot of DUTs one after another and as a result of this the MainSequence is called, but not re-loaded, every DUT tested. Without this function, as it is now, developer have to explicitly reinitialise all variables they are interested in. However, it causes the risk of forget to refresh/reinitialise some variables, which could lead to long and costly debugging.
Proposal (sudo code):
It looks like to implement it on the sequential model needs a lot of modifications. http://forums.ni.com/t5/NI-TestStand/Loading-defau
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
Right now, you really can't reliably use anything other than a basic ASCII character set in TestStand, which means that some SI units (such as ohms) cannot be represented in their preferred way (with an omega). It also means that you can't put non-english characters in your sequence file and reliably have them show up if your sequence file is opened on a different computer with a different language localization (which causes a huge problem if your customer demands support for non-English languages, and has more than one site -- that speaks a different language -- around the world).
Make TestStand support Unicode, so we can use the full greek character set for things like units, and so we can type characters from any language in our sequence files, and not have them change to a different character if we open them on a computer with a different localization.
The settings field can easily become too long to see every active option and there's not necesarily any consistency between steps if they have differing options. What I mean by that is if you only set the "Do Not Record Result" (my favorite) option in one step, it will be on the left of the settings field. But if you now set several options on another step, the settings are not lined up so that it becomes hard to see at a quick glance which steps I forgot to not record (because TS still doesn't default to not recording steps). You have to analyze the settings line for each step.
I propose something more graphical and ordered. Here's my idea of at least ordered. The text could be replaced with icons representing each setting.
Then it would be graphical, ordered, and concise. What more can you ask for?
Currently the Selected Adapterdrop-down list box in tool bar shows only the adapter name example- LabVIEW. If user wants to know if the current setting is using LabVIEW Run-Time Engine or LabVIEW Development System or even the active LabVIEW version, he has to launch the configuration dialog box.
The combobox should also indicate if it is set to use LabVIEW Run-Time Engine or LabVIEW Development System along with the version. Refer image for details.
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.
It isn't uncommon to deploy customized TestStand options, such as search directories, on a deployment computer. It would be much easier to do this if the search directories in TestStand were stored in their own .ini file rather than in TestExec.ini. You can obviously set the search directories in TestExec.ini quickly using the built-in search directories GUI, but when distributing the TestExec.ini file to the deployment computer, you have to be careful that none of the other options contained in the file don't inadvertently cause problems when executing TestStand deployments. A separate .ini file for search directories would clearly remedy this situation.
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
When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help. While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help. I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.
This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users). Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.
Often working with Full Featured UI and Simple UI codes to create custom interfaces for TS, I noticed that the versions shipped with LV2012 are full of deprecated functions.
Also, most of their implementation go against good LV coding rules.
Re-writing them could be a great idea !
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.