NI TestStand Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Currently the message popup step is quite primitive.

 

It would be good to enhance the functionality of this step.

 

Proposal: pressing the any button definied should be able to trigger the set of TS commands (as in Statement step) definied for any button.

 

In this case it would be helpful in that way that developers won't be needed to program separate modules to process the flow control flags and user interface popup.

Hope it will be good to have AddArrayElements in TestStand (OperatorslFunctions) which will reduce effort using Loops to do the same function.

Add Array Elements.PNG

It'd be neat, in the scenario when a parallel thread is called, if there was some smooth way of gathering the results back into the main thread of the execution for the sake of the report. 

 

I've handled this historically by passing a parameter into the subsequence/thread with the ResultList-index of the parent-step, and then doing some notification based handshaking during cleanup of both threads to quickly copy the Result container out of the sub and back to the parent via API calls. But I bet the R&D types could do this far slicker and reduce the whole thing to a checkbox... 😉

 

21413i267B71BB01EB46E5

 

When I create reports they usually look like:

21417iA1EFA6BABE8471F4

 

I just think it'd be a simple feature to add for users who might be uncomfortable with the API  & ResultList? (Naturally if the sequence doesn't wait at the end it may never be safe to 'pass back' results. But if you're already killing time on the back stretch, why not copy the block up?

 

Cheers,

 

Elaine

There should be an Engine Callback that is executed as the very last step in the order of step execution that will execute regardless of any and all settings or step results: the PostStep "No-Matter-What" Engine Callback.  I have a requirement to perform certain actions at the end of every client sequence step regardless of step, station, report settings as well as step results (Status, Error).  Right now, the callback that gives the best coverage is ProcessModelPostResultListEntry, but this does not fire when client sequence developers set Result Recording Option for a step to False.  My requirements call for my actions to execute whether or not the developer of the client sequence desires the results to land in the TestStand report or not.  As with other callbacks, if it is blank, the engine can skip it. 

 

The PostStepNoMatterWhat callback would execute regardless of all these, but as an aid to Framework developers, NI should provide a matrix for each of the default Process Models that shows which of the engine callbacks will execute given the following data:

  1. Step.Result.Status {Done, Skipped, Passed, Failed}
  2. Result Recording Option {Enabled, Disabled}
  3. Step.Result.Error.Occurred {True, False}
  4. Run Mode {Normal, Skipped}
  5. Ignore Run-Time Errors {Enabled, Disabled}
  6. On-The-Fly Reporting {Enabled, Disabled}
  7. Error Dialog Selection {Ignore, Run Clean-up, Abort}

 

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-ProcessModelClient-How-to-access-the-results-from-the/td-p/2796658

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.

 

 

 


Other post: https://forums.ni.com/t5/NI-TestStand/Accessing-measured-data-from-further-steps/td-p/1144710

 

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.

 

Hi,

 

I'd like to propose a new feature for consideration. I'm missing the feature using which I could measure how long it takes to execute the freely chosen block of steps. To do this the new step would be needed.

 

Let say the step type name would be: "Time elapsed".

 

User would be able to specify the name for every instance of the step used, in the way as we can use the names in Rendezvous instances. And exactly as it is done in the rendezvous step type it would be some operations associated with that step type.

 

1. First call of "Time elapsed" step type would be called wit the operation: Create. The one obligatory argument would be the name.

2. Every other call of this step type with reference to the same name, apart from the last one, would be optional. The operation name this time would be Lap Time this time. The step would return the amount of time has gone from either the Create operation or the previous Lap Time operation.

3. And the last call of this step type with reference to the same name should be invoke with the operation called Finish for example, and it would return the time has passed from the first call of the step (with operation Create).

User would be able to create a lot of time elapsed type gauges, distinguish by their names.

 

This functionality would allow to measure the speed of the sequence during execution.

 

Example (sudo code):

 

TimeElapsed.Create("test01") //somewhere in the sequence

...

TimeElapsed.LapTime("test01") //somewhere in the sub-sequence

...

TimeElapsed.LapTime("test01") //somewhere in the sequence

...

TimeElapsed.Finish("test01") //somewhere in the sub-sequence

 

Values returned respectively could be:

0s

32s

35s

107s

 

Kamil

Hi,

 

I suggest being able to group steps in a sequence:

 

TS_Group_Steps.png

 

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.

 

Cheers,

Steen

In every TS step we have the looping feature. I find it very elegant feature which allows us to save implementing full loops for singular steps.
 
I wonder if some statistical information to the looping feature can be added to the looping feature.
 
We could image that there is a step with the i.e. LV module which is responsible for acquiring one sample of data. Let say the sampled signal is noisy. It would be fantastic if we can use this singular step which acquire singular sample and the looping feature of the TS step to get multiple samples and to have a statistic the samples taken. The statistic could be:
--averaging
--mediana
--standard deviation
--etc...

Hello,

 

It would be nice to VIEW errors which occurs in the process Model or callbacks using a special dedicated window.

 

Recently, i have send updates to one of my customers, using FTP transfert.

The updates consists of processModel updates, dotNet assemblies ...

During the FTP upload by my final customer, the dotNet assemblies were marked, by windows 7, as "Bloqued" Smiley Frustrated. (For security reasons ...)

These assemblies were called in my process model.

When the final user tryed to launch his application (Operator interface), nothing occurs Smiley Mad! The dotNet assemblies calls fell in error, but without any message. I had to investigate using debugging tools to find out the problem.

 

It should be nice, in case of "anormal errors" in process model calls, or in callbacks (like frontend callbacks) to launch an error window to view this kind of errors.Smiley Wink

 

You may say, you should have test the errors and handle them correctlty ... and you're certainly right !

But i get a look to the default processModels provided with TestStand ... and they are coded as i do !!!!

So even with the 'default process model', if an internal dotNet error occurs (missing sub assemblies, no more ressources ... ) the same kind of anormal behaviour could occured !

 

So having the way to view process Model, or hidden callbacks errors will perhaps be interesting ! Smiley Happy

 

Thanks a lot.

 

Manu.

Now, if the number is exactly in between if two integers, TS rounding function uses bankers rounding method as a tie-breaking rule. Although bankers rounding tie-breaking rule generally secures equal statistical error distribution, in case of a need of rounding numbers with only one decimal place this tie-breaking rule produces output which could be different than - let say a natural - expectation. 
 
For example if we have a group of numbers like below:
 
{-2.0, -1.5, -1.0, -0.5, +0.0, +0.5, +1.0, +1.5, +2.0}
 
the basic expectation is to have them rounded like that (round-half-up):
 
{-2.0, -1.0, -1.0, +0.0, +0.0, +1.0, +1.0, +2.0, +2.0} 
 
However, using banker-rounding method instead of the rounding as above we see:
 
{-2.0, -2.0, -1.0, +0.0, +0.0, +0.0, +1.0, +2.0, +2.0}
 
I think round half up tie-breaking method option should be added for developers to use.
 
BTW: (the + and - signs and .0 notation are used just to keep the numbers to be easy to compare)

To change the step name the command Step.Name is commonly used.

 

However, if the step contains multiple measurements, changing their names dynamically is impossible.

 

It would be good if this opportunity would exists.

 

 

Hello

 

Execution of a single step is a process executing a lot of steps depending on looping and synchronization. Needing the option to call a PreExecuting and PostExecuting step before taking Looping, PreConditions and Synchronization options in consideration and after all other steps are executed. This is intended to custom step types for use with external customers.

StepExecution.png

StepType-SubSteps.png

 

Thanks Vagn

When developing code for the customization of the User (Operator) Interface, I would like the capability to provide my own custom dialog box for “Loop on Selected Steps” by overriding the standard dialog box that TestStand provides. TestStand provides this standard dialog box when the command kind “Loop On Selected Steps Using” is executed.

 

The problem in our production environment often is our production technicians are required to (manually) perform interactively with a series of sequence steps and repeat those steps 29 times (Our strict regulatory guidelines). Most of our technicians are technologically challenged in our production environment. In our environment, I have developed the TestStand User Interface to where the TestStand Execution and Sequence Views are hidden to production operators but visible to the developers (engineers) and administrators for trouble shooting capability.

 

If a custom dialog box cannot be done, at least provide the capability to where I can programmability change the properties of the “Loop On Selected Steps”. At least allow the dialog box to be programmability set to where I can set the number of loops, set the stop condition, stop expression, enable/disable the controls or hide the dialog box without the operator needing to manually entering those values into the dialog box.

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.

Being new to TestStand, this idea may actually already exist, but it would be great if there was a way to show what references are either still open at the end of an execution. I am having the dickens of a time identifying open refernces with very large scale programs, and if the open references overcome TestStand and it crashes, there seems to be no way of finding out why, assuming open references are the major player.

A TestStand configuration wizard

 

I would like to see a TestStand configuration wizard that would walk a developer through a checklist of all of the most important configuration settings and generate recommended changes.

 

It is best for a developer to be already familiar with Best Practices as in the following link:

 

Best Practices for Improving NI TestStand System Performance

http://zone.ni.com/devzone/cda/tut/p/id/7559

 

However, it would also be nice to have assistance in recording WHY certain choices are made as shown in this image:

17669iC6E2378DE5CA3B29

 

 

Eugene

When test cycles run and fail for some reason, sometimes LabVIEW will either crash or get hung and wont close.

 

Even when exiting or restarting Teststand, LabVIEW does not close properly...or re-open properly, locking any HW resources. Non-technical savvy operators are unsure / do not know what to do.

 

If the operators were notified with a pop-up informing them of a windows restart is needed to clear LabVIEW PRIOR to even the login prompt, that saves a lot of false start/false fails and headaches.

 

We have implemented this in the "FrontEndCallbacks.seq" and works great for false-fail runs.

 

Teststand should have this implemented built-in.

It would be nice to have the option of making an Enumeration of Expression type and be able to use the Enumeration directly in an Evaluate() expression.

vrv_0-1605611723913.png

 

The expression might look like this investigating if "operator" have technician rights Evaluate(Enums.MyConstants.Techincian)

In synchronization  Notification with Wait as an Operation, then there should be Time Out status (Optional Output, Available as a property now) based on which the user can take decision.