Calling two dll's with same function names

[nottveit]

Hi,

I have two dlls I call from labview and separatly everything works OK.

But these dll'e have many of the same functions (in terms of naming, actual function is different)

When trying to use both dll's in the same labview project this gives me a problem as function call are allway

done to dll #1. Labview even recognize the error by giving me warning that function expected to be loaded from dll #2 were loaded from dll #1.

Any ideas?

All suggestion are welcome. (I hae tried to get the dll supplier to change naming in dll #2)

BR

Ørjan

[MikeS81]

Hi Ørjan,

how do you call the dll? I don't understand how you can get problems in calling your dlls. Do you use the "Call Library function node"? Can you show us an example of what you mean?

Try to help.
Mike

[Coq_Rouge]

This sounds like a bug to me, or at least some overprotecting programming from NI. From my point of view you should be allowed to do this. Anyway I have some ideas. You can try to load one of the VIs calling your dll's dynamicly. If you have accsess to a C tool. You may perhaps write a dll which purpose is to make a call to one of your dll's. If you have the application builder perhaps you can make this ddl in Labview.

good luck

[dan_u]

Do both dlls have the same name? Try renaming one of the dlls.

[nottveit]

Tnx for quick replies.

Yes I am using Call Library function. (Tried to paste in picture here, but didn't seem to work.)

And the DLL's have different names, but the functions within two DLL have the same name.

I know this can be fixed in text-based programming languages like C++ or visual basic, but it still gives me a headache in Labview... 

I suppose I can go to C and wrap one of the dll with new function names, but I really didn't want to go that path (YET...)

[chrisger]

Hi there

This is not a bug. Any windows application which uses late binding searches for DLLs first in the applications memory space, than in the folder the application is located and then through the systems search path. So if a DLL #1 with a given name is already in memory, this DLL will be loaded instead of DLL #2. You can overcome this by renaming DLL #2. Please triple-check that you have changed the DLL name of each call library node for DLL #2.

In LV 8.x you also can use early binding by specifing the library path on the call library function dialog box. Then you should be able to specify two different paths (but same names). But this is just a guess, never tried this.

Message Edited by chrisger on 01-29-2009 01:43 AM

Message Edited by chrisger on 01-29-2009 01:44 AM

[mpesavento]

Hello Chris

I am having a similar problem. I have two DLLs with different file names, but some identical function names between the two. Both DLLs are residing on a RT system. All of my Call Library Function nodes have always had the path for the DLL's location on the RT box passed directly into them. In my RT VIs that are calling the DLLs, I added a conditional to change the path and filename passed into each CLF node so it loads the other DLL.

When I run the code with the"normal" path and filename, things work fine. When I switch to the other DLL, it doesnt give me expected results. The code contains numerical methods, and the results aren't anything close to expected results for either the original DLL or the new one. The weird result could be because one of the initial function calls that sets up the integration isn't setting things up correctly before I even get to the integration step, so integration fails.

The new DLL has been tested in other applications and works fine, so I'm sure this has something to do with how LabviewRT parses the two DLLs when loaded in memory.

Any thoughts or ideas as to why I would be getting such strange results? I would rather not have to rename all my functions,sinceI would have to restructure all of mylabview code around that change.

Thanks!

-Mike

[chrisger]

Hi there

Have you tested the DLL on a RT-Target or on a PC? First of all i'd make absolutely sure that the DLL works as expected on a RT target (I've seen different results of DLLs between .VI and .exe !!).

Then log the path of the DLL passed to the CLN and the error output of the CLN to a file on the RT target to make absolutely sure what's called.

You may try to place TWO CLNs in a case structure, each one with hard coded DLL path. Then switch between the CLNs, not the DLL paths. This just if the "path variable" doesn't working on RT.