LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial COM slow in Win10

Solved!
Go to solution

-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!

0 Kudos
Message 1 of 16
(9,787 Views)

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.

0 Kudos
Message 2 of 16
(9,780 Views)

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!

0 Kudos
Message 3 of 16
(9,759 Views)

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?  

0 Kudos
Message 4 of 16
(9,728 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 16
(9,708 Views)

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!

0 Kudos
Message 6 of 16
(9,644 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 16
(9,626 Views)

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

0 Kudos
Message 8 of 16
(9,601 Views)

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

0 Kudos
Message 9 of 16
(9,577 Views)

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

0 Kudos
Message 10 of 16
(9,568 Views)