Missing "ok" on response of M29 causes communication timeout

[foosel]

Problem

Most Marlin-based firmware currently out there in the wild has a bug that has M29 not being acknowledged with an ok. See also MarlinFirmware/Marlin#3055 and the discussion in #450. That doesn't cause problems as long as #1272 is not patched since the additional ok introduced by that issue will level things out again, but as soon that is closed, the communication will stall at the end of streaming to SD.

Always injecting an ok however will also cause issues, since mainline Marlin patched the bug, other forks might have it patched too and of course completely different firmware might not have it in the first place.

Solution

Add feature flag to signal broken M29, inject ok only if flag is set.

Alternative solutions and why they aren't choosen:

• Defining broken GCODE commands: thanks to another Marlin bug commands are not acknowledged in the same order they are sent, so we cannot easily associate output with command. In the case of M29 we know the output, but in case of arbitrary other GCODEs we don't, so we wouldn't be able to identify the response.
• Defining a list of responses belonging to broken GCODE commands: Too much overhead during message parsing for just one case right now to justify implementation effort.