Serial COM slow in Win10

[prugno]

-Is there a reason why Windows 10 should affect serial communication in Labview?

-We use LabView to control mass spectrometers which link via USB Serial port at 921600 baud. Our program is basically a serial read/write QMH, nothing fancy here.

-We are unable to make our program work on brand new, powerful Windows 10 machines made by Dell.

-In fact, we have always used Core i3, Windows 7, 32 bits machines, and always got an execution time of 1ms. But with the new Windows 10 machines, we have 1.9ms execution times, which makes our program buggy.

-We have Kaspersky running on each machine, old and new.

Could anybody shed light on the issue?
I thank you in advance!

PS I don' t have the right to post our code; nonetheless, I am sure that the problematic parts are just the basic VISA Read/Write vis, as I have tried to progressively disable all the others program' s parts to check for the guilty!

[Eric1977]

Take LabVIEW out of the equation as I highly suspect that is not the issue. I'm going to assume that the 921600 BAUD is a typo as well.

Download HyperTerminal or Putty and do the exact same thing that you're doing in LabView and see if the performance is the same.

[prugno]

Our instrument really interfaces at 921600 baud.
I can' t replicate the issue on a serial terminal, as the data from the spectrometer flow all the time; every message is encoded using a compression mechanism which is uncommon, and whose decoding is the purpose of our aforementioned program.
What could it be, if the same exact program runs faster on an older machine? This is paradoxical!

Thank you for your time!

[Kyle97330]

Can you install a virtual COM port driver and see if LabVIEW sending data to itself via the virtual port has the same delay problem?  Compare that result on both a W7 and W10 machine, if possible?  

[crossrulz]

---

@prugno wrote:

I can' t replicate the issue on a serial terminal, as the data from the spectrometer flow all the time; every message is encoded using a compression mechanism which is uncommon, and whose decoding is the purpose of our aforementioned program.

---

It could simply be a driver issue.  It could also be your application not being written in a parallel architecture such as a Producer/Consumer.

[prugno]

Do you mean the FTDI driver? I installed the most recent version.

You are right in the sense that the serial data is read/written in the same While loop as the data processing subVIs; nonetheless, it never gave us problems on older machines!

I will try to separate the serial read/write VIs into a separate while loop.
I am going to try a Timed Loop as well and see if I can force a response time under the millisecond.
I will update as soon as possible!

Thank you all!

[crossrulz]

---

@prugno wrote:

I will try to separate the serial read/write VIs into a separate while loop.
I am going to try a Timed Loop as well and see if I can force a response time under the millisecond.

---

Timed Loops in Windows are worthless.  It won't increase your speed.  It will most likely just add more overhead and possibly even slow your loop down.  The point of Timed Loops are for determinism in an Real Time system.

I doubt separating the read and write will help any.  In fact, I find it best to keep them together.  But if you are processing the data in that loop, that is what can be moved out and handled by another loop.

[Eric1977]

You mention serial communications and a FTDI driver. Are you using a serial to USB converter?

[K C]

Hi,

Used a lot of serial communications over the years. Since the COM port is not directly connected to the chipset inside the computer and with the newer versions of Windows the serial throughput is not getting any better.

The speed of the link doesn't solve much (except if it is very low)

What will speed up things is using a Ethernet to serial converter. Something like the Moxa MB3170 (ModBus) or a NPort converter.

Kees

[prugno]

Our spectrometer only has a USB port for serial communication! Hence the need for a FTDI driver.