LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling several instances of a DLL

Solved!
Go to solution

Hello,

 

We develop a LabVIEW application which call a DLL. This DLL calls a lower lever DLL for communication with a device (but that's transparent for LabVIEW), and it works fine:

Current situation.png

 

We would need to support several devices at the same time:

Requirement.png

 

Unfortunately, this dll can only manage 1 hardware device.
How can we call several instances of a dll? I think each instance of the dll has to run in a different thread.
I've been told a solution to copy several times the MediumLevel dll file and rename each one? It might not work as it would probably call the same LowLevel dll.
Is there a better solution?

0 Kudos
Message 1 of 13
(310 Views)
Solution
Accepted by topic author Romain.P

Two possibilities

 

1) Renaming the DLLs as many times as you need a device and then create seperate VIs for each of them.

2) Remoting the DLLs in a separate process each and talk with them over IPC such as TCP/IP or VI Server.

 

Option 1) may catastrophically fail if the underlying DLL follows a similar stupid one session API design or has some other concurrent call trouble such as not being multithreading safe.

 

An additional action you might consider:

 

3) Whacking the developer on his head for only providing a trivial one session API instead of a truly session based API with an Open that returns a session handle and the Read, Write, Close and whatever taking that session handle to work on a specific device.

Rolf Kalbermatter
Averna BV
Message 2 of 13
(263 Views)

Thank you for you feedback.

 

1) I can rename the MediumLevel dll and call it, but if I also rename LowLevel dll, I think it won't be find anymore by the MediumLevel dll...

2) Do I have to create an executable per thread I want?

0 Kudos
Message 3 of 13
(237 Views)

The options are:

 

(1 and 3) OR (2 and 3)

 

3 is mandatory 😉.

 


@Romain.P wrote:

1) I can rename the MediumLevel dll and call it, but if I also rename LowLevel dll, I think it won't be find anymore by the MediumLevel dll...


See for instance: c++ - Load the same dll multiple times - Stack Overflow (esp. notice "I echo the comments above that encourage you to re-design the system architecture.".

 

Renaming the MediumLevel.dll wouldn't help. You'd still get one instance of the LowLevel.dll.

Message 4 of 13
(230 Views)

@Romain.P wrote:

Thank you for you feedback.

 

1) I can rename the MediumLevel dll and call it, but if I also rename LowLevel dll, I think it won't be find anymore by the MediumLevel dll...

2) Do I have to create an executable per thread I want?


Wiebe already told you more or less the options. If the LowLevel DLL was programmed smart and uses a session based API, and the high level DLL is just a wrapper for noobs who can't be bothered with sessions, it would work. If the LowLevel DLL is the main reason for this session-less API, then the only option is to create a new process for each device and yes that means one LabVIEW executable per process and some Interprocess Communication (IPC) with them from your main app.

 

I would contact the developer first, maybe his low level DLL is all that you would need to access and he might be willing to provide the documentation for its API. Maybe not, but as we keep saying, you can get a yes only if you ask, a no you have automatically if you don't ask.

Rolf Kalbermatter
Averna BV
Message 5 of 13
(221 Views)

Personally, I'd be really tempted to pull MediumLevel DLL into your LabVIEW Code - then you can manage the calls to LowLevel dll much easier in the long run as you have full control over the interface and MediumLevel DLL breaking can't break your LabVIEW APP.
putting the MediumLevel DLL into your own personal comms module is a PITA, but it's something I've done on more than one occasion when the LowLevel dll was not hackable/ editable / changable. (Then you can call  LowLevel dll by path) and spawn as many instances at runtime as you need from 1 module that you maintain.)

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 6 of 13
(210 Views)

I'm going to jump into this.

 

You are asking the wrong question!  Your question should be reworded as:

 

"How can I communicate with multiple devices of the same type?"

 

You should include information about how the device communicates.  You may include the statement that "Some Other Idiot" (SOI) has failed to provide a suitable API and you need to program a new driver in spite of SOI's poor effort. 

 

And you must take the required action 3.


"Should be" isn't "Is" -Jay
Message 7 of 13
(204 Views)

Whilst I too wholeheartedly endorse action 3, I have never been able to do it as SOI has always been my superior or client, hence my proposed solution of reducing the ability of SOI to screw things with 2 dlls instead of 1!
It maybe that the OP is in the same situation as I have found myself in the past.

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 8 of 13
(197 Views)

@James_W wrote:

Whilst I too wholeheartedly endorse action 3, I have never been able to do it as SOI has always been my superior or client, hence my proposed solution of reducing the ability of SOI to screw things with 2 dlls instead of 1!
It maybe that the OP is in the same situation as I have found myself in the past.

James


I've always found that the only difference between "Spaghetti Code" and code that is "Richly Featured" is one was written by my boss.


"Should be" isn't "Is" -Jay
Message 9 of 13
(185 Views)

@JÞB wrote:

You should include information about how the device communicates.  You may include the statement that "Some Other Idiot" (SOI) has failed to provide a suitable API and you need to program a new driver in spite of SOI's poor effort. 


I agree. If a programmer fails to see that an interface to 1 device would benefit from an interface to n devices, I'd seriously doubt the quality of everything else from that source.

 

If I could reasonably make a pure LV driver in a few days, I'd do that and be over with the dll. 

Message 10 of 13
(157 Views)