Timed loop slows down seriously whenever I drag any window box in Win 10

[Jhinhwan]

The timed loop I used as shown below to ramp three output signals to target values slows down indefinitely when I drag any window box around the screen.

The flat ~50mV part of the yellow trace at the center of the screen is supposed to be absent. It is caused when I dragged a small window in Windows 10 (Education version for university).

I am running on AMD 3900X 12 core 24 thread processor and I designated 8 processors to the timed loop and gave the loop a maximum priority value of 65535 and tried all different clock sources, and nothing helps.

Perhaps it's a Windows 10 thing and I set the LabVIEW and Nanonis processes to the maximum (Real-Time) priority in the Windows Task Manager's details tab. The loop performed slightly faster but the same infinite slow down happens when I drag a window.

I searched the internet and found that it may be related to how WM_MOVE message is handled in the app. But contrary to my expectation, the freezing of LabVIEW happens even when I am dragging a window in other apps such as that of Capture.

https://stackoverflow.com/questions/29552658/how-do-you-fix-a-program-from-freezing-when-you-move-th...

Is there any Windows 10 setting I can tweak to solve or mitigate this problem?

[lumonic]

Windows is just not a RTOS so many things can effect other things. I don’t think you are going to find a software tweak other than possibly using one of the extensions that third party’s make that turn windows into something as close to a RTOS as possible. These are used on CNC setups that have a windows interface. Another option is installing and running under a RTOS version of Linux. Another option is offloading this task to something external like a microcontroller or a arbitrary waveform generator.  

[altenbach]

You are not assigning 8 processors to the loop, but processor #8 (just one). You have not mentioned the execution settings of the vi itself. Half of your processors are virtual.

In my personal opinion you are way over-micromanaging everything. What if you take a few steps back and put all settings back to default. Then start with subtle tuning if needed. Maybe you should also settle on one floating point type and avoid all these coercion dots. Can't you do hardware timing?

[Jhinhwan]

Thanks for your comments. I looked up the Windows RT extension a little bit and I am not sure if it works for LabVIEW.

Since Youtube video on any browser can be played without a glitch for minutes of dragging a window around the desktop,

I think there should be something NI (LabVIEW or Nanonis) can do about it. If LabVIEW is delayed for minutes of dragging a window

while web browser isn't, I don't think it is fundamentally limited by the OS. Since this happened with LabVIEW Programming Interface

of Nanonis, it also may be due to communication issue between Nanonis and LabVIEW. I will check it out.