Optimal way for multiple VIs to access one TCP/IP connection?

[balcs]

Wondering what the best way is for multiple VIs to access the same instrument over a TCP connection. Simplified example is that I have a monitoring VI that contacts the instrument to check various status parameters once per second, and then I have another VI that tells the instrument to do a succession of things and return some data.

An easy way to do this is to have each VI open, use, and close a TCP connection every time it communicates with the instrument, and use a semaphore so that only one VI can talk to the instrument at a time. However, if instrument communications take place multiple times a second, it seems like it is a waste of time to keep opening and closing the connection.

It seems like there ought to be a cleaner way to do this in which there is only one TCP connection object that stays open and can be accessed by multple VIs. Maybe this would use queuing -- but I am not sure if you can use a queue across multiple VIs.

On the other hand, maybe the open-and-close-every-time method is fast enough and it will be fine. 

Anyway, is there an accepted optimal way to deal with the multiple-VIs-using-one-connection scenario? This should be platform-independent because it will have to work on a Mac. 

[Jay14159265]

Maybe try something like this to start. It is about as simple as you can go for a TCP/IP connection. 

Call the 'setup connection' case with your info then use the read and write cases to communicate to the instrument. You may need to adjust the read data format to whatever your instrument is sending. 

You dont need to worry about semaphores, LabVIEW will handle that for you as long as you dont make this VI a reentrant clone.  

Use this as a starting point and see where you can go from there. 

Maybe next steps would be to make a 'digital instance' of your instrument in LabVIEW that has methods like, 'connect', 'read', and 'write'

[balcs]

OK, thanks. I can see how this works with one VI.

However, I am missing how this will handle two VIs trying to use the connection -- if two VIs are using this, how does this make sure that the result of one request goes back to the VI that made the request? It seems like you would have to link the 'write' and 'read' cases to make sure you always read the result of the correct write operation. 

Also, do you happen to know if Labview will keep the connection live by itself once initiated, or is it necessary to check periodically and/or catch connection failure errors and reconnect if necessary? Sorry, limited experience with TCP inside Labview here. 

[Jay14159265]

---

However, I am missing how this will handle two VIs trying to use the connection -- if two VIs are using this, how does this make sure that the result of one request goes back to the VI that made the request? It seems like you would have to link the 'write' and 'read' cases to make sure you always read the result of the correct write operation. 

Yes, using this kind of 'Action Engine' to access the TCP/IP connection would typically require you to chain the calls for write then read, like this: 

This pattern allows for basic TCP/IP communication with an instrument but it is not that extensible (in the sense that it can only handle very specific TCP/IP interactions). A more robust way to interact with any remote system over TCP/IP would be setting up a server / client / listener kind of architecture which is a bit more involved but allows for good extensibility to handle any remote connection and can provide concurrency (if you really need it for a single connection) . This simple example does not require queues or actors or class objects so it is a good place to start. 

---

Also, do you happen to know if Labview will keep the connection live by itself once initiated, or is it necessary to check periodically and/or catch connection failure errors and reconnect if necessary? Sorry, limited experience with TCP inside Labview here. 

---

In my experience there are three main things that will close a TCP connection in LabVIEW 

1) explicitly closing it in LabVIEW by calling 'close connection' 

2) Windows, windows is a jerk ( but once a connection is made, windows will typically not close it, its mainly in the connection phase that windows will kill the connection, if you cant connect, look at the firewall, wireshark is your friend )

3) the remote connection is terminated or lost 

So aside from those things the connection stays open : )