NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (7)

Because of the way .NET applications and assemblies are invoked in TestStand they are a child process of TestStand. This means that they share TestStand's resources. For most applications this is not an issue but if the application or library being instrumented by TestStand is resource intensive this creates a significant problem. In the scenario that served as the impetus for this suggestion we saw performance 1/10 that when running the target application outside of TestStand.

To correct this I recommend the .NET adapter architecture be changed or be able to be configured such that instead of directly instantiating target applications a call to create an object with a .NET adapter would create a separate process that consisted of a TestStand WCF client wrapper process that would host the target .NET process and communicate with the parent TestStand instance via WCF.

Here is a simple block diagram of the intended architecture:

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

I have seen multiple customers who have encounter the following error:

Error: The following VIs or Project Libraries have duplicate names
You must change the names or add them to project libraries:

The issue sources from installing a TS deployment onto your development machine. It is not recommended. And though the deployment will be able to execute, it can also cause undesired linking errors, as shown in these cases. As a result, some of the VIs called are looking to SupportVIs (even in your development sequence), and other VIs called are looking for the same named VI in vi.lib. There can't be two different VIs with the same name, unless they are in two different libraries.

I suggest that we implement a warning when such an installation is started or even an error which prohibits installation fo the deployment.

View All (7)

Hello all TestStand users,

How often i had to debug my sequences ... to find out after many minutes that some of my steps are Skipped !

It would be nice to highlight the skipped steps by default ... (Without having to customize something in TestStand)

By using a stroked font to view the step détail (~~STEP SKIPPED~~)
By using a red, flashy color (STEP SKIPPED):smileyhappy:
Or better, both ... (~~STEP SKIPPED~~):smileyvery-happy:

Thanks for your help ...

Manu.net

View All (1)

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 use an edit step to modifiy the values contained in your step inputs/outputs, the fields are not updated with the new values. You have to close the step tree branch and reopen it to see the updated values. A good idea would be to refresh the step section after the execution of an edit step !

Please make possible to select LV Development System version in similar way as it is possible to select Run-Time Engine.

It also should be available in TS API.

That will allow Test Engineers to use code modules (especially those inside .lvlibps) from different versions.

It would be also useful for to set up desired version of LV for code modules without lack of debugging options of Run-Time Engine calls.

I use the Stationglobals.ini to define my hardware settings on the test PC, like comport number and so on. It is running Teststand Base Deployment.

If I want to edit the settings it's only possible if I copy the stationglobals.ini to my development PC which has the full license, edits the settings, and then copies the file back to the test PC. Before I copy the file to my development PC I need to make a backup of the original file, so I don't get the settings on the development PC overwritten. Then afterwards I have to re-establish the backup.

This is a lot of copying back and forth, which is quite annoying.

Please make it possible to edit the Stationglobals.ini directly on the test PC with the Base Deployment Engine.

DotNetAdapter: Help Button

View All (1)

Hello,

For the moment, the precondition builder editor only allow to check steps status or to create custom conditions.

It would be nice to add a way to test the current sequence Status.

To handle this, i create my own custom condition by using the runtime variables Runstate.SequenceFailed and Runstate.SequenceError.

The problem is that these variables doesn't exist at edit time.

I think that adding this feature to the precondition builder editor could simplify our work.

Thanks.

Manu.

View All (1)

View All (2)

Provide error logging

View All (1)

It is not possible to perfrom manual selection (for example, between different products to be Tested by the sequence file) in TestStand by using the Message Popup.

It would be great if a TestStand Message popup had pull down list or radio buttons or etc. to provide manual selection from a list.

pull down list and the picture paths could be populated from a 2D array, something similar like this LabVIEW VI:

The reason why I requested this feature is that I am developing a Test solution, where we have to

manually select the product to be tested. My test solution will be used by lots of Test Engineers in the future.

I know that this feature can be realized with a LabVIEW VI easily, but this case, I have no control on the arrangement, layout and stile of this dialog box in the future. In LabVIEW, the pull dow list, buttons and picture can be put everywhere

TestStand would provide a standard arrangement for this dialog.

Recently I have been involved in 2 Projects which deployed the test solution to PCs with disconnected deploy licenses

On both projects it was very labour intensive, there were some strange failures that were seen , related to the different licences and which were only highlighted when running with LVRTE and Teststand base deployment license. On each occasion it felt that even though the development machine had proven the solution it still required significant effort to prove and integrate the deployment image

My suggestion is to allow the developer to configure their development PC NI licence manager to replicate the PC that will run the deployment.

The Development machine would obviously need to have the development suite licences, all child licences related to the development licence would be available in the NI Licence manager . The developer would then have the option, to configure the licence manager to use the desired licenses. Ie TestStand Base deployment & switch executive deployment.

With a TestStand solution on a development machine the deployed image could then be tested before its deployed to its destination PC

ie.

1.The adaptor settings can be changed for the code modules to Run Time

2.The TestStand Search directories can be configured to use the deployment target image

3.And the licencing could be changed to replicate the deployment PC

Realise that points 1 & 2 above should iron out most of the issues with the deployment licence and its mainly on new deploys that the integration is painful, but having the option to select the licence to test on the development PC will help a lot to speed up the integration.

NI TestStand Idea Exchange

Remove bold text for Label Description in Step Settings

Host .NET processes outside of TestStand's application space

optional Autosave for the sequence editor

Deployment utility must warn and or ignore LabVIEW's separate compiled code flag.

Analzye a Subsequence within the Main Sequence

Pop up to stop or at least probit Deployment on Development machine

Please highlight the skipped steps ...

provide cancel button on loading express VIs dialog

Separate or Shared file global selection setting is not obvious

Adapter drop-down list box in tool bar should show more information.

Update step fields after using an Edit Step

Programatically allow to select LV Adapter Development System version

Make it possible to edit Stationglobals from the Teststand Base Deployment License

DotNetAdapter: Help Button

Add the ability to test the sequence status in the precondition builder editor ...

Ability to remove button on Message Popup and performs other customizations

Provide error logging

Add ability to use TestStand message popup to perform selction from a list

Teststand/Labview/CVI/Switch Exec etc.. Licence selection

Column Resize Indication if Column is Resized so that it Disappears