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

[JÞB]

---

@Edjsch wrote:

Jeff,

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

Ed

---

Without knowing the number of cores or core loading from external programs- no I can't see any reason that that original vi would operate repeatably.  LabVIEW just launches a bunch of threads totally unrelated to each other and the OS kicks in a schedules them whenever

[Alisha_P]

Hi Ed,

Yes, as we've discussed the interface between LabVIEW and the third-party driver is a possibility. Our company does not guarantee that this driver will work with LabVIEW. If you are using one of our products, we can be of better help to you. At this point, more specifics concerning LabVIEW performance with the third-party driver are not going to be looked at.

No, a microsecond wait time is not available. LabVIEW uses the O/S clock to clock wait time and a microsecond mode would not be very accurate on a Windows system. If you have further questions for NI about LabVIEW performance specs, please contact our support team more directly.

The portmon log, winXPtest1.log, was for both COM1 and COM7 which means it records reads and writes. Also, as I've said, the test computer has been relegated to other tasks and I no longer have access to it.

One other thing i found that you could try is setting your VISA functions to sychronous rather than asynchronous (right-click, Synchronous I/O mode). This might speed up your VISA functionality as long as you are communicating with fewer than 5 devices. I'm not saying it will bring your performance up to speed; I'm just saying it would be worth a try.

[Edjsch]

Hi Alisha,

I fully understand that NI is not and cannot be responsible for third-party drivers. When I started this thread I wasn't aware of Portmon, which Peter told me about. I also wasn't aware that some newer third-party devices worked well, at least in this one-way test. (I need to try a command-response method to see how that compares to a real, full-duplex COM port. I'll let you know.) I also had experience 4 years ago with the NI USB-232 converter that performed quite a bit worse than real COM ports, and worse than the SiLab's device. At that time I was not aware that the driver can make a huge difference. So with all this new information learned from this post, I realize that it is the Silicon Labs driver that is to blame. Now I just need to convince them of that! Ha! I'll ask them again Monday and post their reply. I hope they will say their latest driver fixes the problem, but that's probably very overly optimistic..

Thanks for your reply on a microsecond timer. I was going to search NI.com, but did not get around to it. I though I saw someplace that the latest version of LV had something faster than 1 mS., thinking that maybe new PC's had faster time-bases available. (I know they exist, for example, for high-speed USB or Firewire, etc, but they are used at the kernel (driver) level.) I'll bet that clever LV developers have used loops that they have timed and calibrated, but that would be machine-specific, and subject to OS time-slicing. Windows was not designed for fast, time-deterministic applications.

I took another look at your winXPtest1.log and this time searched (instead of looking visually) for IRP_MJ_READ. I do see them now, and the times are in the 2 uS range. I don't see why you saw any slowness on that machine. As I said, I don't think it's at all related to the original test vi's architecture (not using the producer-consumer method).

Re. Synchronous mode: On 1/6 (the bottom of p. 5 of this post), I mentioned to you that I tested with it set to synchronous and it was slightly faster, about 110 RPS (vs.. 70). I did not take the Portmon logs for that, though. I probably should look at that to see what the events look like.

Thanks again for all your help and patience. I'll keep you advised of what I learn from Silicon Labs.

Ed

[Edjsch]

Hi Alisha,

I ran Portmon on my vi with the read set to synchronous. It increased from around 63 to 94 RPS. Notice the attached log file shows only 2 IRP_MJ_READs, and each one was 4096 bytes. Also there was a 5 mS delay for the GET_COMMSTATUS before and after the read.

Can you run the vi in synchronous mode on your PC and send the log (and see if it runs faster, although yours was keeping up with the 250 RPS being sent)?

Thanks,

Ed

[Edjsch]

Jeff,

I have an Intel Core 2 CPU. You said, "no I can't see any reason that the original vi would operate repeatably". Do you mean "... would NOT operate repeatedly"?

Ed

[JÞB]

---

@Edjsch wrote:

Jeff,

I have an Intel Core 2 CPU. You said, "no I can't see any reason that the original vi would operate repeatably". Do you mean "... would NOT operate repeatedly"?

Ed

---

No I meant repeatably.  the threads are completely dependant on the OS to schedule themthe only garantee is that all threads finish before the vi returns.  there is no reason to expect them to complete in the same order.

[Edjsch]

Jeff,

Thanks. I guess this is topic for another "thread", no pun intended! But I think the compiler would put all the "stuff"  (code/functions/vis) that's either outside of all loops or within a given loop, in the same thread. Then it would be the compiler that determines the order of execution of that "stuff". And then it would at least run the same way every time, independent of the OS scheduler.

Ed

[Edjsch]

Jeff,

BTW, if I highlight execution I can see that what I said in my previous post is correct. All of my code outside the While loop executes before the code within the loop. The code in the While loop then does execute in a quasi-random order (that is, "random" except when forced to execute in a specific order determined by the wiring), but the same every time.

Ed

[Alisha_P]

Hi Ed,

I did not notice that it ran any faster. Still ran around 250 rps. Attached is the portmon log.

[Edjsch]

Thanks, Alisha. That's what I expected, since it was already keeping up with the 250 RPS being received. What if you tried it at 1000 RPS, the "fastest" (apparently, unless you coded your own delay function) that a LV loop (the vi that writes the strings) can execute since the Waits are in 1 millisecond increments?

Ed