Select between same devices (Amtron) at different IP address

[Sam_Sharp]

---

@Gregory wrote:

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

---

No - for the same reason we are creating different executables in the first place - because we need them to operate in their own memory space! Hence why I suggested some sort of TCP/IP based method...however I recently found out about another method (after wanting to find a neat way of transferring data from LV web services to my application) by opening a reference to another application instance using VI Server.

I've attached a sample project (in LV2013) - it uses an internal message-queue library which you can probably find from the WebSockets link in my signature if you need it - but it demonstrates the principle (basically opening a VI server reference to an executable and running a VI in memory in that executable to pass it some data).

[Gregory]

I made a quick VI to see how long it takes to Open a connection, set a current, read the current, and close the connection, and it was about 300ms. What's worse is that it locks me out from a new connection for about a second after closing the previous connection. I'll have to explore Sam's idea of TCP communication.

[Gregory]

Well, it turns out that one (non-scaleable) way to get this working is to make a renamed copy of the .dll.

[Sam_Sharp · Accepted solution]

Oh yeah, I hadn't thought about that. You could use LV File functions to copy/rename the DLL and then wire the library path to the CLFN node (specify path on diagram option). That actually isn't too bad.

[Gregory]

I implemented the dynamically called DLLs as mentioned above. And at first I thought it was working well, but it was a little finnicky. The most annoying issue was that I could have one device talking to the computer, and the act of connecting another device made the first device drop off. I think I have finally found the root of the issue.

I do not think I can use the "Call Library Function" node dynamically (with the path input). Because every time I call it, it releases the previous path, which I believe is the reason that connecting to a new instrument can make the already connected instrument have issues. I am now changing my VIs so that the ones that call the library functions are in a case structure. The case structure has 10 cases (because we want 10 instruments) and each one has a "Call Library Function" that is statically linked to a different DLL.

It seems like a very ugly solution, but already I have had much more success connecting to these instruments.

[jacekow]

Hello Gregoryj,

Would you be so kind as to send me a pdf of the Manual of CM100 controller?

I bought  recently such a unit from a surplus company and I would to use it in my research (photodynamic therapy),

regards

Jacek

(jo@compartmedical.com)

[Gregory]

I do not have it any more, but you should be able to create an account and download it from their website:

http://www.amtron.net/index.php?id=35&L=2