Jump to content

VISA write (read) to USB instruments in parallel crashes LabVIEW


Recommended Posts

Hi,

 

I have several USB instruments (Agilent/Keysight optical power meters) which I can talk to via USB.

To minimise the time "wasted" by transferring data between the instruments and the PC I would like to query them in parallel. Unfortunately, LabVIEW doesn't agree with that strategy and reliably crashes when doing so. It doesn't matter which command I send, so here's a sample snippet, where I just query the instrument ID repeatedly. I don't even have to read the answer back (doing so won't make a difference):

post-28303-0-73933500-1412744114.png

This will kill LabVIEW 2012 and 2014, both 64bit without even popping up the "We apologize for the inconvenience" crash reporter dialog.

 

Has anyone had similar experiences?

I've seen LabVIEW crash while communicating over RS232 (VISA) but it's much harder to reproduce.

 

Is it outrageous to assume that communication to separate instruments via different VISA references should work in parallel?

All my instrument drivers are separate objects. I can ensure that communication to a single type of instrument is done in series by making the vi that does the communication non-reentrant. But I have to communicate with multiple instruments of different types, most of which use some flavour of VISA (RS232, USB, GPIB).

 

Am I just lucky that I haven't had more crashes when I'm talking to a lot of instruments?

Could it be a bug specific to the USB part of VISA? I've only recently changed from GPIB to USB on those power meters to get faster data transfer rates. In the past everything went via GPIB, which isn't a parallel communication protocol anyway afaik.

 

Tom

Link to post
Share on other sites

Hi,

 

I have several USB instruments (Agilent/Keysight optical power meters) which I can talk to via USB.

To minimise the time "wasted" by transferring data between the instruments and the PC I would like to query them in parallel. Unfortunately, LabVIEW doesn't agree with that strategy and reliably crashes when doing so. It doesn't matter which command I send, so here's a sample snippet, where I just query the instrument ID repeatedly. I don't even have to read the answer back (doing so won't make a difference):

attachicon.gifsnip.png

This will kill LabVIEW 2012 and 2014, both 64bit without even popping up the "We apologize for the inconvenience" crash reporter dialog.

 

Has anyone had similar experiences?

I've seen LabVIEW crash while communicating over RS232 (VISA) but it's much harder to reproduce.

 

Is it outrageous to assume that communication to separate instruments via different VISA references should work in parallel?

All my instrument drivers are separate objects. I can ensure that communication to a single type of instrument is done in series by making the vi that does the communication non-reentrant. But I have to communicate with multiple instruments of different types, most of which use some flavour of VISA (RS232, USB, GPIB).

 

Am I just lucky that I haven't had more crashes when I'm talking to a lot of instruments?

Could it be a bug specific to the USB part of VISA? I've only recently changed from GPIB to USB on those power meters to get faster data transfer rates. In the past everything went via GPIB, which isn't a parallel communication protocol anyway afaik.

 

Tom

 

Depends what instruments that were. The key here is that they are USB, and lacking any specific USB Raw setup in your diagram, must be Virtual Comm devices, which means VISA does in fact very little itself other than talking to the Windows COMM API which then calls into either the standard Windows Virtual COMM USB driver or a specific Agilent/Keysight virtual device driver. Which one it is I have no idea.

 

While VISA may be part of the problem I have seen all kinds of weird and unpleasant things happening with Virtual COMM USB drivers from various manufacturers. I have seen very little problem with parallel or any other type of VISA communication with other devices than COMM USB devices and since VISA really just treats them as any other serial port the problem very likely has to be searched in the USB COMM device driver, either the Windows standard driver or most likely a vendor specific device driver for the instrument you are using.

 

Basically your instrument is pretty much the same as any of those RS-232 to USB converter dongles, and there it makes a big difference if one uses a noname product with unknown internal controller or one based on for instance the FTDI solution. While none of the standard drivers that come with the SDK for such chips is really meant to be distributed by OEMs to their clients, most (especially no-name manufacturers) do so anyhow as you really can't hire a programmer to improve a driver when you earn basically nothing on the sale of a product already and from the ones I've seen only the FTDI driver works reasonably well enough to not crash under any but very ideal situations.

 

Another indication for this is the fact that LabVIEW simply disappears. No crash that can be produced in user space only is really able to terminate a process in such a way under modern Windows systems. This only can happen if a kernel driver is violating some critical system integrity while being called by the process directly or indirectly. And the only kernel component aside from normal Windows kernel handling in this setup would be the USB Virtual COMM port driver or some other part of the USB driver stack.

 

This really only leaves two options for the cause of this crash: A buggy chipset driver for your system itself or a buggy USB virtual comm driver for your instruments. Both of them are completely out of control of VISA and even more so for LabVIEW.

 

And while USB can potentially allow faster communication speeds than GPIB it is even less parallel than GPIB. In USB each bit has to go through the same line, while with GPIB there are 8 parallel datalines. Also both USB and GPIB do allow to communicate to several devices quasi-parallel. And since the USB port is really just used as a virtual COMM port in these cases the bit speed (baudrate) is typically limited to values way beyond what you could reach with GPIB.

Link to post
Share on other sites

Has anyone had similar experiences?

 

Yes.  We had a similar experience using VISA but with USB Raw calls in parallel to an FTDI chip on a NI RMC running LabVIEW 2012 RT (no virtual comm port).  We ended up having to remove the parallel loop and could not determine the root cause.

Link to post
Share on other sites

Results!

I investigated option 3 (communication via tcp/ip). It's about twice as fast when using six instruments - but only after setting the super secret TCP_NODELAY option on the tcp socket with a call to wsock32.dll

 

After talking to Keysight about the problems I experienced when talking USB, they said they saw something similar but only when using ViBufRead calls, which is the default in VISA. You can also see those calls when running the NI I/O Trace software.

 

From the VISA write help: 

When you transfer data from or to a hardware driver synchronously, the calling thread is locked for the duration of the data transfer. Depending on the speed of the transfer, this can hinder other processes that require the calling thread. However, if an application requires that the data transfer as quickly as possible, performing the operation synchronously dedicates the calling thread exclusively to this operation.

note.gifNote  In most applications, synchronous calls are slightly faster when you are communicating with four or fewer instruments. Asynchronous operations result in a significantly faster application when you are communicating with five or more instruments. The LabVIEW default is asynchronous I/O.

 

So, ignoring the warning about the potential performance hit, I switched to synchronous I/O mode and all is well.

No more crashes! Hooray

Link to post
Share on other sites

Results!

I investigated option 3 (communication via tcp/ip). It's about twice as fast when using six instruments - but only after setting the super secret TCP_NODELAY option on the tcp socket with a call to wsock32.dll

 

After talking to Keysight about the problems I experienced when talking USB, they said they saw something similar but only when using ViBufRead calls, which is the default in VISA. You can also see those calls when running the NI I/O Trace software.

 

From the VISA write help: 

 

So, ignoring the warning about the potential performance hit, I switched to synchronous I/O mode and all is well.

No more crashes! Hooray

 

Geez, I completely forgot about asynchronous VISA. It has been years that I had to tinker with that because of flaky devices drivers.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By ThomasGutzler
      Hi,
      I'm connecting to a Rigol DZ1000 Oscilloscope via USB and using the :DISP:DATA? ON,0,PNG command to grab a screenshot. Reading out the data in blocks of 65535 bytes until there is no more (see attached vi).
      This normally works fine but yesterday I was getting a timeout error. I fired up IO Trace and got this:
      > 783. viRead (USB0::0x1AB1::0x04CE::DS1ZA201305475::INSTR (0x00000001), "#9000045852‰PNG.......", 65536 (0x10000), 45864 (0xB328)) > Process ID: 0x000039C8 Thread ID: 0x00001760 > Start Time: 13:13:54.1169 Call Duration 00:00:10.4323 > Status: 0xBFFF0015 (VI_ERROR_TMO) You can see that 45864 bytes were received, which is exactly what was specified by the binary data header (45852 data bytes + 11 header bytes + 1 termination char)
      I dumped the reply string into a binary file and set the scope to run so it show something else on the screen. Sure enough the error went away. I also dumped a good result into a file. Then I tried to figure out what the problem may have been but I didn't get anywhere. Any ideas? Sure looks like a bug in VISA read or perhaps an incorrectly escaped reply from the scope?
      It's very easy to "convert" the reply into the screenshot - just remove the leading 15 bytes (4 bytes from WriteBinayFile and 11 bytes from the scope header). And yes, both data files display just fine as PNG. I don't think PNG does internal checksum so byte errors would be hard to spot.
      Any ideas what could have caused that timeout?

    • By LogMAN
      Here is another bug I discovered in LV2019+ which reliably crashes LV. Simply connect a set to the map input of the Map Get / Replace Value node on the IPE:

      This VI is executable in LV2019 SP1 f3, which means that you can actually build that into an executable without noticing.
      I have reported this, but there is no CAR yet.
    • By RMowatt
      I am experiencing numerous VISA Lock Errors (-1073807345) on resources I haven't explicitly locked.  This is happening on TCPIP connections to keysight N6700 power supplies and keysight N5242 PNA fairly regularly.
      I have simultaneous loops in the application communicating to the different instruments, using a sequencer of sorts to pipe commands one at a time to each of my various loops.
      Has anyone seen the locking error pop before while not actually using the Lock and Unlock VIs?  This issue has gotten worse lately and it has come time to find the root cause.  My only thoughts are that it may have something to do with having NI MAX and Keysight Connection Expert both installed and possibly trying to "ping" these devices.  Every once in a while me sending commands and these "pings" may clash and cause the locking error.
      Error reads as follows:
      "Specified type of lock cannot be obtained, or specified operation cannot be performed, because the resource is locked. VISA error code -1073807345 (0xBFFF000F)"
      We are using LabVIEW 2013
      Thanks in advance!
    • By Benoit
      Hey guys,
      Can you take a look at this?
      The only work around I found is to dynamically open the connection with an external VI to make it fail so the second time it works.
      If anyone has an instrument that communicate trough TCP-IP with VI, please try on your side with LabVIEW 2018 and visa 18.
      https://forums.ni.com/t5/LabVIEW/VISA-error-with-TCP-IP-BK-precision-2190E/m-p/3876316
      Thanks
    • By szewczak
      I wanted to cross post metux's discovery here asap, and have a separate discussion.
      Metux's original post:
      The recent Linux driver package introduces a CRITICAL security vulnerability:
       
      http://www.ni.com/download/ni-linux-device-drivers-2018/7664/en/
       
      It adds additional yum/zypper repos, but explicitly disabling package signing and using unencrypted HTTP transport. That way, it's pretty trivial to completely takeover the affected systems, by injecting malicious packages.
       
       
      DO NOT INSTALL THIS BROKEN SOFTWARE - IT IS DANGEROUS !
       
      CERT and BSI are already notified.
       
       
       
       
       
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.