Using LVLIBP with DLLs in TestStand

[ngblume]

Hello fellow LabVIEWer,

I've run into a problem when developing drivers in LabVIEW by calling a DLL and then using this driver as a packed project library from TestStand. To give you a little background (and example components, but the issue seems to be generic):

- Hardware used: PCAN-USB-Pro-FD (https://www.peak-system.com/PCAN-USB-Pro-FD.366.0.html)

- DLL used: PCAN-Basic API (https://www.peak-system.com/fileadmin/media/files/pcan-basic.zip)

- I created the wrapper VIs with the LabVIEW wizard (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ls1SAE)

The settings for each Call Library Node (CLB) are as follows:

(I later tried also "Run in any thread" with similar issues...)

Issue(s):

When packaging this LVLIB into a LVLIBP and calling this LVLIBP from TestStand (separate computer, only LabVIEW RTE available), I get the error message "Unable to load VI ZZ with the Run-Time Engine version 17.0. It is possible that the version of one of its subVIs is not the same ..." (not showing the VI panel in TestStand, etc.). I traced this to the LVLIBP not finding the DLL and fixed this by putting the PCANBasic.dll in "C:\Program Files (x86)\National Instruments\TestStand 2012\Bin". The folder itself (containing the LVLIBP and the DLL) was already in the TestStand SearchDirectories. I then attached the device for the first time and needed to install the device driver. This put the PCANBasic.dll into system32 as well allowing me to automatically find this DLL there and remove the copy in "C:\Program Files (x86)\National Instruments\TestStand 2012\Bin".

Overall, I am a little confused as how and where TestStand looks for these DLLs and how to specify a specific DLL-file to be used in a packed library, running via the run-time engine in TestStand.

To check this further, I built a VI, that builds the path to a specific DLL-file as follows and changed the library nodes to "Specify path on diagram" and used the path helper VI:

This works fine in an application built from LabVIEW (EXE) and when using the LVLIBP in other LabVIEW projects.
But NOT when using the LVLIBP from TestStand...

Which leads to the question:

What is the recommended way to use DLLs in LabVIEW LVLIBPs (that are later executed from TestStand via the run-time engine) ?

Any help and tipps are greatly appreciated"

Thanks!

Cheers

Niels Göran

[~jiggawax~]

The problem here has to do with Application Spacing.  I noticed you are using the application directory function in LabVIEW.  This is tricky because TestStand runs a special engine underneath the hood that has a different application directory than an executable.  Here's a great article on how some of that works and how to share the application space (heads up, it's tricky): http://www.ni.com/product-documentation/14335/en/

Also, in the case that you are calling the DLL from LabVIEW then the LVRTE is in charge of linking and not TestStand.  TestStand only looks for direct code modules, not thier dependencies. 

In this case it might be better to either pass in the directory from TestStand to the DLL (you can use the FindFile function).  Or use an absolute path.  Or, I'm not sure if I remember correctly, but couldn't LabVIEW link it relatively when you build the PPL instead of relying on a path?

Hope this helps,

[ngblume]

Dear jigg,

thank you for your reply.

I figured that I was somehow related to TestStand handling the apllication instances differently than LabVIEW RTE or a LabVIEW application. I also read that article, but I'm not fully getting a feel for this behavior from it.

I probably will build a VI that just prints out the application directory and see where it leads me.

"Also, in the case that you are calling the DLL from LabVIEW then the LVRTE is in charge of linking and not TestStand.  TestStand only looks for direct code modules, not thier dependencies.":

What do you mean by "from LabVIEW" ? Calling a VI from a LVLIBP in TestStand or from LabVIEW dev?

I expected TestStand to call VIs via LV RTE, which puts finding the dependencies in the hands of LV RTE..
Which then confuses me, since I can place the DLL in "C:\Program Files (x86)\National Instruments\TestStand 2012\Bin", and the LV RTE finds it there, but not in the folder where the LVLIBP resides..

Your idea of a relative path was what I expected the standard CLB node to do when configured like this (maybe switching to any thread instead of UI thread). Are you refering to something else? Also the idea of the separate VI was to build the absolute path at run-time in the LVLIBP instead of TestStand, since the library will be used later in LabVIEW as well and I think that yould therefore be handled in the library internally.

I think that is also what's happening since the LVLIBPs put the DLL along side the LVLIBP file ("PPLs do not include dependencies that are DLLs" - http://www.ni.com/product-documentation/7061/en/ - LabVIEW code modules section) and tries to find it during execution.

I get the feeling that TestStand simply "puts" the LVLIBP somewhere else and runs it there (without the DLL in the containing directory) and therefore starts looking for the DLL ... Why it is not using the serach directories of TestStand for that is another mistery to me...

I'll try some more things and report back, but will probably send the NI support an email for them to sort that out in more detail..

Thanks!

Niels Göran

[~jiggawax~]

So the reason the Bin directory works is because your application is SeqEdit.exe (assuming you are running from the sequence editor).  If you were using a UI it would be different.  So when you use the get application directory it is returning the Bin directory or the UI directory if using a UI.

I'm not as familiar with how the CLB node works so I can't speak to how it will behave once your code is put into a PPL.  I do know that the dll has to be in the same directory as the PPL as you pointed out.

Once TestStand calls a VI in your PPL then it is up to the LVRTE to find it's dependencies.  The problem here is that you are/were expecting the application directory to be where your PPL is located.  As we've proven that is not the case when called from TestStand. 

In order to fix this you can't use the application directory to search for your dll.  You have to find a different method.

Hope this helps,

[ngblume]

Dear jigg,

thank you for your reply!

It seems to be the case, that the CLB actually searches for the DLL in the application directory (or what the RTE defines as the AppDirectory), which means that this changes between RTE and LVLIBP via TestStand and other use cases.

When runing AppDirectory in a PPL from TestStand I get the "C:\Program Files (x86)\National Instruments\TestStand 2012\Bin" path. And it appears to search there for the DLL, even if the VI was called from the PPL.

I'm getting the feeling, that having the DLL next to the PPL usually works, since most use cases include the PPL in another LabVIEW project and that means using the the RTE "from LabVIEW" when deploying the application as an EXE for example (in this case the AppDirectory works as expected).

Example: Running an LabVIEW-build EXE that uses a PPL from "C:\Test\MyApplication" returns "C:\Test\MyApplication" as the application directory, allowing the CLB to find the DLL easily and allowing the developer to use that path to build the path to the DLL...

Nevertheless, I filed a support request with NI and will see what they come up with as an elegant solution to ensure properly locating the DLL to call from a PPL. Will post updates here...

Thanks for the help!

Cheers

Niels Göran