LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Read function slower for USB VCP than "real" serial port

Solved!
Go to solution

@Edjsch wrote:

Jeff,

 

I'm simply using the VISA Read and VISA Write functions in asynchronous mode. My simple test vi loop is only using a VISA Read, of course, except for the initial write command in the first iteration to get our device to output readings.



What version of LabVIEW?  read the linked thread pg 2.....Smiley WinkSmiley Surprised we might be on to a LabVIEW-VISA bug


"Should be" isn't "Is" -Jay
0 Kudos
Message 11 of 109
(1,533 Views)

Jeff,

 

In my original post I said I'm using LabVIEW version 8.5. I just tried synchronous mode for my VISA Read and it did improve the throughput somewhat, from getting 70 RPS with the VCP USB port to about 110. (Remember I get the full 250 with a real COM port.)

 

This is to be expected, as described in the 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.”

 

This is not the bug described in the CAR, which applies to LabVIEW 2010, not earlier versions like mine.

 

Furthermore, I don’t think this behavior can be called a “bug” per se. I was trying to find out of others have observed this behavior, and Wayne confirmed this. (Any others?) I’d call this more precisely a “relatively important (for us) wish-list performance improvement request/suggestion” than a bug. Since the demise of the serial port has been greatly exaggerated, USB to Serial Converters will be around for the foreseeable future. Since a C# program is significantly faster than LabVIEW, I’d think that NI would take this as a challenge! C# proves that it is possible, even with the added USB to VCP layer.

 

Comments NI?

 

Ed

0 Kudos
Message 12 of 109
(1,518 Views)

Hi Edjsch!

 

You found an interesting issue here! Do we know if these same performance issues occur in more recent versions of LabVIEW (2011 specifically)?

 

Unfortunately we cannot request development improvements for older versions of LabVIEW. If we do find this happening in LV 2011 as well, we might be able to contact our developers about performance upgrades for new LabVIEW releases.

Peter E
Applications Engineer
National Instruments
0 Kudos
Message 13 of 109
(1,509 Views)

Peter,

 

I don't know about the current version's performance. I suppose I could get my NI field engineer to come into my company with LV 2011 on his laptop and we can test it. Let me know if you want me to contact him (Robert Berger).

 

Do you know if the coding of the VISA vi's have changed? I'd suspect not, but that's just a guess. Why would they "fix" it if they are not aware of this problem? I don't think I saw anything about this in the version info.

 

Another possibility is for me to post my test vi (which you could re-create easily starting with the "Basic Serial Write and Read" example). All you would need is some hardware that can output serial data continuously at about this rate (or faster!). You can use NI's USB/Serial converter (which as I said worked even slower than ours which is based on Silicon Labs' chip and driver). But that way you'd have full access to the source code.

 

(I also have vi's that use a command-response protocol, requesting individual readings in a loop. With this, things slow down even more due to the asynchronous nature between the device and the computer, even with a real COM port, but not as much as with the USB VCP. But I didn't want to complicate this post with this information.)

 

Let me know.

 

Ed

0 Kudos
Message 14 of 109
(1,502 Views)

Ed,

 

If you post your test VI, I would be more than happy to take a look at it and attempt recreate the issue on my computer with LabVIEW 2011.

Our developers will accept CARs (Corrective Action Requests) after the issues are reproduced on our computers.

Peter E
Applications Engineer
National Instruments
0 Kudos
Message 15 of 109
(1,497 Views)

Peter,

 

Ok, I've attached what I call "Read_Gauge_Auto_Transmit.vi", which was developed in version 8.5. It's adequately commented and self-explanatory, but let me know if you have any questions. Note that the "gauge" referred to is our force or torque gauge, which uses a command "AOUT250\r", for example, to command the gauge to begin outputting at 250 RPS. When the STOP button is pressed, "AOUT0\r" is sent to turn off transmission. This will have to be changed with your test instrument.

 

What instrument will you use to output the serial data?

 

(Note that I added the "Graph and Tabulate Readings" check box to see if that was consuming CPU resources, but it doesn't appreciably. Notice that with a real serial port the "Bytes at Port" is low until about 8K readings, after which it increases as it falls behind, and the CPU usage goes up (as seen in Task Manager). I think this is due to dynamic memory allocation. However, with a USB VCP port, the "Bytes at Port" increases immediately, as does the CPU usage.)

 

BTW, I get the same results running on a Dell Dimension 9200 with Windows XP Pro, 1.86 GHz Core Duo with 4 GB RAM, as with a Win7 home premium Dell Inspiron laptop, 2.1 GHz Core Duo, 3 GB RAM.

 

Thanks,

Ed

Message 16 of 109
(1,491 Views)

Great, thanks for letting me know!

As of now I am still scouring around looking for an instrument to run this VI, but I'll let you know once I find one.

 

What version of VISA are you using? What Operating System? In the C++ program you mentioned, is it directly communicating with the device? That is, it is not going through any VISA layers in text based code.

 

While I'm finding an instrument, would you mind running an I/O trace of your VISA calls, this can be done with NI Spy (if you have older versions of our drivers) or NI I/O Trace (which is newer). You can perform this by following the steps on the following Knowledgebase article. Attach the trace that you get on here.

 

http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9 

Peter E
Applications Engineer
National Instruments
0 Kudos
Message 17 of 109
(1,475 Views)

Peter,

 

I’m using NI-VISA 4.2 for Windows as indicated in C:\VXIPNP\WinNT\NIvisa\Readme.html (opened from the Start Menu shortcut when LabVIEW 8.5 was installed. It is also shown in MAX. (BTW, NI-Serial is version 3.3.) As I said in my post I’m using Windows XP SP3.

 

The C# program I mentioned was developed by my customer. He saw the same slowness our LabVIEW data collection software when used with our USB VCP (VirtualCOMPort) driver. He was familiar with WinUSB and has developed drivers using it, so he was able to modify it for the Silicon Labs chip used in our gauge. He says it’s direct USB and does not enumerate as a VCP. His driver is NOT used with my LabVIEW program, only with his C# program. So you are correct in that it does not use VISA.

 

I captured the port data using NI Spy. The first trace attached, Capture_USB-VCP.spy, shows about 15 mS between reads, which corresponds to my seeing about 70 RPS throughput.

 

The second trace, Capture_COM1.spy, is with a “real serial” port. Notice that there are about 4 to 8 reads in the 15 mS periods (it varies quite a bit), but averages out to about the 250 RPS that is being sent.

 

Let me know if you need any more info, and let me know your results.

 

Ed

Download All
0 Kudos
Message 18 of 109
(1,470 Views)

I'm also attaching Capture_USB-VCP_Synchronous.spy in which the VISA Read was set to synchronous mode. Notice it is a little faster, getting about 103 RPS in this run.

0 Kudos
Message 19 of 109
(1,469 Views)

Hi Ed,

 

You are correct. The I/O trace is giving us the same information as your program was. 

I brought this to a VISA expert here and he has requested some more information before we recreate this on our end. There is a program called Portmon: http://download.cnet.com/Portmon/3000-2651_4-50147.html

 

This program is like NI Spy except that it monitors all port activity. It can capture the usage of the ports with VISA commands as well as in the C# program that you mentioned. This will allow us to compare what layers VISA is going through as opposed to the standard windows dll port calls to get to the VCP. Do you still have the C# program available to watch the performance of it?

 

How to use Portmon once it is running:

1. Computer>>Connect Local

2. Capture>>Ports and then select the target port you wish to monitor.

 

Now run the two programs (the C# and the VISA calls) and save the information you get.

Peter E
Applications Engineer
National Instruments
0 Kudos
Message 20 of 109
(1,464 Views)