LabVIEW hang on VISA instr property

[bbean]

I have an issue where reading the VISA Instr Property "Intf Type" of a USB Instrument hangs for about 40 secs:

followed by an asynchronous VISA Write hang for 2+ minutes!  The timeout on the VISA instr session is set to 1000ms.   Here are the other details of the session:

and here's a snip of the VI:

 

Any idea why these long timeouts are occurring?    or why the 1000ms timeout is being violated for both the Instr property call (no idea what goes on under the hood here) or the VISA write. 

 

[hooovahh]

I don't have anything to add other than I've seen this but not in any recent projects I've worked on.  It always frustrated me when I'd drill into some VI that was taking forever and it would be some property node or Read/Write/Open that was supposed to have a small timeout.

[Rolf Kalbermatter]

1 hour ago, bbean said:

I have an issue where reading the VISA Instr Property "Intf Type" of a USB Instrument hangs for about 40 secs:

followed by an asynchronous VISA Write hang for 2+ minutes!  The timeout on the VISA instr session is set to 1000ms.   Here are the other details of the session:

and here's a snip of the VI:

Any idea why these long timeouts are occurring?    or why the 1000ms timeout is being violated for both the Instr property call (no idea what goes on under the hood here) or the VISA write. 

An USB device implementing the TMC class! That looks very much like the underlaying USB session itself somehow got borked. Once VISA calls into the Windows USB driver it can only hope that this driver will return within a reasonable time. If the driver detects some problem with the hardware resource it just can hang there and VISA only can wait until the Windows driver decides it wants to return. Unfortunately the fact that it is a Thorlabs device (from the VID and PID in the USB session name it must be a PM320E Optical Power and Energy Meter) doesn't increase my confidence in the actual hardware interface. Their physical hardware is amazing in what it can and does, their electronics and firmware is a lot less impressive.

Personally I guess some previous command you send hasn't been fully processed by the device, or you haven't read the entire response, or haven't reset a status flag in the device or something like that. These things all shouldn't be able to lock up the USB interface, but they can and sometimes do.

 

Edited November 27, 2019 by Rolf Kalbermatter

[bbean]

9 hours ago, hooovahh said:

I don't have anything to add other than I've seen this but not in any recent projects I've worked on.  It always frustrated me when I'd drill into some VI that was taking forever and it would be some property node or Read/Write/Open that was supposed to have a small timeout.

Thanks for the quick response.  its a rather annoying problem.

7 hours ago, Rolf Kalbermatter said:

Once VISA calls into the Windows USB driver it can only hope that this driver will return within a reasonable time. I

7 hours ago, Rolf Kalbermatter said:

Personally I guess some previous command you send hasn't been fully processed by the device, or you haven't read the entire response, or haven't reset a status flag in the device or something like that. These things all shouldn't be able to lock up the USB interface, but they can and sometimes do.

I think this may have been the problem but wont know until I test again on Monday.  You are correct that its a PM320E.  And so far their driver has been a pain.  The suspect command is the error query the parent class implements by default "SYST:ERR?" but PM320E requires ":SYST:ERR?".  A nuance (nuisance) that I failed to notice.

PS.  I think I may have borked the instrument up by upgrading the firmware too.  Oh well thats what you get for trying to get something done before a holiday weekend.