Octolapse: M114 Not Implemented on Anet ET4 Firmware

[FormerLurker]

The Anet ET4 does not implement M114, a standard gcode. Currently the printer responds with an OK, but not with a position reponse, simlar to thi: ok C: X:0.00 Y:0.00 Z:0.00 E:0.00

Octolapse and indeed OctoPrint (as well as a lot of other software) relies on this gcode's response. Octolapse cannot function at all currently without M114.

The best solution to this issue would be a firmware update. However, I will be attempting to find an alternative gcode that can support at least some of the functionality of Octolapse.

[FormerLurker]

I added a test at print start to detect M114 support, and to report an error if it is not supported. This is about the best I can do I think.

Closed!

[eoleinik]

@FormerLurker I was able to get Ocolapse working with Anet ET4 with a dirty one-liner, by making this method:
https://github.com/FormerLurker/Octolapse/blob/48616fb115e669fdef2cba2cdc50e40c104f4517/octoprint_octolapse/gcode_parser.py#L742
always return {'x': 0, 'y': 0, 'z': 0, 'e': None} (essentially always reporting a made-up position)

Settings used:

• "GCode" snapshot mode, with G4 P1 snapshot command, as suggested by this YouTube guide.
• Made the slicer insert G4 P1 at every later change.
• Stabilization: Extruder at Back Left
• Snapshot delay of 3000ms to give the extruder time to park corner before snapshot is taken.

Anet indicated they won't be open-sourcing the firmware, and there are a lot of owners unable to use Octolapse due to unimplemented M114. Do you think it would be possible to add a setting option to disable position checking, since it doesn't seem to be necessary for Octolapse to work?
I'd be happy to contribute, as long as you're ok with the approach :)

[rizwansarwar]

M114 is now supported in ET4 firmware 1.1.7 (in beta at the moment). So no need for code patch, although useful for printers that might still not support M114.

[FormerLurker]

@rizwansarwar, that is great news, thank you for the update!

@eoleinik, I may still take a look at this, but a snapshot delay of 3000ms will definitely cause some print quality issues. It might be possible to use some other command, as long is it returns some predictable output (not just an OK) AND the output is not returned until all print moves have completed (honoring M400).