[3.6.0-beta.2 and prev] Random out of sync

leone

Hi all,

from 3.6.0-beta.1 I started to have some layer shifts in the first layers of a print. These shifts happen randomly (the same gcode might shift in one print and not in the consecutive one, or just in another position). Still, I didn't find a way to replicate exactly the issue. The shift happens because the expansion boards go out of sync for about 2 seconds and the movement commands are discarded (as intended behavior from 3.6.0-beta.1).
So far, it never shifted when the bed compensation was disabled or, when enabled, it never shifted above the tapering height (5mm).
To debug, I connected a can sniffer device and analyzed the TimeSync messages. The out-of-sync happens when the field lastTimeAcknowledgeDelay is zero for more than 10 consecutive times. From my understanding, the CanClockLoop doesn't update this variable if the previous message takes more than MaxTimeSyncDelay between the call of the send function and when the ISR actually processed the TX callback.

From the plots you can see that the behavior of lastTimeAcknowledgeDelay with FW 3.5.2 and 3.6.0-beta.1 is similar, so I might never have had a shift before just because in 3.5.2 the movement commands weren't discarded.
I increased MaxTimeSyncDelay from 300 (400 usec?) to 375 (500 usec?) to see what happens: these spikes are still present but the number of zeros is reduced, so hopefully tolerant enough to never reach 10 consecutive samples.

From the plot, it looks like the normal value for lastTimeAcknowledgeDelay is around 3-5 and a cloudy distribution around 250-300. So the original threshold of 300 would make sense.
I'm wondering why there are these spikes, after one spike to about 300 or more, the spike is then repeated every 5 samples but with a linear decreasing amplitude.
I tried also to disable the input shaping but the overall distribution is similar.

Do you have any explanation for this behavior? Other processes or interrupts interfering? Do you think it would make sense to increase the MaxTimeSyncDelay threshold or is it just a patch? Do you foresee any issues arising from doing this?

Thanks in advance.

droftarts

@leone Thank you for your in-depth analysis. I've highlighted it to @dc42.

Ian

leone

Thanks @droftarts.
Update note: I got a resync also with MaxTimeSyncDelay = 375.

leone

now I'm doing some tests increasing StepTimer::MinSyncInterval from 2000 to 4000. I noticed it was already increased some years ago, it might be the same issue, I am also running on a SAME70.