Cycling TCP/VISA connections

[mjbeals]

I have a device I need to poll at a rate of 2Hz over either a TCP or VISA connections (one or the other...user selectible).  My current work flow involves opening the connection (TCP or VISA) then entering into a while loop which polls the device at 2 Hz.  This means that each loop iteration I have to check to see if the connection is still alive (and reopen if not) as well as detect when the connection mode (VISA or TCP) changes, and handle closing one connection and opening up the new one. 

All of these tasks are introducing quite a bit of complexity into the code, and it would be much easier to just open the connection at the beginning of the loop and close it at the end with a case structure determining which version runs (VISA or TCP).  However, this would mean I'm opening and closing the connection very rapidly, and I'm wondering if this is problematic.

[Craig_]

How often do you need to change the resource type while the program is running? It seems like this would mean that something in the system itself had changed; people usually don't want to keep polling at a certain rate when switching devices.

Otherwise the overall functionality is possible and may be simplified with state-machine architecture.

[mjbeals]

The resource type *should* not change often at all.  This is just two different methods for contacting the same device and issuing the same commands, and for any given installation, only one will be used at a time.  Ideally it should be set once and left to run in that state until the end of the run.  However, in the case of initializing and debugging the connection, it might be changed a number of times...especially since changing connection parameters (such as IP address or com port number) require the connection to be reinitialized as well.

I considered state machine architecture but was having a hard time visualizing how to properly implement it

[Craig_]

You could programmatically work through different connection options, just make sure to keep this part of your VI separate from the acquisition part. Basically, the first part of your program could work through the connection specifics of your device, and the second could simply read data from the device.

I have attached a downgraded template from LabVIEW 2012 saved to be compatible with LabVIEW 2011. It should offer some guidance about how state machines are used.