Serial communication appears to running on low priority.

[Xonmyth]

Hello, 

Hope you are doing well!

I have run into a strange issue and I have no idea how to resolve it. I am talking to a UART device at 5000000 Baud using LabVIEW's serial communication VIs on PC side. 50,00,000 Baud might be too much but it has been working totally fine for a little over 1.5 years now, even in the high emf noise environments. But around 29th of September (one possible suspect- windows update) it decided not to work on the non-development PCs. Program still works robustly on development PC.

Device sends 4096*46 = 188,416‬ Bytes ~per second and once ready, program would read it all. Buffer size is set to 10 times (188,416‬0). Device uses FTDI chipset, all drivers are installed and are the same on the development / non-development PC. After couples days of trying to troubleshooting, this is what I have observed: 

Run the program on a non-development PC, everything will work as expected until another program is loaded (can even be a calculator app), use windows explorer search function, a modal pop-up up in the LabVIEW program or similar functions that may require CPU attention, breaks the packets rest it still works fine.

Without problem packets look like: 46n0, 46n1 ......46n4095. 

When interrupted packets become something like:  46n512, 46n513....46n4095...46n0....46n511 (Packet loss)

Once again, this was not a problem ever before and nothing has changed on my end. Only change is the windows update. Any suggestions on where should I possibly look to gain the functionality back? It almost seems like the VISA VIs or the under-the-hood stuff was running on high priority before but not now (Not talking about LabVIEW VI's execution priority).

I did not attach a code since I do not think it is the problem but if required, I will make a simplified version of it and share it here.

Thank you for reading, I would really appreciate any inputs.

Best,
X

[BertMcMahan]

I am seeing a similar issue that started around the same time. I considered it to be a hardware issue, but now that you're saying you're dropping packets too I'm starting to wonder...

It could still be a hardware issue on my end- I haven't dug into it yet- but I'll be watching this thread closely.

Any chance you could roll back your Windows update and see if it fixes things? Doing that on my machine will be very involved due to my particular IT situation. 

[Xonmyth]

Hi BertMcMahan!

I had some SUCCESS! 

I did not roll back the windows but writing the question gave me some clarity and that led me to read about "latency". I tired to see what the read latency was for my device under windows settings:

Go to device manager and navigate to Ports(COM & LPT): 

Right click on the port of your interest and select properties:

Go to port settings & click on advanced:

Set Latency value to a value of interest: (mine was at 16ms so I changed it to 1ms)

This seemed to have solved my problem, for now. Now I need a way to be able to programmatically change it. I will keep testing to see if this was just a fluke or an actual fix. I will keep you posted.

X

[Xonmyth]

I can confirm latency setting was the culprit in my case. I could replicate this across multiple machines and devices running Windows11 or Windows 10. There are some more settings that might have also changed but I do not know what they originally were. For example: Selective Suspend Idle Timeout (secs): 5. I would set it higher in my case.

In my case of FTDI drivers, I used their own VI "FT_Set_Latency_Timer.vi" to change this setting through LabVIEW itself. 

I hope your case has something similar/ simple going on.

Good luck

X