NI TestStand Idea Exchange

Community Browser
About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

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.

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

Hi,

 

Test tand is very useful to me and always feel thanks. Nevertheless sometimes I feel that how about hide skipped steps, sequence and something like that. If there is a function of "Hide skipped step or Hide skipped all", I will obviously use them every 50 times. 🙂 

How do you think about this suggestion?

 

Thanks in advance.

The separate compiled code flag is great when using VIs and source code control.

 

However TestStand (2016 SP1) deployment utility builder does not warn if the separate complied code flag is set - This means the VI will not run with the TestStand Deployment Licence without a LabVIEW development system installed. 

 

I do think the the Deployment utility should have a checkbox to force include the compiled code in all VIs and Controls so it can be run easily with the TestStand Deployment licence and LabVIEW runtime engine. 

 

Suggested because I have pulling my hair out wondering why a VI on a deployment machine won't run. 

Turns out a type def control had separate compile code flag set!  I even wrote code to clear this flag on VIs and all subVIs - it never occurred to me to check controls!

 

Also please update the error message in TestStand:

----------------------------------------
Details:

Parameter 'UUTServiceType': -This was a bit of a clue... but the TestStand type matched when I recreated it.
Unable to load VI 'Dialog - Prompt to connect UUT.vi' with the LabVIEW Run-Time Engine version 17.0.
The version of a subVI might not match the version of the run-time engine and the Version Independent Runtime feature is disabled or a VI dependency might be missing.
Try the following steps to troubleshoot the issue:

1. Open the VI in the LabVIEW development system. If the VI is broken, fix any errors in the VI.
2. Force compile the VI by clicking the run arrow while holding the 'Ctrl' key.
3. In LabVIEW, select File >> Save All to ensure that all subVIs are saved in the same LabVIEW version.

4. Check that the separate compiled code flag is not set on the VI or its dependent subVIs and controls (typedefs) when using the LabVIEW Runtime engine. 
----------------------------------------
Error Code:

-17600; Failed to load a required step's associated module.
----------------------------------------
Location:

Step 'Prompt User to Connect UUT' of sequence 'MainSequence' in 'My testsystem.seq'
----------------------------------------

 

{edit1} I also have just realised that running the code with the LabVIEW runtime in adaptor settings worked fine on my development PC as the control's code was in my local object cache. So I was also wondering why it worked fine on my development machine and not on the deployment machine when using the LabVIEW runtime.

Therefore the Runtime adapter should have a setting  to either Disable the Runtime using the local object cache

or an option ot clear the local object cache before running the sequence. This means this issue would have been reproducable on my development machine with the LabVIEW runtime adapter. 

 

I feel this idea is almost is close to being a bug.... 

 

 

 

Download All

Hi All, My code module to be deployed uses some VI's from user.lib. When I'm trying to create the deployment, in LabVIEW options I'm excluding all files from vi.lib,user.lib and instr.lib. After creating the deployment, still my code module looks for the VI's from user.lib in SupportVIs folder which is parallel to the deployed folder. I don't know why it is still looking in SupportVIs folder instead of taking it from user.lib. Please share your thoughts about this.

 

Thanks in advance!

Regards,

vani

For one of our test racks we have a PXI Rack that is full of Measurement HW devices from NI.  Recently tow of the cards in the rack were returned to us from the calibration house with OOT (Out of Tolerance) as found readings.  This put into question the product tested and shipped in the past year.  Since the test fixture is used to test 14 different assemblies, I wanted to use Teststand to generate a report that told me what hardware was being utilized during the sequence of each assembly that is tested on this fixture.  It appears that unless one intentionally adds certain system configuration information into the VI that can be read in as a variable in Teststand, that this process will be very tedious in looking at each vi called out by the sequence file and looking for HW callouts.  It would be great to have this capability baked into the handshaking between VI's and Teststand to allow for a simple query within TestStand.  c.S.

I just had an issue (SRQ#1672094 - for NI employees who want to look it up) where I tried to open a termination monitor in a sub VI which was called in a VI that already had an termination monitor running. The whole thing seemed to run properly until the second termination monitor was about to be closed. It threw an error telling me that I was playing around with an invalid reference. I was a bit confused...

The issue was solved by NI hotline in a short time - as usual: It's not possible to have several termination monitors running in this constellation and I should forward the open monitor into the subVI and use it there.

 

I wonder whether it is possible that an error message is thrown when one tries to open a redundant termination monitor. Even if LabView can't know, TestStand should be able to and respond accordingly if the function is called. It would make debugging easier.

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.

 

 

In the sequence editor, when you hover over the step name in the Step column of the editor, please display in caption the step unique ID.

Hello Team,

In the additional results of step settings, if we have long list of results to log and like to rearrange the list, it is very effort taking to rearrange using the “Move Selected Results Up/Down” control button.

It would be easy if we have

1. Option to select multiple results  while using the “Move Selected Results”  control button 

2. Option to have drag and drop to move the selected results.

 

 

MultipleResultstoMoveSelection.jpg

 

Thanks

Hello Team,

 

Currently we can’t move or add additional results above the ‘Parameters’ if the subsequence or module has parameter list. It would be useful if we have an option to move the selected result to log in the Additional Results of step settings to desired position/row.

Similary with in the Parameters list, it would be useful if we have an option to rearrage the list.

 

MoveSelectedResultUp.png

Thanks

 

Hi,

 

As in subject: allow the *.llbs, build as the Source Distributions in LV Application Builder, to work  with TestStand as indemendent application instances.

 

K.

Hi,

 

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.

 

K. 

Hi,

 

As in subject: add the possibility to define the datatypes described in .net assemblies.

 

Now developers, when they create veriables, can choose from between number, string, boolean, object reference and cointainers and arrays of these as well as from between DatabaseColumnValue, DatabesePropery Mapping, Error, Path, Expression, NI_LimitMeasurement, NI_MSgBoxFontData, NI_LV_DeployLibraryItem, NI_TDMSReference, IVI and LabVIEWAnalogWaveform, LabVIEWDigitalWaveform, LabVIEWDigitalData, LabVIEWDynamicData, LabVIEWClusterArray,LabVIEWIOControl.

 

These two groups of data types are called Custom Data Types ( number, string, boolean, object reference)  and Standard Data Types (rest of them).

 

I'd like to vote the .net types of data which are defined in .net assemblies were accessible from Standard Data Types menu along the LabVIEW datatypes.

Hello,

 

I have a sequence which must loop a very long time, with cyclic access to hardware components.

In order to limit the amount of memory used by my application i decide to use the famous "Disable result recording" flag.

 

Beside this problem, my sequence don't have to collapse in case of runtime error (Due to hardware manipulations during execution),

and operators don't have to aknowledge the "error dialog box" ... every time an error occurs !

 

To handle my runtime errors, i deceide to :

 

  • The main sequence is a loop calling the different fonctionnalities by sequence calls 
  • I configure the sequence calls with "ignore RTE", so my mainSequence never stops on runtime error 
  • I Configure the "runtime error handling" with the Run cleanup ... so no popup disturbs the operator

This is OK, but i also want to treat my errors (Tracing at least) ... and then i get the folowing problem ...

 

  • The errors are no more accessible using Runstate.previousStep.result.error... ... Runstate.sequence.main.... .... , because i have used the "Disable result recording" flag.
  • Storing a runtime error in locals is not possible in post expressions ... because post expressions are not executing after a runtime error

Perhaps the only way to handle my problem would be to use the SequenceFilePostStepRuntimeError callback ... 

But doing so, would need to use stationGlobals or FilesGlobals to get back the error in my main sequence. (A complicate architecture only to get an error !)

 

So, it would be nice, to be abble to ...

 

  • Let the result recording working
  • This make the runstate.previousstep.result.error... works fine
  • And sometimes, be abble to flush the result tree (Using a new API function. Something like <Execution>.FlushResults( ....) )

PS : My sequence don't use any report, database writing ... thats why disabling results recording is possible !

 

I don't know if i am clear ? (And with my bad english ???) Smiley Frustrated

 

Manu.

Hi,

 

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):

FileGlobals.ReinitialiseToDefault()

Locals.ReinitialiseToDefault()

ResultsContainers.ReinitialiseToDefault()

LimitsContainers.ReinitialiseToDefault()

 

It looks like to implement it on the sequential model needs a lot of modifications. http://forums.ni.com/t5/NI-TestStand/Loading-default-limits-for-every-execution/m-p/2943434/highlight/false

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

Hi,

 

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).

 

/Steen

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.

 

/Steen

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.

Proposal:

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.

 

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.