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

[Edjsch]

Peter,

I've attached Portmon.zip, which contains the log files for both COM1 (a real COM port), and for the USB-VCP. I've captured 5 seconds of reads, including the initial port opening when my test program starts. Most of the data for the USB-VCP are IOCTL_SERIAL_GET_COMMSTATUS (I guess that's the Bytes at Port vi), with the initial and final writes, plus a few reads of increasing lengths. Notice that the log file for COM1 shows all reads. 

I'll try to get the C# program, but something maybe just as good or better is the capture from HyperTerminal, which keeps up with the 250 RPS, included in the zip file.

Hope this tells you something. Have you found an instrument yet?

Ed

[Edjsch]

Peter,

I tried my customer-supplied C# test program, but it is slow with our (SiLabs') USB-VCP driver. He tells me it's fast with his Win-USB driver. I don't really know what his program does, so we can't really use it for comparison. Since HyperTerminal can keep up with the 250 RPS data rate (I've logged it to its own capture file for 10 seconds, timed manually, to confirm this), it says that our driver meets the spec. as Silicon Labs claims. Let me know what else I can do to help your research.

Ed

[Peter-E]

Thanks for doing that. I'll look at these log files and let you know when I get new information!

[Peter-E]

Hi Ed,

I have one more request from you so that we can get the best information to our R&D department eventually to work on this problem. Can you make a new LabVIEW VI that is as simple as possible to remove some variables and keep things constant between hyperterminal and LabVIEW? A simple serial read write example should be sufficient. This will take out most of the code in between each read and focus more on the reads. When you have made this, create a portmon log file for it.

In this way we can almost mimic in LabVIEW exactly what you are doing in Hyperterminal and see the differences then.

[Edjsch]

Peter,

Let me see if I understand your request. I should eliminate the Force table and the graph. Correct? You realize that you can effectively do that by unchecking the "Graph and Tabulate Readings" check box, don't you?

Then you could delete the wire from the output of the VISA Read to the Search/Split String vi (and connect an empty string constant to its unconnected input so the vi is not broken).

You could then delete the RPS code (or put it in a Case structure's True case and wire a False constant to its input).

Then the "read string" indicator would function like the terminal window of HyperTerminal. The only difference being that the START button sends "AOUT250\r" (or whatever speed selected in the drop-down list box) where you type it in HyperTerminal, and the STOP button sends "AOUT0\r".

If this is what you want, you already essentially have it. I said in my post that the CPU usage is the same with the "Graph and Tabulate Readings" check box being checked or unchecked, but I should have also said that the speed is the same regardless of it being checked or not.

Let me know if this is sufficient.

Ed

[Peter-E]

Yes, what you mentioned is exactly what I was looking for! I stripped down your VI to its bare essentials to communicate with your device.

I attached that VI here. Can you run this and get a log of it?

I am collaborating with a VISA expert on this issue and he is asking for this information before we attempt running it on our end since you have the 3rd party device readily available to you. 

[Edjsch]

Peter,

You forgot to save it for version 8.5. Please do so and re-post.

I told you that I saw no difference with the check box checked or not, so the code you eliminated should make no difference (unchecking the box eliminates most of the code from executing). Also remember that the VISA Read keeps up with the 250 RPS with a real serial port, which seems to prove that the eliminated code is not the cause of the slowness. Anyway, I'll send you the logs when you send me the vi. Thanks.

Ed

[Peter-E]

I apologize. Attached is the VI for 8.5.

Even with the checkboxes unchecked in the original code, it does add a few more processes when the code needs to go through to check each case structure. The only way we can truly isolate the issue is to strip down the code to VISA reads and writes.

I hope you are having a great day!

[Edjsch]

Peter,

I’ve attached Portmon_(Revised2).zip which contains Portmon_COM1(Revised2).log and Portmon_USB-VCP(Revised2).log for an approximate 5 second run for each. (I timed it as best as I could manually using Multitrack Stopwatch, mwatch.exe.)

Notice that the COM1 log file is 4,628,331 bytes while the USB-VCP file is 154,688 bytes, or about 30 times smaller, for whatever that’s worth. It indicates that there are fewer status reports. Also notice that if you search for IRP_MJ_READ, in the COM1 file, all the time stamps for SUCCESS for the IOCTL_SERIAL_GET_COMMSTATUS reads are about 0.00000083 seconds (8.3 micro-sec.), but for the USB-VCP file they average about 0.00500000 seconds, or about 5 milli-sec (you’ll see 4 to 6 mS.)

(BTW, I deleted the unused initial timer (which was hidden) in your test vi just so that isn’t taking up any CPU recourses. Notice that since you eliminated the Wait (ms) vi, when the program runs it uses about 50% of the CPU resources on my PC.)

(Also, with the COM port it's so fast that you don't (rarely) see the reading in the "read string" indicator. If you put a feedback node to a string concatenate vi in front of the indicator, then the read string indicator fills up fast like a terminal window. But I did not do this for the log files I gave you.)

Let me know your thoughts and what you find. Thanks!

Ed

[Alisha_P]

Hey Ed,

Thanks for those log files - we're looking at them. I'm working with Peter and some other engineers to reproduce and report this issue. I'll try and keep you posted with what's going on.