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

[Alisha_P]

Hey Ed,

I just wanted to apologize for the delay in getting back to you and let you know that we are still trying to reproduce the issue. So far, we haven't been able to see any difference between the VCP and plain serial-serial, but we have some additional things to try. If you have any tips on reproduction, if you can think of anything unique or important about your system, please let us know.

Happy holidays!

[Edjsch]

Alisha,

Thanks for the update. I have some questions:

1. Are you using LabVIEW V. 8.5 like I am? (I'd think that the developers and/or the documentation would have indicated any improvements in the speed of the VISA functions if there were any, no?).

2. What are you using as a source of 250 serial strings (about 12 bytes) per second?

3. When you say, "we haven't been able to see any difference between the VCP and plain serial [port]" do you mean that they both can keep up with 250 RPS or they both are slower? What serial port card are you using? (Dell Optiplexes have a built-in serial port.)

Let me know. And Happy Holidays to you, too.

Ed

[Alisha_P]

Hi Ed,

1) We are not using LV 8.5 so that's a possibility although we'd be most concerned if this issue could be reproduced with a newer version. Which version of the VISA drivers are you using?

2) We're simply using another computer as the the source and writing at a 115,200 baud rate.

3) The seem to be keeping up fine. In your logs, one can see that the data is building up but you don't see that on any of our logs. 

4) We are not using a serial port card; our serial ports go straight into the mother board as far as I can tell. What about you? Do you have a serial port card?

[Edjsch]

Hi Alisha,

1) On page 2 of this post I said I'm using NI-VISA 4.2, which is what came with my LabVIEW 8.5. Can you try it with that version? (I've been told by NI that several/many (all?) versions can (theoretically) be installed and run on a PC, but I'm not sure if that is true with VISA. Maybe the new version would have to be uninstalled? I'd suspect you have PC's dedicated to the (all?) old versions for downconverting and/or this kind of inquiry. No?

2) I'd like to replicate your test. Are you using HyperTerminal with a "null-modem" (back-to-back) adaptor or cable? (I have those.) Are you using a file transfer protocol like X, Y, or Zmodem? If so, can you post the file you are transferring? If not, how are you writing 12-byte strings at a 250 strings per second rate? Please describe your test for me.

4) Dell Optiplex PC's have a built-in (on the motherboard) single COM port. Is that what you have? (I don't know of any other PC's these days with serial ports.) I'm using a Dell Vostro PC with a generic PCI dual serial port card. I'm not sure if it's StarTech (startech.com) or another brand (we did buy it from Dell when we ordered the PC, and I know they carry StarTech and maybe other brands), but from Device Manager the driver is from "Sunix Co. LTD".

Please let me know so I can test as you have. If I don't hear from you today, have a Happy New Year and we'll speak next week (year).

Regards,

Ed

[Edjsch]

Hi Alisha,

FYI, in addition to the Portmon logs I've already posted, I have attached 4 screen shots of my “Read Speed Test” vi in a zip file, "Read Speed Tests.zip". “COMPort250 RPS - 30 Sec.png” is with a real serial port. After about 5000 readings the “Bytes at Port” starts to increase from its initial value of 0 or 12/13 (depending on sign of reading) to the indicated 4252 bytes, which brings down the average RPS rate. In this test I stopped the test after 30 seconds where the RPS decreased from its initial value of about 250 to 233 as shown due to the 4252 bytes (about 340 readings) remaining in the buffer. I am assuming that after the 5000 or so readings, LabVIEW is dynamically allocating memory, which takes time and slows down the vi.

The second screen shot, “USB Virtual COM Port 250 RPS - 1 Sec.png” is with the USB VCP. The test was stopped after 1 second. Notice that the “Bytes at Port” is already 2184. The bytes are in the buffer waiting to be read because the VISA Read function cannot keep up in real time. This slows the RPS down to 67 as indicated.

The third screen shot, “COM Port 250 RPS - 1 Sec.png”, is with a real serial port for comparison with the 1 second test using the USB VCP. Notice that there are 12 bytes at the ports being read, and it is keeping up with the ~250 RPS being received.

The fourth screen shot, “USB Virtual COM Port 250 RPS - 30 Sec.png”, is with the USB VCP. Notice that the average RPS rate is only 67, and the “Bytes at Port” is 9652, representing about 772 readings, bringing the total up to 2025 + 772 / 30 = 92 RPS. (Actually, after the stop time has been reached and the While loop reading the port terminates, more bytes are still coming in, but the “Bytes at Port” isn’t registering it.)

Hopes this helps clarify what I am seeing.

Ed

[Alisha_P]

Hi Ed,

1) I will try to test this with previous versions of LabVIEW and VISA. We don't really support problems only associated with versions before LabVIEW 2009, so it's a little trickier to get back versions, but I will see what I can set up.

2) I am not using Hyperterminal. I'm simply using the Simple VISA Read/Write VI available in Find Examples.I am not transferring a file but writing a string (of the indicated size) again and again at the indicated speed. I realize this is not an exact replication of what you're doing but it should indicate whether the VISA read can hold up to the speed and the amount of data you indicated. We haven't seen any of the same build-up of data.

4) I'm using a Dell Precision and the serial port is connected directly to the motherboard (my computer is open so I can see it). 

I'll let you know if I find anything out testing older versions of LabVIEW and VISA.

[Edjsch]

Alisha,

I'll try to replicate what you are doing. Can you post your vi, downconverted to V8.5? I have some questions:

1. How are you confirming the number of strings you are writing per second? Using a timer vi? A scope? Both? Peter E. stripped out my timing code from my test vi, Read_Gauge_Auto_Transmit (Revised2).vi. Did you put it back in?

2. What USB VCP device are you using to receive? And when you do that, I assume you are transmitting from your real serial port. Please confirm.

3. The fact that you see no "build up of data" could mean that both writing and reading are equally slow. Can you make sure that is not the case?

Regards,

Ed

[Edjsch]

Alisha,

I have attached Serial Write & Read Tests.zip containing the screen shots of tests I have conducted with a vi for writing (at about 250 strings per second -- it has a 4 ms loop wait time) and another vi for reading as fast as it can (0 loop wait). Serial Write & Read - COM1 to COM2.PNG, which has the Serial Write (Max RPS test).vi block diagram as the background, writes out of COM 1, a real serial port, to COM 2, also a real serial port. (I am using a DB9 to DB9 “Null Modem Adaptor” from Radio Shack.) The write time is 20 seconds (only needs to be more than 10 with enough time to start the read vi), but I am reading for only 10 seconds. Notice the RPS rate is 242.9. And notice that the Bytes at Ports is 0, indicating that the VISA Read function is keeping up.

Serial Write & Read - COM1 to COM6.PNG, which has the Serial Read (Max RPS test).vi block diagram as the background, writes out of COM 1, a real serial port, to COM 6, our Silicon Labs USB VCP. Notice the RPS rate is only 70.2, indicating that it is not keeping up with what is being sent by the write vi. Also notice that the Bytes at Ports is 9948, indicating that these bytes are in the buffer but the VISA Read function cannot return it to the read vi fast enough.

Please let me know if this is what you are doing. Thanks.

Ed

[Alisha_P]

Hi Ed,

This is very similar to what we're doing. We're using the Basic Serial Write and Read.vi that's available in the Example Finder. I've attached a picture of our block diagrams.

Our code is a little simpler than yours, but I don't see anything on your code that should affect the timing too much. We've been using Portmon to determine if there is "build up" at the ports. We have been using two different computers rather then different ports on the same computer, but I don't think that would make a difference either.

We are using this USB Serial Interface

http://sine.ni.com/nips/cds/view/p/lang/en/nid/12844

with an NI RS232 Serial Cable

It seems that you've shown that there isn't a problem with using the VISA write and read in the test. Even with writing and reading using VISA, you still see the read delay. I'm thinking this either has to do with your hardware or possibly your software versions. I just would be surprised if the VISA read has changed that much.

[Edjsch]

Alisha,

Thanks for the update.

You said, "It seems that you've shown that there isn't a problem with using the VISA write and read in the test. Even with writing and reading using VISA, you still see the read delay."

What you said is NOT correct. In these tests I'm using a vi (using VISA, of course) to write the data. In previous tests I was using my hardware device to send the data.

Furthermore, in the tests where I'm writing (using VISA) from COM 1 (a real serial port) at about 250 RPS (strings per second) to COM 6 (a USB VCP), I am only receiving 70.2 RPS. When I write to COM 2, a real serial port, I receive 242.9 RPS (which I'm guessing is the actual rate the the write vi, which uses the VISA Write function, is writing at. I didn't look at it on a scope, though.).

So I don't know what you mean when you say, "you still see the read delay." Please explain.

One more thing: I looked at your block diagrams. How are you timing the number of strings you read per second?

Regards,

Ed