Bomb-proofing VISA serial interface

[MarkDavidGeorgePotter]

Hello;- I am running a Labview program that (among other things) communicates with a relay board by a USB-Serial interface. Normally this works just fine, but I have been asked to try and make the program more error tolerant (since the hardware it is connected to sometimes causes glitches than can look like momentary disconnects of the port).

Anyway I have been testing error recovery basically by pulling out the USB port and reconnecting it and have found the following:

-(1)  If I pull out the USB, the program quite rightly reports errors trying to write to the serial port. I can then use Visa close to end the "session". I plug the USB back in and it starts communicating again (no need to open a session so I assume Labview does that automatically as long as a Visa command is pointed at a valid reference).

-(2) However, if i pull the USB out and REPLACE  it BEFORE calling Visa Close, I am unable to start communication with the serial port again even if I subsequently close the session (on trying to open a session again or talk to the port I get a "VISA: (Hex 0xBFFF0011) Insufficient location information or the device or resource is not present in the system" error. (in all cases the OS correctly recognises the USB Serial port and assigns it the same COM number whenever it is plugged in).

Due to hardware reasons we do not want to have to restart the program OR pull out the USB plug to restore access, and because in use the hardware issues that can cause momentary disconnects can be short, and Labview only notices an issue when it tries to write to the port, I cannot be confident of detecting a disconnect and closing the session before the port reconnects, so does anyone know a way to recover from condition (2) within the labview program?

For reference I am running labview 11.0.1f2 (32 bit) on a windows 7 PC, talking to a KMtronic USB relay device.

thanks in advance for any help that can be provided,

Mark.

[Hooovahh]

When you see an error with the port (or an error in communication) close it immediatly.  Then notify the user somehow (maybe a popup or a indicator) that communicaiton was lost.  Then have the code in a timeout case try to reconnect every so often (say once a second).  If the Open/Read fails close it.  If the Open/Read works then leave it open, and optionally tell the user that the connection was re-established.

[mknix]

Hi,

This is an interesting question, I'am façing more or less the same behaviour, and struggling with it for a while with no success.

I would be really happy to see your code solution that can handle such visa temporary connexion lost.

regards

antoine

[MarkDavidGeorgePotter]

Dear Hooovahh,

the problem with this is the program is generally busy doing other things and only occasionally tries to write to the Serial port. Unless theres some way to automatically detect if a port has been lost (other than continuously writing to it) I can't close the port in time (I suppose I could try constantly writing to it and see what effect this has on program speed...) so it "jams" when the port reappears. When this happens no number of close or open commands seem to fix it.

Thanks for your suggestion, though. I am still tinkering so if I find any more information I will post it up here.

Mark.

[Matthew_Kelton]

If you are only rarely writing to the port, can you open and close the port every time you send a command?

[MarkDavidGeorgePotter]

Good point. I will try that and see if it helps.

Mark.

[JÞB]

You are indeed correct.  VISA open is optional in current VISA implementations.  There is a service that stores VISA session information such that when you call a VISA operation with a VISA Resource the name (as string) is used to find the session if any is open.  An open session to a disconnected device is bad.  The open session must be closed before a new session can access the resources needed to establish a new session.

Yup, pretty confusing with Plug-n-Play VISA resources but, that's how it works.  It is more of a P-n-P limitation than a VISA feature.  That U in USB is probably miss-scoped since "Universal" covers a pretty broad range.

[AKA_TG]

Me too

I can handle a lost connection if its a pure serial port by having the port close immediately upon an I/O error and then

reconnect at leisure before checking the connection and then continuing with execution flow if possible.

I normally split I/O related timeout into smaller chunks and process them in a rather quick loop. This allows at least to catch a disconnect quickly.

 I rarely use the built in timeout unless the device is supremely reliable.

(Few are)

however a USB pull and immediate reseat is an interesting variation.

That is tied into the OP system handling of USB as well as VISA.

[MarkDavidGeorgePotter]

OK, I implemented Matthew Keltons suggestion and it works - I can pull out the USB and stick it in again and it keeps on going! Thanks!!

Mark.

[mknix]

So did I, thanks Matthew, simple and efficient