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

[Edjsch]

Alisha,

Thank you for the update. Snow Mule's suggestion did not make a difference. I didn't think it would for after all, the power down only takes place after a period of inactivity, and probably doesn't even apply to this type of device (as it does for an HID device like a mouse, for example). Also, we are using the same driver version that he says works best for him.

I do have a support request into Silicon Labs with the new information and portmon logs I posted recently. They are looking into it as you are. I'll post when I get a reply.

I'm anxiously awaiting what the VISA expert comes up with. You probably can contact SiLabs and get their CP2102-EB. It is their evaluation board for the USB-Serial converter (they call it a "bridge"). I have given them the link to this post in hopes that they read it as I have asked them to.

Ed Schwartz

[Alisha_P]

Hi Ed,

I have located the source of reading slowness on my test computer. It was a coding issue; when I rearchitecture the code to have a producer/consumer loop design pattern (so none of the calculations are affecting the speed of the read) and remove all local variables, I consistently get 245-250 rps (for at least as long as 45s) in versions of LabVIEW as varied as 8.2 and 2011. I'll attach my altered version of your code; perhaps it will help with the rps in your application.

Other than that, I spoke with a VISA expert and since you're using a third-party serial device and using the third party driver to make calls to it with VISA, there's a limited amount we can do. As of now, we haven't been able to show that the problem is caused by a LabVIEW to VISA interface problem. 

I suspect that the problem might have to do with the CP2102 driver. Just doing a Google search, I've found several people reporting slow communication with this driver.

If you find evidence that continues to make you think that this is a problem with LabVIEW, let me know. It's just that all our testing has been to the contrary.

[Alisha_P]

Here's the producer/consumer loop program for measuring RPS.

[Edjsch]

Alisha,

I do not get the same results as you. I get the same results as I did before with the other test vi’s. How you are testing with your Basic Serial Write (2).vi? Are you using COM1 on both vi’s, that is, looping back the Tx to the Rx? I am using COM1, a real serial port, to write, and COM6, a VCP, to read with measureRPS.vi. This may account for differences in our results.

I have attached a screen shot of an arbitrary 7.4 second test with our instrument. (I get identical results with your Basic Serial Write (2).vi.) It does keep up, as before, on COM1, a real serial port, but has the same result on the VCP as before. I only get about 69 RPS. See the attached screen shot. The Portmon log shows the same as before (I saw no need to attach it). Notice how “bytes read” (really “bytes at port”) is 8954, indicating that the Producer loop still cannot read the port as fast as data is coming in to it.

I agree that it seems to be VISA’s interaction with the Silicon Labs driver. However, remember HyperTerminal DOES keep up using the Silicon Labs driver. So why doesn’t VISA? THIS IS THE CONFOUNDING PART. But VISA does keep up when using other VCP devices (with their respective drivers), as I have stated in my post on page 6. I have not heard from Silicon Labs yet. I’m sure there’s going to be some finger pointing. They will say since it works with HyperTermianl, they are off the hook, are you say you are since it works with other USB – Serial converters. This is not going to be easy to resolve unless you and they work together, I think. But I am hopeful they will see how their driver needs to be revised to be the same as the FTDI and Prolific drivers.

Too bad I returned my NI USB – Serial converter so I cannot re-test using it. Is that what you are using? Remember that it was even slower than the SiLabs device. Maybe it has been improved since then, as that was about 4 years ago.

I await your reply to my questions, and further comments. Thank you.

Ed

[Alisha_P]

Ed,

It sounds like my set-up is the same as yours: directly from COM1, a 'real' serial port to COM7, a VCP. 

Since the issue seems to be with the third-party drivers, there's not much we can do about it. Even if this has to do with the way LabVIEW makes its VISA calls, there's nothing that guarantees the performance you want with your set-up. However, I have seen several forums online where slowness in communication with this driver was reported unrelated to any National Instruments product.

If the configuration does not produce results up to par for your application, I recommend trying a new configuration (maybe different hardware). I've done all of my testing with the NI USB-232 and it seems to perform well. 

I'm sorry we can't be of more help at this time.

[JÞB]

(I've Been hanging around too)

Looks like there is still some unresolved issues and I've had a bear of a time setting up those SiLabs VCPs too.

One minor point- You could probably tweak out the latency timer and packet size on the FTDI and match the Prolific performance (over a short term- (FTDI has appeared to me to be less noise susceptable but maybe thats cable shielding and not the chipset.)

Tossing ideas that haven't been asked:

• do the VISA default settings match the Device manager default settings and the settings applied to the VISA session? I can imagine some "resolvable" property setting negotiation between the interfaces.
• Is there any change if you try a VISA Serial:Instr class session? (Oh I Hope NOT) but replace the Serial port configure with a property node of Serial:Instr class anyway and lets rule it out.

If Hyperterminal can do it with SiLabs, and Prolific/FTDI can do it in LabVIEW/VISA and Hyperterminal, we need to look pretty close to find any differences.

[Edjsch]

Alisha,

The NI USB-232 was the one I used 4 years ago. It was about $100 when we bought it; now it's $149. I'm sure the driver has been updated many times, but the description from the link you provided as well as the data sheet says "driver software for Windows Vista/XP/2000". You said you are using Windows 7, correct? So you need to tell them to update the web page and data sheet. That's a pretty glaring error.

I could not find any driver update history. Can you? There may be clues there. I'm thinking maybe I should buy a new one and test it. If that is still slow then I guess you would feel you need to look into the problem, yes?

Anyway, you did say that you also experienced slowness on some PC's. Can't the developers look into that?

Obviously these USB-Serial Converter drivers are still in their infancy, and there is no standardized and accepted way of doing it the right way.

I tweaked Silicon Labs again. Unfortunately the engineer who was handling my SR has been reassigned, and told me someone else would be taking over and would get back to me. So that person needs to get up to speed. They have the Portmon logs so should be able to figure out why their requests are in the milliseconds instead of in microseconds, as are the FTDI and Prolific drivers. I'll post when I hear something.

Ed

[Edjsch]

Jeff,

Thanks for your inputs. I don't think "tweaks' will solve anything. To me it seems like fundamental design issues with the Silicon Labs' driver. See my reply to Alisha. The SiLabs driver is 1000 times slower as shown in the Portmon logs.

The Device Manager "default" settings get completely overwritten by the driver and different drivers show different things in Device Manager. But anyway, the "Advanced Settings" look about the same.

What problems have you had setting up the SiLabs VCP? We don't have setup problems, only performance problems.

Ed

[Alisha_P]

Ed,

The USB-232 uses the NI-Serial driver; the most recent version of this driver supports Windows 7. I have alerted the web team to what I agree is probably a specification in need of an update.

If you look at the readme for NI-Serial 3.8 (which can be found at ni.com/drivers), it has some general descriptions of changes from version 1.8 through 3.8. It does say there were some improvements for USB-232 in version 3.4.

As I stated a few posts before, the slowness I saw on one of my test machine was caused by the calculations within the read loop and the use of unnecessary local variables. When I switched to a single core computer, I guess it couldn't make up for these factors as it could on my regular comoputer. With the code that I rearchitected and posted, I don't see the slowness at all.

If you experience communication problems below our specifications with our hardware, driver, and software, we would definitely want to know and seek to correct the issue.

[Edjsch]

Alisha,

Thanks. Re. "slowness": Did you run Portmon on both slow and fast computers? If not, can you please. I can't imagine that those several millisecond delays vs. microseconds seen on the FTDI and Prolific drivers, are machine dependent. To me it seems the way the driver is written. I agree that that's not really your problem, but it would help in getting SiLabs to re-do their drivers.

As I said, I didn't see any difference with your Producer-Consumer architect. Can you compare Portmon with the 2 architects?

Ed