My solution to solve the watchdog issues with custom sound generation

[bmuessig]

As discussed issue #2045, long sound durations often cause the watchdog timer to reset the printer, as the sound generation is currently using regular delays that don't feed the watchdog timer.
I am proposing a hybrid solution that uses regular delays for short beeps and a modified version of delay_keep_alive that doesn't update the LCD for long delays that exceed 1.1 seconds.

[bmuessig]

Having hit PR number 3310 in a sound-related PR, the classic Nokia 3310 ringtone came to mind: https://www.youtube.com/watch?v=h6iIFVTwKeE

[leptun]

Not sure if doing something like this is really needed. You could just use delay_keep_alive(noUIupdates) regardless of duration. As long as no sounds are generated, delay_keep_alive() is just fine at all times, with the added bonus of managed heaters and inactivity messages on uart so that the host doesn't time out.

[bmuessig]

I was not sure how much delay the update routine adds (which might also vary), so I thought it would make sense to keep the length of short beeps more accurate. But if this is not required, this could be simplified indeed 👍

[leptun]

Not really relevant considering the points above, but just a quick observation:
Instead of doing if (delay < 1100) delay(); else delay_keep_alive();, do if (delay > 1000) delay_keep_alive(); else delay();

[bmuessig]

I didn't just choose 1100 ms to exclude one second long beeps, but I added 100 ms in case someone somewhere used a delay around 1 second, but not exactly.

[bmuessig]

Alright, I have now combined the multiple methods into one with the second optional parameter controlling whether to update the LCD.

Now, what's the best minimum threshold to trigger delay_keep_alive instead of the regular delay?
We could lower it from the current 1100 ms to e.g. 260 or 510 ms, but I want to avoid that regular beeps vary in length.
Many long running update operations might produce an audible difference, so I would suggest keeping the regular delay method for the short default beeps.

[leptun]

I'll look at the updated PR soonTM (maybe tomorrow). In the meantime, here is a gcode with music:
WII.zip
You can try playing with the treshold and see if it negatively affects the file. Please also use the stock firmware first to get a baseline (it's kinda crappy already).

I think delay>1000 is a good enough threshold instead of >1100. It doesn't really matter at that point if it's 1000 or 1050ms. This threshold might only improve things when quick beeps are produced. WII.gco includes some of these in a quick sequence in the second half of the song.