NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

unable to load vi in LV runtime engine - AGAIN

Solved!
Go to solution

This is probably the most frustrating interaction I have with TestStand & Labview. 

 

You build a VI with the development system, test it all works fine, then switch to the LV runtime engine and get the dreaded "Unable to load xxx.vi with the labview runtime engine".

 

So following the multitude of posts here, you 1/ Make sure your VIs are not read only 2/ Mass compile your VIs 3/ Use the TestStand "update VI calls" function and finally 4/ Give up in discust and attempt to diagnose the problem by systematically ripping your library apart to find the problem VI in your system.

 

Surely there must be a way for the stupid Labview Runtime engine to indicate to Teststand why it can't run the VIs in question? An error log somewhere perhaps? A debugger mode? Just randomly trying things each time I encounter this issue is driving me nuts (and is very stressful when you have a production system down).

 

A case in point - my current issue is;

 

TestStand 2014 SP1

Labview 2014 SP1

Labview Runtime engine 14.0.1

 

I've built a LV class, and I'm calling the VI with the Labview adapter in Teststand, using the Runtime engine. The call type is "class member call". Every public method in my class works ok with the Runtime engine, except one public method that has the dreaded "unable to load blah blah blah" message. This public method has nothing inside it but a popup dialogue box. Removing the popup dialogue box call from the method fixes the problem (well other than the class method does nothing now). The VI obviously works with the development system and I've gone through the obvious 1/2/3/4 steps above to resolve the problem. The LV Runtime, development system and Teststand are even on the same machine - its not like I'm even trying to deploy to another PC!

 

My gripe isn't that the LV Runtime has a problem.... its that there appears no way to intelligently debug the issue without randomly trying things.

 

Has anyone found a way to debug the LV Runtime engine under TestStand?

0 Kudos
Message 1 of 8
(6,019 Views)

Hi Bilby42,

 

Do you receive any other error message outside of "Unable to load xxx.vi with the LabVIEW Runtime Engine"?

0 Kudos
Message 2 of 8
(5,997 Views)

Hi Luke,

 

Yes, the full message is;

 

"Unable to load VI 'PopupDialogue.vi' with the labVIEW Run-Time Engine version '14.0'. The version of a subVI might not match the version of the run-time engine or a VI dependency might be missing. Try using the Update VI calls tool with the LabVIEW adapter set to the labVIEW development system to resolve this issue".

 

Regards,

Tom

0 Kudos
Message 3 of 8
(5,964 Views)

Hi Tom,

 

You’ve managed to narrow down what VI (PopupDialogue.vi) is causing the issue.  Are there any distinguishing features about this VI? Does it have dependencies? Was it originally written in a different version of LabVIEW? Is it located in special directory?

0 Kudos
Message 4 of 8
(5,940 Views)

Hi Luke,

 

I can't tell if there are any dependancies for the dialog, as its the standard "one button dialog" that comes with the labview environment. You can't even open the "one button dialog" VI, it seems to be a primary component of Labview. However it should be exactly the same version as the runtime engine, after all its supplied as a standard VI with development environment. It also runs normally when in developer mode.

 

I guess this is my point exactly; I've found the issue by randomly deleting portions of my class. I can find no other intelligent way to pinpoint this VI as the issue, and indeed now I've actually found the problematic VI cannot diagnose anything further. This can be very time consuming and frustrating at best. 

 

Tom

0 Kudos
Message 5 of 8
(5,937 Views)

Forgot to mention, the "One Button Dialog" doesn't show up in the Dependancies tab of the project manager. I thought it would show under the vi.lib folder, but it doesn't.

0 Kudos
Message 6 of 8
(5,927 Views)

I've also included the output from the "Update VI Calls..." function. Notice that it forced a prototype load on the "Show Dialogue" call, but this didn't fix my problem ("Show Dialogue" is the TestStand Labview call that is giving trouble).

 

Also note it forced a prototype load on the "destroy" call, even though there is nothing wrong with this call.

 

 

 

Snippet from "Update VI Calls..." function;


Cluster mapping errors:
<None Found>

__________________________
Step Name: Show dialogue
Project Path: C:\Users\tom.rolfe\Documents\ATE_Fixtures\PP012\Labview\RelayDriver\RelayDriver.lvproj
Class Url: My Computer\Class\RelayBlock\RelayBlock.lvclass
Class Path: C:\Users\tom.rolfe\Documents\ATE_Fixtures\PP012\Labview\RelayDriver\Class\RelayBlock\RelayBlock.lvclass
Member name: PopupDialog.vi
VI Version: 14.0
VI Status: Normal
Step Status:
* Forcing Prototype Reload...
* VI call was updated to use the new prototype.

Cluster mapping errors:
<None Found>

Step Name: destroy
Project Path: C:\Users\tom.rolfe\Documents\ATE_Fixtures\PP012\Labview\RelayDriver\RelayDriver.lvproj
Class Url: My Computer\Class\RelayBlock\RelayBlock.lvclass
Class Path: C:\Users\tom.rolfe\Documents\ATE_Fixtures\PP012\Labview\RelayDriver\Class\RelayBlock\RelayBlock.lvclass
Member name: ReleaseRelayBlock.vi
VI Version: 14.0
VI Status: Normal
Step Status:
* Forcing Prototype Reload...
* VI call was updated to use the new prototype.

Cluster mapping errors:
<None Found>


--- Completed updates ---
Elapsed Time: 00:00:03.8600000

0 Kudos
Message 7 of 8
(5,922 Views)
Solution
Accepted by topic author Bilby42

 

 

I always build a Packed Library .lvlibp  during Deployment.

Else I also had Problems with just using VIs 

 

Note:  I am  also using  multiple classes in my Project.

 

regards,

Akshay

Message 8 of 8
(5,911 Views)