LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with building exe. of Thorlab Kinesis motor included .NET container

Solved!
Go to solution

Hello everyone 

 

I am working on building exe. from a project that include Kinesis .NET container(KDC101 control).

It works fine on development environment just like others, but I can't run with the exe. which build from project.  system will display

 

geocactus_0-1602576934876.png

(in the exe.) 

 

I guess it the problem with the .NET container, because I create a new simple vi without the .NET container and it works fine on exe. (the vi with .NET container wasn't included in building application)

 

In order to investigate it easily, I use Kinesis motor example vi (Name: Kinesis - KDC101 - Move Absolute)with .NET container.

and only two dll. included in this vi.(two dll. show in figure below)

geocactus_1-1602577739915.png

 

 

geocactus_2-1602577977360.png

(The front panel of vi in development environment) 

圖片8.png

(The block diagram of vi in development environment) 

 

I think the problem of .NET framework is not involved in, because the interface in container will not pop up if the .NET framework problem had occurred in development environment.

 

So far I'm still haven't find out where the real problem is, but I guess the potential problem may be the dll. of the Kinesis when the Labview building exe.

 

 

 

Application of properties when building application exe. :

圖片1.png

圖片2.png

圖片3.png

圖片4.png

  

圖片5.png

 
 
 
 
 
 
 

圖片6.png

圖片7.png

Labview version: 19.0.1f3(32bit), professional development system.

Kinesis version: 1.14.23(Build 16838) (32bit)

My laptop: Win 10 (64bit)

0 Kudos
Message 1 of 8
(2,199 Views)
Solution
Accepted by topic author geocactus

Hi Geocactus,

 

Have you found a solution yet? 

 

You are missing a few steps. 

 

1. You must include all DLLs that are called by the main Thorlabs.MotionControl.Controls.dll. There is no way to know which DLLs are required so I suggest you copy all the DLLs from the Kinesis folder and delete one at a time. As and example, here's a list of files that a filterflipper requires:

Capture.PNG

 

2. You  need to copy all DLLs to the same folder as your executable. For some reason, Thorlabs created their DLL in a way that it can only

find the required private DLLS in the directory of the running executable.

 

This should do the job. Let me know if you have any questions.

 

Eric

0 Kudos
Message 2 of 8
(2,057 Views)

@Pitts-burger wrote:

 

2. You  need to copy all DLLs to the same folder as your executable. For some reason, Thorlabs created their DLL in a way that it can only

find the required private DLLS in the directory of the running executable.

 

This should do the job. Let me know if you have any questions.


That’s simply how .Net works by default as designed by Microsoft. The other default option is to install all those DLLs to the Global Assembly Cache but that is something the manufacturer should provide an installer for. You should never add .Net assemblies to the GAC yourself!

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 8
(2,050 Views)

Yeah, that is how LabVIEW finds the main DLL Thorlabs.MotionControl.Controls.dll. But what I meant to say is, that DLLs then calls other DLLs that need to be in a specific folder. For some reason, it is not enough that they are all in the same folder. They need to be in the same folder of the main executable.

0 Kudos
Message 4 of 8
(2,039 Views)

@Pitts-burger wrote:

Yeah, that is how LabVIEW finds the main DLL Thorlabs.MotionControl.Controls.dll. But what I meant to say is, that DLLs then calls other DLLs that need to be in a specific folder. For some reason, it is not enough that they are all in the same folder. They need to be in the same folder of the main executable.


And that is exactly what I wrote! 😀LabVIEW is very able to load an assembly DLL from wherever it was stored by the application builder since the VI is update with the new path to the DLL during application build. From there it is all out of the hands of LabVIEW and the Windows .Net loader handles the rest including loading all dependencies. And the .Net loader by default only checks the GAC and the executable directory for these dependencies.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 8
(2,030 Views)

I build the application with all the dll. file in "always include".

After the build process done, I moved the dll. files which in "data" subfolder to the folder which the Application.exe located:

圖片1.png

Then this is the result:

geocactus_0-1616660937573.png

The interface of the KDC controller finally appeared in exe.

Thank you very much

 

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

@geocactus wrote:

I build the application with all the dll. file in "always include".

After the build process done, I moved the dll. files which in "data" subfolder to the folder which the Application.exe located:


You don't have to do this manually. By adding another custom destination to the Build Specification that points to the same directory as where your executable is, you can then assign that destination to the files in question and the Application Builder will do the rest.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 8
(1,864 Views)

Thanks for your advice, I change the destination of  support directory as where the executable is, so the destination of all the dll. files at Source file setting will be all the same. This works the same as the manual one, but more convenient.

0 Kudos
Message 8 of 8
(1,853 Views)