NI TestStand Idea Exchange

Currently, the only way to pass parameters from a subsequence to a caller is by reference.  It would be nice if you could also pass parameters to callers by value to prevent the callers from modifying them.

Using the stock reportgen_xml.seq file, the text value of the XML node shouldn't contain the characters < or >:

http://www.w3.org/TR/xml/#syntax

When using LabVIEW VI's to parse this, you (rightly) get errors, so it's incredibly difficult to just search and replace the offending characters with their XML escapes. 

Example node contents from the XML report:

<Prop Name='ReportText' Type='String' Flags='0x400000'>
                            <Value><![CDATA[{0} Locals.i = 0; Locals.i < 2; Locals.i += 1]]></Value>
                        </Prop>

When monitoring values within a loop in TestStand, it is often desired to only record step failure results.  It would be useful to have a "Result Recording Option" of "Enabled On Step Failure":

This is possible through various means (SequenceFilePostResultListEntry callbacks and other custom code).  However, I believe this would simplify TestStand sequence development significantly.

Similar to the SequenceFileLoad Callback but for any sequence file using that process model.

One use case would be invoking a splash screen with company information.

We have several sequences which are too long to execute (test stand crashes during the initial load) using the preload option.  These are often sequences with 50-100 subsequences which define contiguous tests to be performed.

If Test Stand had a 64 bit version additional memory would be a solution to this problem.

See this post

Testing date / time values (Specifically from .NET)

HI

It would be nice to make Sequences public or private within a SequnenceFile.

With this you where able to make powerful SequenceFiles librarys.  The biggest advantage of this

is you can show the consumer of the library only the "important" public sequences. The

private ones where invisible. This will help to avoid errors.

Regards

juergen

I'd like to be able to specify the username, password, and local & remote paths by expression:

loading express VIs can take a long time on a slow computer

occasionally I press the express VI button by mistake and have to wait and wait

Right now I can configure search directories in TestStand, but I am limited.  There are 2 types: either an absolute path, or a "programatic" value (think <current sequence file directory>, <TestStand Public Directory>, <Windows Directory>, etc).  However, these "programatic" values cannot be modified.  I would LOVE to be able to configure a new search directory of "<Current Sequence File Directory>\LabVIEW_files\*", or "<Current Sequence File Directory>\..\Code Modules", but TestStand doesn't support adding modifiers to the ends of those paths.

It would also be nice to be able to specify <Current Process Model Sequence File> as another value.

This would help greatly with being able to move files around, and limiting the total number of search paths, and limiting the cross-linking of finding the wrong code modules for individual sequence files.

In a recent Test Stand training session at my work, we learned about Engine callbacks and specifically about the Load and Unload ability to run code when simply loading or unloading a TS sequence file.  In speaking with our FE, there is no was to disable the Engine callbacks and he asked that I post this request.

Without the ability to disable this feature, there can be inadvertent to malicious consequences.  The loading or unload of a sequence file needs to be passive during development so the sequence file can be reviewed and verified to be harmless before putting the sequence file out for production use.

In the inadvertent instance, a developer could produce something that they are not quite sure will work and it could produce a side-effect. It would be good to be able to open this sequence file and review all the steps before the Engine Load callback has any chance of running.

In the malicious instance, the Engine Load could be used to perform unwanted events - I.E.. Performing a system call to format the C: drive, making a remote connection to an external computer, etc. during the code load and before anyone has a chance to review the sequence file and verify that it is harmless.

The Engine callbacks are a great feature but with the inability to disable them creates a great security risk. There needs to be an option in the TS Sequence Editor to disable all or selected Engine callbacks and then a sequence file can be opened safely and reviewed before execution.

It would be nice to have the an API function to get the current progress stuff.

Allways when i am using the progress with PostUiMessage inside a sequence

I do not know what the current progress is. It would be nice to save it at start of sequence

now modify it with PostUiMessage

and on the end you are can able to set it old values again.

Regards

Juergen 

Presently we can login into Teststand using the windows login. Carrying this forward it will be good if all Teststand configurations ( ex report type,process model,search directories) are user specific.

This will need maintaining separate config files for each user.

On start Teststand will check the windows user name logged in and accordingly copy relevant config files and configure the Teststand.

globals scoped to an execution

currently I use RunState.Root.FileGlobals as execution globals

but adding a custom global there normally requires modification of the model

It would be nice if there was a station option that would set the default load option for all created sequence files.  Currently I must either programmatically modify the RunState.SequenceFile.ModuleLoadOption property with a statement in each of my .seq files or navigate to Edit » Sequenfe File Properties and change the feature over and over again.

An example of what I'm talking about is shown here:

Programmatically Update Default Sequence File Load Option
https://decibel.ni.com/content/docs/DOC-20095

Thanks!

The sequence editor's (v4.1) diff tool doesn't properly step through the differences if it encounters a "For" loop step or a sequence call step that is a homonym of another sequence call step in the diff window. It basically gets in an infinite loop that can be exited by selecting the next step in the diff window.

Also, if a parameter is added to the parameter list of a sequence and is moved before other existing parameters, the tool doesn't identify the pre-existing steps as identical. It just markes them as deleted from the first sequence and added to the second sequence (therefore it prevents proper comparison).