TestStand Base Deployment Engine with LabVIEW Runtime Engine Error - 17600 LVLIB issue?

[jdub9260]

When I run TestStand development system with LabView development system  or LabView runtime adapter, my test runs fine.

However, when I run TestStand Base Deployment Engine with LabView runtime, I get the 17600 error - could not load module.

I've seen some of the solutions offered such as mass compile, place all VIs in the same directory etc., but I'd like to find a way to eliminate the error with my current project file structure which is defined within my department.

My particular problem seems to be due to LabView instrument drivers within an LVLIB structure.  I created two custom VIs that call several of the instrument driver VIs (default instr.lib location) and located the custom VI in my project folder.

I can get rid of the error by moving my custom VI into the instr.lib location, but not by moving the Instrument driver folder to my project folder.  My search directories include the LabView default instr.lib.

I do understand that there could be VI naming conflicts with many Instrument Drivers containing Initialize.vi, Reset.vi, etc. The question is why the error only with TS BDE and LV RT configuration.

How can I ensure that TestStand will be able to load the lvlib drivers that my custom VIs require?

Again, this only is an issue with the TestStand base deployment engine and LabView runtime adapter.

[CaseyGj]

By your message, I would assume you have looked at this article and it's suggestions were not helpful for you.

Error -17600 on Deployment Machine Using TestStand and LabVIEW Run-Time Engine

Your question is fairly specific, so if you do not find an answer on the forums and you have SSP, you might want to make a service request with National Instruments to try to investigate further.

[jdub9260]

Thanks for responding Casey,

I did indeed search through several of these similar replies and had tried all of the suggestions except using packed project libraries.

I now have a similar program that calls the same custom VI's and it does not have this problem.  

I'm now looking into file permissions.