Select between same devices (Amtron) at different IP address

[Gregory]

Hi all,

I'm trying to work with Amtron CM100 Current sources for the first time. The manufacturer supplies "CM100DLL.dll" and when I configure "Call Library Function Node" I get three function options: Connect, Disconnect, and Reg Access. (I am not very experienced with library function nodes).

When I connect, I just send in the IP Address of the unit, but it does not output a reference. I'm used to having a different session for each instrument, does anyone know how I might control two of these units in the same program? Do I have to Connect and Disconnect every time I want to send a command?

Here is what the function nodes look like:

Thank you for any ideas, and please let me know if I need to provide any more information. Thank you,

Gregory

[nathand]

Can you provide the header file and any relevant documentation for the DLL? Possibly the return value from the Connect function is a reference that you then pass to the other functions, but there's no way to know from the information you've provided.

[Sam_Sharp]

What should happen is either:

1) The DLL/function is thread safe and returns a reference which you then pass to subsequent calls, allowing you to address/communicate with multiple devices

2) The DLL/function isn't thread safe and the DLL itself actually holds the reference to the device in the DLLs memory space and can therefore only communicate with a single device

You have the DLL calls configured as thread-safe - but that might not be the correct way of calling the functions.

As nathand has said - the documentation/headers for the DLL will help to identify which is the case. If it's the former, then you probably don't have the function prototypes configured correctly to pass the reference around and if it's the second, I think you'll need to create an executable which you run/spawn one copy (in it's own memory/application instance) of for each device and have each one communicate to your main application.

[Gregory]

Hi guys,

I only have one file right now (.dll) and it looks like the header is a separate file (.h). I will try to contact the company and see if I can get any more documentation from them.

[Gregory]

I got the function node usage from a provided "Demo" VI, that is why I selected "any thread" instead of "UI thread". The library and demo VI are attached.

Edit: I was looking at a colleague's code which had the "any thread" selected. The nodes in the Demo VI actually have UI Thread selected and are dark orange. It looks like if the return value = 0, it signifies no error. So I don't think that can be used as a reference 😞

I've also found a manual which talks about the functions (is this a header file?). It doesn't mention anything about controlling multiple instruments. I think I will try to use Sam's idea of multiple executables.

[Sam_Sharp]

Given the information in the manual - the DLL looks like it isn't thread safe and the DLL itself has some state information about the device it is currently connected to. You probably need to change the Call Library Function node to be (I think?) 'run in UI thread' - if you leave it as it is, it might call the library function from a different thread and not have access to the state information (and therefore error...or maybe you get an access violation (???)).

My suggestion then would be to write a small executable which is tasked purely with communicating with the instrument and your main LabVIEW application. There's an INI setting to allow multiple instances of the executable to run at once and then each instance will have it's own memory space when calling the DLL. You can then launch this executable multiple times (for each device) from your main application (e.g. system exec) and communicate between them and your main application (e.g. TCP/IP, network streams, messaging library, NSVs etc.).

[Dennis_Knutson]

If they publish a manual that explains the Ethernet protocol itself, you can use tcp/ip or VISA to control the instruments directly instead of using their dll. Have you tried using a sniffer such as Wireshark to capture the packets? Have you asked the vendor for additional documentation?

And no, a PDF file is not anything like a .h file.

[Gregory]

Sam,

A consultant with a CLD came in and set up a test station using the function nodes that I posted a picture of, that's why I used those as a starting point. So it appears that they "work" like that, but I definitely want to do things the correct way. I think I can handle your idea creating an executable for communication. If I create a cloneable VI (like in the DQMH) could I launch multiple instances of that, or do you think that would create a conflict? (I will put together a quick test here soon).

Dennis,

Thank you for the idea of using VISA. I am definitely more comfortable using the VISA calls, but I've already created a set of VIs for communication using the DLL, so I think I will see if I can get the multiple executables idea up and running quickly. Please excuse my naivety on DLL's!

[Sam_Sharp]

The key part is that the DLL must be called in different application instance (i.e. a new instance of the LV Runtime Engine - therefore in it's own memory space). Hence the need to launch one instance of an executable (rather than a VI) for each device. Even packed project libraries (although namespaced differently), run in the same instance so unless I am mistaken, it needs to be an executable that you launch for each one.

They work as they are because you only have one device and you are only calling the DLL serially (i.e. one call at a time). If you had multiple instances of that VI running at the same time in the same application instance - you would connect to each device and the DLL would store the information from the last device connected. Every read would return the data from that device and the close function would only close that device, leaving the others open and the subsequent calls would then error (because it's already closed).

Oh - one possible solution, which may/may not work for you if you don't need simultaneous calls/access to the devices - is that if you open / read / close the DLL each time, you could then do that in a for loop for each instrument. Of course, this might not be that efficient or may take a lot longer - but that is one way around the problem.

[Gregory]

Hi Sam,

Yes I will definitely check to see how long it takes to open and close with every function call. If it is around 10ms it should be fine.

If I go with the executables, could I create a queue in that VI and pass it back to my main VI somehow?