NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

It would be nice to have an Auto-populating folder option for TestStand projects much the same way that LabVIEW project do.

Folders added to TestStand projects are snapshots of the folder's contents when added. Any files added to the folder on disk afterwards are not marked for inclusion with the deployment at analysis time. This behavior is fine as a default.

However, there are times when you do want to automatically include all files in a folder. Having an auto-populating folder option would mark the folder and all its contents for inclusion automatically with the deployment at analysis time. After analysis is over the user could still choose to uncheck any files they wish before selecting the build button.

From version to version, it's only natural that developers will be adding new files to established folders. Since the TestStand project doesn't aid in development activities, it's easy for folks to forget to add files while they're developing. We often have a faulty build or two with each release because necessary files aren't making it into the build. We ultimately have to delete the folders in the project and re-add them, then go through the hassle of fixing the paths and included files. An auto-populating folder option that integrates with the build utility would save us time and headaches.

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)

Prefix Dependencies for PPLs

There is a major flaw with packed project libraries in LabVIEW. That is that they pull the dependencies in to the same folder as the PPL. For example if you use advanced math functions then lvanlys.dll will be put in the directory. The problem is that LabVIEW doesn't like it when you try to load multiple files with the same name. So if I have a test system with multiple ppls that use the same dependencies I could potentially run into collisions. There is a document here that discusses a solution for this:

https://forums.ni.com/t5/LabVIEW-Development-Best/Packed-Project-Library-Pitfalls/ta-p/3523762

I would like to see the option to prefix my dependencies for PPLs. This could easily be added to the Packed Project Library Options dialog.

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.

NI TestStand Idea Exchange

Add an "Insert Folder From Disk (Auto-Populating)..." option to projects for Improved Deployment Experience

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

Create Installers in TestStand Deployment Utility from Previously Created Images

Please highlight the skipped steps ...

provide cancel button on loading express VIs dialog

Separate or Shared file global selection setting is not obvious

Prefix Dependencies for PPLs

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