how to open multiple instances of a dll?

[adhikari]

Hi,

i have dll which controls the instruments. I have to communicate with multiple nr. of devices(5-8) in Parallel using LAN interface.I have designed my process like below:

Framework (for inilialization, UI, and loading subpanel)-->AsynCallreentrant.vi ( call the nr of instances (clones) using Asyn node) --> Subvi (reentrant execution Vi Property and dll call).

If i call the same dll using for example subvi:1(clone), subvi:2(clone),..and so on, then only one device works properly and other returns the error. How to solve this problem??

How to make copies of same dll (non reentrant dll) for the reentrant calling? Is there any dynamic ways that clone 1 calls the dll and clone 2 calls making copy of it (dll-copy)?

[Sam_Sharp]

It depends on the DLL, if the DLL is thread-safe then you can run multiple instances of it by changing the call library function node to 'run in any thread'. Of course, it depends a lot on how the DLL is designed - if it returns a reference or handle for each device then you should be able to pass that along in multiple loops. 

I've done some work with the FTDI drivers and the documentation states that some functions (e.g. getting a list of devices) are non-thread-safe and device specific functions (e.g. open, read, close - with a 'handle' for each) are thread safe - so they can be called in parallel.

[adhikari]

It did not work just changing the thread 'UI' to 'run in any thread'. Dll that i am using is non reentrant and written in c++. May the solution would be to create as many dll copies that i need instances and call them separetley.

Clone1 -->dll1

Clone2-->dll2 and so on.

How can be loaded dynamically for each clone individual dll?

[Sam_Sharp]

Well you can use the File I/O functions to copy a file and give it a new name. You can specify the path to the library on the block diagram - it's one of the options in the call library function node.

I'd be surprised if it works though - at some level the DLL will be talking to a device driver and then a device and it may not be possible to share the resources (e.g. memory, driver, hardware device) used.

Is the device from a manufacturer? Maybe you should get in touch with their technical support and ask how to interface with multiple devices.

[adhikari]

It (Just creating dll copies) also didnot work. The dll is non reentrant and can be open only one instances at a time. But if i make an exe and copy it(including dll), then i have two process runing separately. In this way it works fine. but i want to show all the running devices in one main vi. for that, i think(but not sure), i need inter-process communication.

Is there any easiest ways to do inter-process communication? some example would be very helpful.

[Sam_Sharp]

I've tended to use TCP/IP (at least at the base-level) for inter-process communications - either raw TCP/IP, Network Streams or some of the messaging libraries also support communications between executables.

[adhikari]

I am planning to implement it. I will have one main exe and other separate sub-exes(for e.g) as i need instances. Every sub-exe runs separately and independly. These sub exes exchange data (communicate) only between main exe and itself (there is no need to exchange data between sub-exes).

In the main i will put a listbox and show the Status of running Programms. This main is only needed for calling these exe and showing the Status(progress).

Is there any examples for this? is it possible to do like this?

[nathand]

It's definitely possible, although I don't know of any specific examples to recommend.

If you decide to use TCP, you'll want the main application to act as a server (it will open a listener and accept incoming connections) and have the other applications act as clients. You can find examples of how to accept and track multiple connections on the same port.

You might also consider using VI Server. For relatively simple communication, I've often found that's the easiest way to get LabVIEW applications to talk to each other, because it allows one application to directly call a VI in another application easily.

[adhikari]

Thank you.

Is Labview DLL also a stand-alone application like labview exe?

[nathand]

No. If you were to load multiple copies of a LabVIEW DLL, each of which calls your 3rd party DLL, you'd still have the same problem.