NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

Labview Error in Test Stand

Hello all,

I'm starting to do some Test Stand sequences, and I'm having a Fatal Error that is always forcing me to close the program. This error always happens in the first run and I just can avoid it by deactivate and activate one option in the adapters configurations tab.

The error that I'm having is the next one -> "labviewv.lib was unable to locate a suitable location to resolve "MGApp". This may happen when too many instances of labview have been loaded into the same process."

Can someone help me to correct this error?

View All (7)

Hide skipped stuff

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

TortoiseSVN is an easy to use Source Code Control tool. However, it needs a MSSCC API plugin in order to be integrated with TestStand. On NI web page, PushOK is listed as a tested plugin with TortoiseSVN by NI tech team. PushOK is made by a Russian company. Another AgentSVN plugin is made by an Australia company. From an end user perspective, the time zone difference will cause some difficulty to access tech support in case it is needed. I used TamTamSVN 1.4.9 plugin for TortoiseSVN integration with TestStand and it worked fine. TamTamSVN plugin is made by an US company located near NYC area. I will suggest NI Tech team to test TamTamSVN plugin for TortoiseSVN integration with TestStand to ensure its features and functionality are acceptable to NI applications. If it pass the test, please add it into tested list.

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.

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.

Modify sequence during excution

I distribute my application which needs end user to register the teststand base deployment license. None of the end user of my application are interested in what NI software’s were used or in any NI hardware they are the end user who just want to use the application. So they end up using the Eval version for some days then complain that they cannot use the application any longer.

They are not interested in creating a NI profile & NI does not give any option to register the base deployment license without NI profile, so I have to go on their system and register the product using my profile.

View All (4)

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:

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

Develop a tool to migrate TS2017 Custom Python step type to TS2019 built-In python step type

Labview Error in Test Stand

Modificacion de variables en un vi.exe

Remove bold text for Label Description in Step Settings

optional Autosave for the sequence editor

Save As Previous Version for Deployment Utility

Hide skipped stuff

Analzye a Subsequence within the Main Sequence

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

Test TamTam plugin to support TortoiseSVN integration with TestStand

Programatically allow to select LV Adapter Development System version

TestStand Deployment Utility: Support VIs issue

HW query capability in Sequence File

Modify sequence during excution

Teststand Base Deployment license registration should not require a NI profile.

Developers should be able to edit the sequence file whilst executing.

Host .NET processes outside of TestStand's application space

Support for creating locals for Image type

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

Allow Custom LabWindows/CVI workspace or project from TestStand