Executing a DLL created by LabView 2012 in Dymola

[roeperj]

Hi,

I am quite new to LabView and right now try to get my bearings. One thing I would like to figure out is how to call Dlls created with Labview in Dymola.

So I created a real simple VI with two inputs in double which are multiplied and then given out as a double. Calling this dll in Visual Studio 2008 works fine. But as soon as I try it in Dymola I get the attached error. The compiler used by Dymola Visual Studio 2008 as well. On google I found something about delayed calling of dlls regarding the errorcode 998. LV Runtime is definitly installed.

I also tried putting the lvrt.dll in the project folder with the same result. I thought it might help because of the wiered path with the \\.

I'd be really greatful if anybody has ideas regarding this problem.

[rolfk]

Well, I'm not sure what Dymola is, but this definitely looks like a Dymola problem.

The LabVIEW runtime is installed in a central location and registered in the registry and the sharedlib will query the registry to find where it is installed in order to load it from there.

Loading of a sharedlib can fail for several reasons in Windows. The first is obviously that the file is not present at the indicated location, but this seems not the problem as otherwise you would also get problems in the Visual C test program. The other reason that loading of a DLL can fail is when Windows tries to resolve the implicit dependencies of the sharedlib, by locating and loading any other sharedlib it may reference. If loading of any dependency fails, this will fail the loading of the main sharedlib as well.

Since this seems to work just fine from a Visual C generated test program there must be something that Dymola does that prevents Windows from loading the LabVIEW runtime. I don't think  that the problem is in querying the registry but most likely in what Microsoft calls activation contexts. A shared library can define an activation context in the form of a manifest file that defines how to locate dependencies (secondary shared librareis) such as the Visual C runtime library. And the LabVIEW runtime contains such a manifest for at least the Microsoft C runtime library and the Common Controls library. In absence of such a manifest the shared library inherits the activation context of the invoking process, which is probably your Dymola development environment. It could be that Dymola messes with this in order to do some behind the scenes magic to link with certain runtime libraries for some strange reasons, overwriting whatever activation context the LabVIEW runtime library may require, and then when Windows tries to load the LabVIEW runtime it fails because of unresolved external references, and that gives you the mentioned error.

It definitely looks like a problem that only can be resolved by someone with a deep understanding of what Dymola does to the Windows activation context or more generally process environment which could influence the loading of shared library dependencies.

[roeperj]

Thank you for the reply. After doing some additional tests I believe you are right about your statement that it should be a Dymola problem. I started a support request at d'Assault on this and will report if I get any information.

[phil_real]

Hi,

have you solved the problem or are you still waiting for an answer from d'Assault.

Greetings

[roeperj]

Hello Phil,

I did not get an answer yet. But it is time to remind them...

Are you planning to do something similar? If so, please describe your problem, maybe we can figure it out together.

Jan

[ShuenA]

I meet the same problem when call the DLL builded by Labview 2012 SP1 in Visual C++.

Is it Bug in labview 2012 SP1? Or how can i solve it?

[roeperj]

Hi everyone,

Dymola-Support found the error. Labview Dll's have to be delay loaded. Which is described in an article of NI:

http://digital.ni.com/public.nsf/allkb/70995EC2CA1B523386256DD4004F3DE6?OpenDocument

The way to call a library delayed in Dymola is:

Library={"SharedLib -delay SharedLib"}

To bad that this option can not be found in the Dymoladoc...