From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
01-17-2013 05:13 AM
01-17-2013 05:16 AM
Not sure if my attachment showed up. Heres another go:
01-18-2013 06:25 AM
Hi Paul
I've been looking into your post and if I'm correct your issue is when using a LLB to call a DLL? As I understand your problem you have a program that runs fine as a LabVIEW project however when you export this as a LLB or EXE there are problems when calling a DLL that resides inside the LLB. Is this correct?
As far as I am aware this should work fine so long as the DLL is in the same directory as the LLB. But as you have stated this is the case. A way to work around this issue may be to use LabVIEW native drivers for the 3rd party piece of software. Can I ask what 3rd party device it is your working with? You can check the IDNet and see if a LabVIEW driver is already available.
http://www.ni.com/downloads/instrument-drivers/
There are also lots of resources there to help with using instrument drivers there. If there isn't a driver there then please let me know and I can look into solving this issue with you further.
Many thanks
Daniel Harryman
Applications Engineer
National Instruments
01-18-2013 06:35 AM
Thanks for the reply.
The device in question is the Aerotech Ensemble motion controller. There doesn't appear to be a native labview driver, although Aerotech do provide some reasonable example code using their dlls.
Your assesment is basically right, when in a labview project environment, all works fine. But if I export my top level vi (along with all dependencies) to an .llb it seems to fail to properly load the .dll in the constructor node (although I should point out, the error is not being generated by the constructor, but by the property node immediately following it!).
I'd be much happier with a VISA style solution sending commands to the controller, but that's not available.
Any further suggestions would be gratefully recieved!
Paul
01-18-2013 07:15 AM
.Net has special request in order to be able to locate assemblies. Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located. LabVIEW adds for this an extra location which is the same directory as the project file is located, but for a build application the project doesn't exist anymore. There is not much you can do to mitigate these issues, except installing the assembly into the GAC but that requires a so called strongly named assembly which means it needs to be fully versioned.
01-18-2013 07:15 AM
.Net has special request in order to be able to locate assemblies. Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located. LabVIEW adds for this an extra location which is the same directory as the project file is located, but for a build application the project doesn't exist anymore. There is not much you can do to mitigate these issues, except installing the assembly into the GAC but that requires a so called strongly named assembly which means it needs to be fully versioned.
01-18-2013 07:25 AM
Hi Rolf,
Thanks for the reply - can you "dumb it down" a little for me ;o) whats the "GAC"?
you say: "Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located
Assuming I'm running in a labview dev environment, does that mean I can drop the assembly into the labview directory?
If I'm running from a built exe, can I then drop the dll into that applications directory?
Thanks again for your help.
Paul
01-18-2013 07:43 AM
@psmorris wrote:
Hi Rolf,
Thanks for the reply - can you "dumb it down" a little for me ;o) whats the "GAC"?
you say: "Basically you need to place the assembly into the GAC or in the same directory as the calling processes executable is located
Assuming I'm running in a labview dev environment, does that mean I can drop the assembly into the labview directory?
If I'm running from a built exe, can I then drop the dll into that applications directory?
Thanks again for your help.
Paul
1) GAC: Global Assembly Cache, the global location in Windows systems where all installed assemblies should be stored.
2) Yes in the LabVIEW development system it would be the directory where labview.exe is located, but that is a bad idea to do. Since LabVIEW treats the directory where the project is located in similar ways, you should rather use that directory. For build applications however you should indeed place the assemblies in the same directory as the executable, if you can't have the assemblies installed in the GAC.
01-18-2013 08:00 AM
Sorry to be a pain - what's the method for installing into the GAC?
Thanks.
Paul
01-18-2013 08:06 AM
Just found %windir%\assembly\ to view and drag drop. It didn't argue when I dropped the dlls into there. so that must be a good thing!
Having done that, do I need to change my code to reflect where they are? Or will labview just automatically look for them there if it can't find them elsewhere?
Finally, assuming the above works on my development machine, is there a neat way to install the dlls into a users GAC without needing to drag and drop as I've been able to do here?
Thanks for all your help - I think I'm getting there!
Paul