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

[Alisha_P]

Hey Ed,

Maybe I'm a little confused about this last test you did. I know that previously you were using the hardware to send the data, but in these tests it looked like you were using a VISA Write to send the data and VISA Read to receive it. With this set up, you still only received at 70.2 RPS, thereby showing that the problem was not dependent on whether or not you used VISA write to send the data. That's what I understood, but maybe you can point out where I am wrong.

It's true that I am not timing my read/second. I'm trusting that my while loop is writing the appropriate speed (or at least close to it). Since the bytes at port remains consistent and small, I can assume it's reading around the same speed as my write.

[Edjsch]

Hi Alisha,

Yes, I wrote these 2 new vi's, one to write the data and one to read the data, to replicate your test. Your misunderstanding is that with 2 real COM ports, one for writing and one for reading, it keeps up with the rate written (a little under 250 RPS). However with the reading vi using the USB VCP, it only attains 70 RPS, replicating what I am experiencing when my hardware serial device writes at 250 RPS.

So you are correct that it does not matter if I use a real COM port or my device to WRITE the data. What does matter is what port I use to READ the data, a real serial port or a USB VCP. This is the problem I am reporting in this post: Reading NOT writing (although that may be somewhat slower too, but I do not care at this time).

You said, "It's true that I am not timing my read/second. I'm trusting that my while loop is writing the appropriate speed (or at least close to it). Since the bytes at port remains consistent and small, I can assume it's reading around the same speed as my write."

This is a very bad assumption. I am seeing that the write vi with the 4 mSec wait does indeed output about 250 RPS (string writes per sec.). However, you need to put in a feedback node in front of the "read string" indicator, as I did. Then you can either count line feeds, as I did, or you can copy and paste the data in the indicator after the test completes into a text editor that has line numbering. The last line number will tell you how many strings were received. (You can time the test with a stopwatch, or use a timer vi as I did for more precise timing.)

Please let me know the results of your test and that you understand. Thank you.

Regards,

Ed

[Alisha_P]

Hey Ed,

I definitely understand that the problem you are seeing is associated with using a VCP port for the read.

However, I basically copied your code for the Read VI from the picture, sent the same string you're sending, and set up my serial-to-USB from COM1 to COM3 (vcp) on my computer. The RPS stays quite close to 250 as long as I've run it. At the very beginning of the test (like in the first second) it has an RPS of ~238 that quickly ramps up to 249 but that's as much variation as I've seen. Here are the screen shots from my test.

[Alisha_P]

Let me know if you still feel like there are other possibilities, but it seems like the problem you are seeing is either due to your hardware or to the fact that you're using older software versions. I still haven't run these tests with older software versions; I'll try and see if that's the problem.

[Edjsch]

Alisha,

Ok, so now you are testing on 1 PC, as I am, but you are not seeing the problem. First let me tell you that it is not just me, it's our customers, too (as well as other posters in this forum, as I have mentioned) who have seen this problem. (Have you asked any "serial" experts at NI?)

1. I've posted my PC specs in this post (6th post on page 2). What are yours? (Although a 2 GHz dual-core processor should be able to handle 250 Hz reads!)

2. You now need to test it on version 8.5. It would be great if you can find it already installed on, say, a 5 year old PC as I have. Let me know if you can.

3. Your screen shot does not show the "bytes read" indicator. Is it always around 0?

Based on your reply, we'll have to take it from there. Thanks again.

Ed

[Alisha_P]

1. Dell Precision with Windows 7, 2.8 Dual Core with 4 GB RAM

2. I tested in LV 8.2 and while I didn't see the same thing that you see, I did see something different for once. When I run it, it initially reads around 245 rps but this seems to continually decrease. I haven't tested exactly how far it decreases to but at 40 s it reaches about 185 rps. So perhaps an upgrade could solve this issue? I'm going to try some other versions and see how the behavior varies.

3. My bytes read indicator generally reads zero and flashes 12 every once in awhile.

[Edjsch]

Alisha,

I actually have V. 8.2.1 (the version I started with) installed on my PC and could try that. However, the VISA is the one that came with V. 8.5. Would that make a difference?

Is your LabVIEW 64 bit? Mine is 32. (Although V. 8.2 was only 32 bit.)

Your PC is 2.8 GHz. Correct? That should hardly make the difference. I don't know what's going on now.

Anyway, the fact that your "bytes read" is 0 or 12 indicates that there is no data build up in the read buffer. That seems to

confirm that your VISA Read is keeping up. What could be my (and other's) problem, then?

Ed

[Alisha_P]

Ed,

So I've done some more tests and found that the version of LabVIEW is not the most important factor and probably not the processor speed either. The tests I was doing with LV 8.2 were on a Windows XP operating system on a 3.2 GHz PC (but an older one). On that computer none of the versions of LabVIEW (including 2011) run this test at 250 rps (all significantly lower, though different).

So far, all the versions on my computer (2009 through 2011) run this test between 240 and 250 rps.

All my tests have been done with VISA 5.1, so if that's a factor, it's not the only factor though at this point I feel like we can't rule anything out.

All computers I've worked on have been 32 bit.

I was kind of wondering if maybe it has to do with the operationg system, but I believe that you said you reproduced that problem on both Windows XP and Windows 7 so I guess that can't be it either. 

I'm going to do some more tests to see if I can find any patterns.

[Edjsch]

Alisha,

I just tested on my 2-year old Windows 7 laptop (2.1 GHz Core Duo, 3 GB RAM) and it behaves exactly the same as on my desktop PC. That is, when receiving 250 RPS from our instrument it only displays 72.6 in my test program (LabVIEW V. 8.5, VISA V. 4.2 - the program I sent to Peter E.). When I tested with HyperTerminal (captured it to a file for 10 seconds) it did keep up and I got a little over 2500 readings (lines in the capture file). This proves that our Silicon Labs USB-Serial device (chip and driver software) does keep up, as I have said.

1. Are you using VISA 5.1 even with LabVIEW 8.2?

2. On the older PC you said all versions of LabVIEW run "significantly slower" than 250 RPS. What rate do you get?

Ed 

[Edjsch]

Alisha,

I just tested on a newer, Dell Optiplex Windows 7 PC. It has a 3.2 GHz 2-core Intel processor. On the USB VCP it also only attained only 68 RPS over a 10 second test run with our device. (I tested on an exe build of my test vi.) However, on the real serial port, COM 1 that the Optiplex comes with, it attained 252 RPS.

BTW, I have my VISA Read set for asynchronous operation. What about you? When I tested with it set to synchronous it was slightly faster, about 110 RPS if I recall.

I am perplexed as to why we are getting different results. If you like I can get our NI Field Applications Engineer, Robert Berger, to stop in with his laptop, and we can test. Let me know.

Ed