Wait Until Next Millisecond Taking longer than it should

[RavensFan]

You should put the Write to Spreadsheet File in its own loop and pass data to it through a queue.  File functions tend to take longer than other functions, so perhaps a hard drive slowdown adds some slower loop iterations.

But as Frozen noted,  6 second loop iterations that get recorded every second doesn't make any sense.

EDIT:

Actually I see what it is.  The way you coded your logger is illogical.  You are writing the "MAX interval" that you store in a shift register every time your loop runs.

Yous should only record the current loop's interval.  You actually only have 1 6-second delay in there.  And like I said, put the logging in another loop.

[Frozen]

I was thinking more like this...

This will capture all loop variations that are more than 10% of your target time. (might want to make the tolerance a bit tighter)

[evapjep]

Understood, but it doesn't matter how the logging works, this was all just to test the problem with a time log to catch it for review of system log.  Yes there are more efficient ways to log, most of my data files are binary, but there is no logging at all where this issue came about.  The loop that does the same slow down every 2-3 hrs is this (there are no errors, the 10ms delay is re-entrant pre-allocated, yes there is a local variable, but it's not causing a multi-second slowdown):

Intention is to send minimum of 3 rising edges every second, with some headroom for the non-real-time OS, thus 3 rising edges every 750ms.  Again, this all worked for years, but now I am seeing more and more PC's drop out.  Yes real time FPGA would be better, but there also is a cause of this and must be some way to workaround, that is what I am trying to find out.  Still open to ideas, but base it off this code, not the loops made for testing the principle that are not optimized (though should still not be slowing down that much).  On my Dev PC, I do notice sometimes Ctrl+Alt+Del bumps up the delay quicker, but the other systems are not touched.

[Kevin_Price]

- The use of autostart==True in the call to DAQmx Write is sub-optimal, though by no means should it explain *seconds* worth of extra overhead.   See the DAQmx Task State Model for more info.  Regardless, I'd try starting the task explicitly before this loop instead.

- Any chance your DO task is on a USB device?   I've seen a number of threads concerning anomalies that traced to Windows' over-agressively putting USB ports into some kind of low power state

Obviously, these both put suspicion onto the DAQmx Write call, they say nothing about your simpler stripped-down test case that *also* showed a multi-second iteration interval.  But I'd second others' suggestion to run that stripped-down case using separate producer / consumer loops for timing measurement and logging to file.  And I'd also second the motion to log each individual interval, or at least each one that's far from nominal -- there may be some important clues to be found in the *cadence* of the extra-slow iterations.

-Kevin P

[RavensFan]

I say restore your PC back to a point before any windows updates happened that may have caused the random slow downs.

If it worked before for years, and you have problems now, then obviously something changed.  Everything we told you about logging was to get some sort of measurement of what is going on without having the measurement process itself aggravate the problem.  The trick is for you to figure out what things changed on that PC then proceed to undo those changes!

[evapjep]

So this happens nearly to the dot every 3hrs42sec, now to find the root cause...

Timestamp	Lag	Dwell H:M:S.s
10/24/19 4:21.55 PM	5685
10/24/19 7:21.14 PM	5784	3:00:41.59
10/24/19 9:52.64 PM	5813	2:30:36.51
10/25/19 12:53.14 AM	5391	3:00:41.49
10/25/19 3:53.68 AM	5691	3:00:41.55
10/25/19 6:54.22 AM	5749	3:00:41.54

[Frozen]

It seems very repetitive! Might give you a clue, or it could be a dead end? (I hope not) At least you have another data point.
Interesting that no one else experiences this problem, so it points to a company specific problem, IMHO.

[Kyle97330]

Can you check the following:

Windows Task Scheduler (for anything listed as "When X occurs, then every 3 hours afterwards)

Windows Event Viewer (For anything happening at the same time as your lag)

Any antivirus you might have installed (For scheduled scans or updates)