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

[JÞB]

---

@Edjsch wrote:

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. 

Sorry that was missunderstood.  It was just a side note about how to improve the FTDI performance by using FTDI specific adjustments that are available

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.  EXACTLY the point I am questioning.  Is there something in LabVIEW/VISA/Silabser that isn't applying a property change properly?   

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

It was not related to what you are experiencing but to answer your question, The Dell Latitude I was using had a BIOS that reserved COM1-COM4 rather than the typical COM1-COM2.  This was not taken into account by the serial enumerator regisry keys in the SiLabs driver install.  That was a couple days I'll never get back.

Ed

---

[Edjsch]

Jeff,

I appreciate your inputs. Re. "FTDI performance": FTDI does not need improvement, SiLabs does. I guess this is why I completely misunderstood you. Sorry.

Re. "Device Manager": There's no way for me to know or do anything about it anyway. It could be a clue, though, to SiLabs (whom I hope is still reading this forum as I asked them to do).

Re. "Dell Lattitude": 1) Laptop PC's a few years ago were using a COM port for their infrared port, and I've also run into conflicts with VCPs, not just SiLabs. All you simply needed to do was to disable the IR port in Control Panel to eliminate the conflict and to be able to then use that port. I'm not sure how long that took me to discover that little tidbit! The IR port has been largely (but not totally) abandoned. 2) FYI, Windows totally overrides the BIOS settings, which are just for booting.

Thanks,

Ed

[Edjsch]

Alisha,

I have attached “No Serial Read (Max RPS test).vi”, which strips out all VISA functions from my previous speed test. It is a test to see how much the UI and the overall architecture of the vi, with its Match Pattern and RPS calculations, etc., is causing it to run slowly. In a 1 second test with 0 Millisecond Wait, I get 20,487 RPS on my PC. This proves that it is NOT the ui or the calculations that is slowing down the VISA read performance.

A longer test does show slowdown due to dynamic memory allocation of the string indicator (my theory). And if I have a 1 mS wait I only get a little over 500 RPS. Can you speculate why?

Please comment. Thank you.

Ed

[JÞB]

the time tick - and write to Initial timer occur in parallel to the while loop.  Totally non deterministic in this case without some means (Dataflow) to enforce order.  Your numbers may go all over the map and initial timer may even execute AFTER the while loop finishes without breaking any LabVIEW Laws (although the compiler optomization will prevent that)

Ditto the write of constant 0 to terminal readings  It may happen while the loop is in any itteration causing a race with the locals

[Alisha_P]

Hi Ed,

I don't think that the slow read performace you are seeing has anything to do with LabVIEW. I thought we agreed on that already. Even on the 'slow' computer, where I was seeing some slowdown, I was not getting nearly the 'build-up' that you saw.

In that case, I'm pretty sure it simply had to do with the fact that the computer only had one processer. It therefore took longer for the program to get to where it called the Read VI. It has absolutely nothing to do with the VISA Read itself. 

You could easily test your memory allocation theory by removing the string indicator. It doesn't surprise me that adding a wait would cause LabVIEW to stop calling the read function as fast as it can (therefore getting a slower reading).

The computer I was testing on is now in use by someone else. I therefore cannot get the portmon log for the new architecture on that computer. However, I will attach 3 portmon logs: one from my computer with your old code (win7test3.log), one from the test machine with your old code (winXPtest1.log) and one on my computer with the new architecture (win7test_newcode.log). You will notice that they're really not that different. You see a little bit of 'build-up' on winXPtest1.log, but not at all like what you are seeing. 

[Edjsch]

Jeff,

I see what you are saying, However, I know by the results that the compiler knows that those values are to be initialized before the While loop is entered, otherwise the calculations would be crazy and they are not. In other words, the compiler executes all the code on the block diagram (in non-deterministic order, as you say) before ANY loops are entered. Agreed? (Although I thought when I was learning LV it said something to the effect that the code is basically executed from left to right, but maybe that's not strictly true. Comments?)

Ok, to test, I put the initialization of the Initial Timer and the Readings in a Case with i = 0 wired to its selector INSIDE the While loop, OR if I keep the Case outside the While loop but wire a First Call vi to it, I get the same results (it varies a little each run) as before. (All 3 tests give the same results.)

Thanks for the advice.

Ed

[Edjsch]

Hi Alisha,

No, we agreed that the slow performance seems to be mostly caused by the SiLabs driver, but VISA seems to interface to the driver differently (more slowly) than HyperTerminal does (I'll do a Portmon and send in my next post). Silicon Labs, whom I have not heard from yet, said initially that since their driver works with HyperTerminal, it must be LV/VISA that is at fault. In rebuttal, I’ve pointed out to them that LV works great with other USB VCP’s, throwing the ball back into their court. (This is probably why I haven’t heard from them yet - hopefully they are exploring. I’ll tweak them again soon.)

The only reason I did this test without using VISA (without actually reading the serial port) was to see if the architecture of my original vi had anything to do with the slowness as you thought (which is why you developed the Producer-Consumer method). It does not. I see no difference. Do you agree? (I’m not sure why you saw a difference.)

If I remove the Shift Register before the string indicator soLVis not saving anything to memory, I get 1,000,060 RPS with 0 delay. [With 1 mS delay (or a Wait Until Next MS Multiple vi) I still get 513 RPS. Not sure why. I expect to get 1000.]

(Is there a microsecond delay or wait vi? If not, is there a way to do that?)

Re. your Portmon logs: The winXPtest1.log is for the IRP_MJ_WRITE, not the IRP_MJ_READ, so I don’t know about that. Can you repeat with the reading vi? The other 2 log files do show the same ~2 microsecond delays around the IRP_MJ_READ as I do with the FTDI and Prolific drivers, which tells me that your latest NI drivers are good. The SiLabs driver was a few MILLISECONDS. I have told them this (and given them the logs).

Thanks,

Ed

[JÞB]

actually, in previous versions before the optomizer the compiler defaulted to Back to Front  (and there still seems to be some bias to this order)

Since new objects are created in front of existing objects by default, and most developers code linearly (I don't- I drop by pallate and arrange as needed), this seems to act like R to L and T to B.  The compiler today is free to change any order at any compile and you WILL notice execution order changes more than in older LabVIEW versions unless you have a data dependancy.  Depending on the compiler to order your steps is begging for a surprise at some future date.

[Edjsch]

Jeff,

Got ya. But you do agree that my vi was correctly coded, don't you?

Ed

[Edjsch]

Hi Alisha,

Ok, I’ve attached Portmon HyperTerm.zip, which includes the capture log file from HyperTerminal timed manually for 10 seconds. Notice that the capture file shows 2573 lines (strings), indicating 257.3 RPS. Also notice that the Portmon log file shows that HyperTerminal is reading 80 bytes per read, so I guess that’s why it keeps up since the read times are in the order of 27 milliseconds.

My vi reads the “bytes at port”, and the line feed is detected to count the number of strings (line feeds) received. If I wire a constant of 20 to the VISA Read “byte count” input (the LF termination character is enabled by default), then I get even slower performance of about 50 RPS (instead of 70). Notice that Portmon_COM17 - byte count.log shows about 4 mS around the IRP_MJ_READ.

Ed