How to import a dll-file to LabView NXG 1.0

[BasilB]

Hello

I want to import a dll-file to my LabView NXG 1.0 projekt. The dll-file is create from a Microsoft Visual Studio project. The dll-file (AgilentSweep.dll) is attached to this post.

I have created a new shared library file and there I have selected my dll-file. Should it identify the function automatically or do I have to create the functions in the shared library editor by myself? If I have to define the functions in the shared library editor by myself, how can I change the function name?

Thanks a lot for your help.

Regards

Basil

[tobiasglunk]

Hi Basil!

it appears you are not the first person with that question. Check out this thread with gif containing instructions:

https://forums.ni.com/t5/LabVIEW/NXG-Call-DLL/td-p/3650275

regards

Tobi

[BasilB]

Hi Tobi

Thanks for your answer. I have seen this gif in the other post, but I'm a step before. The gif starts at the point, where the user open the .sli-file and all the functions, which are included in the dll-file, are listed out. But my question is, how do I get these functions with the return argument and the parameters in the .sli-file? I can select the dll-file in the top of the .sli-file but nothing happens afterwards. 

Regards

Basil

[tobiasglunk]

Hi Basil!

I tried it myself as well and ran in the same issue. I learned that we will be able to do that NXG 2.0

[BasilB]

Hi Tobias

Thanks for your answer. I really looking forward to NXG 2.0. :-

[diabeticdaniel · Accepted solution]

Basil,

The reason your DLL is not importing properly is because it is a 32-bit DLL. LabVIEW NXG cannot import 32-bit DLLs. This Microsoft KB explains this limitation under "No Mixed 64-bit/32-bit Processes".

LabVIEW NXG is 64-bit software, and so it cannot call 32-bit DLLs. If the DLL was 64-bit, you would be able to configure the function name from the right rail, as well as the input and return types.

[BasilB]

Hi Daniel

Thanks for your answer. My dll-file is several years old, so it is highly likely that it is a 32-bit version. I will try to create a new version of my dll-file.

Regards Basil

[Raykov]

In "This Microsoft KB" article, there is no information about any limitation for 64 bit applications to load 32 bit DLLs. If there is such problem in this particular case, it's not OS limitation.

[diabeticdaniel]

See this article for more direct phrasing.

"However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution."

[Raykov]

Ok. My mistake. But how can I see the beauty of the view from the top of the Eiffel tower when you point me to Berlin?

Something you can do is to load the 32bit DLL in it's own container process and use some form of interprocess communication to do the job. You need to create two additional things: a 32bit .exe to execute 32 bit DLL and a 64 bit DLL to interact with the 32 bit process running that .exe. Probably there is some more or less universal tool to do that (maybe rundll32.exe can be used). This way you will acheave completely transparent work for both sides - your application and 32bit DLL. Easiest way is to recompile the 32bit DLL to 64bit. ...If you have access to the source code ofcourse.