Document G29 differences from upstream Marlin behaviour

[ToxicFrog]

Based on the wiki and reading over the issues, it looks like at least the following should be noted:

• AUTO_BED_LEVELING_BILINEAR is enabled, so the relevant documentation page is this one and the pages on UBL, 3-point, linear, etc leveling should be ignored
• G29 C1 is now "compute least-squares leveling plane based on existing mesh" rather than "generate fake mesh for testing"
• G29 P0 has been added and does a simple start-of-print height probe (I think, based on comment here)
• RESTORE_LEVELING_AFTER_G28 is disabled, so you need to re-enable the leveling mesh in your starting G-code after homing with G28; M420 S1 should do this, it's not clear if G29 P0 will as well or if you should use both

[aegean-odyssey]

Thanks, I've updated the wiki's G29 links to the Marlin documentation; your link to the bilinear-specific page is a much better choice. I'm making some changes to the G29 code now, so I'll update the wiki with the G29 particulars with the next release.

FYI, G29 P0 does enable the leveling mesh. It is equivalent to G33 P1 V1 followed by M420 S1. I added it to be compatible with shamelessly borrowed the idea from Marlin4MPMD firmware. Without G29 P0, M420 S1 should be used after homing with G28 to re-enable the leveling mesh.

[edit] Also please note that Marlin 2.0's G29 H parameter is not supported in the firmware.

[ToxicFrog]

Also, if there's some way to abort G29 when it starts going wrong (short of rebooting the printer), that would be great to have documented.

[aegean-odyssey]

Another good point.

Marlin's concept of "cancel" is to shut everything down and restart its program from the top. So to cancel the G29 command, Marlin offers M112 which does shutdown everything down and restarts (not technically reboot, though). With mpmd_marlin_1.1.x, M112 should flash a red LED and wait for the user to press the LED push button switch to continue. Pressing the switch initially should also cause the same kind of abort.

Marlin does offer M524 (Abort SD Print), but it seems to have been added as a patch to an all ready kludgy "abort printing" mechanism. There really should be a gentler way to cleanly exit Marlin's longer running commands.

[aegean-odyssey]

In issue #28 @ToxicFrog comments:

It looks like the firmware has some checking for completely ridiculous G29 results caused by one of the switches getting stuck down and/or the switches being so finely balanced that just moving the print head around closes them, and will abort the G29 procedure if it detects this. When that happens, the LCD will show an error message and the indicator LED will flash red. Pressing the button on the front panel will return the LCD to normal operation, but the LED keeps flashing red and the printer won't respond to serial commands until you power cycle it. Since I'm calibrating it via serial rather than using the gcode files on the SD, this is annoying.

What's happening here is that Marlin's motion control is detecting what is considers a motion error (e.g. not reaching a target position, hitting an endstop too soon, etc.). There is a little bit of extra checking because G29 employs a "probing move", but this is not specific to the G29 command; G30 (Single Z Probe) could have the same difficulty. An error is easy to simulate -- gently interfere with the print head's motion. So, Marlin detects a motion error and aborts via Marlin's "kill" routine which shuts everything down and restarts.

In mpmd_marlin_1.1.x, I changed Marlin's "kill" routine to flash a red LED and wait for a button press on the LED push button switch before restarting its program. The change makes it easy to spot a fault that occurs because the code is doing its job, or a fault that occurs because the firmware is "off in the weeds".

In most cases I think this is prefered behavior, but in @ToxicFrog's scenario this behavior is a definite problem. Off the top of my head, I don't have a good way to fix this. Even if the firmware restarted with no user intervention, the serial connection will drop, current machine state is lost, etc. -- all complications for the program on the other end of the serial connection. If such a program could detect the dropped connection, wait a few seconds, and then establish a new connection, then maybe the new connection could signal the firmware in the same way as a button press. I don't know; it seems tricky.

[ToxicFrog]

Even if the firmware restarted with no user intervention, the serial connection will drop, current machine state is lost, etc. -- all complications for the program on the other end of the serial connection. If such a program could detect the dropped connection, wait a few seconds, and then establish a new connection, then maybe the new connection could signal the firmware in the same way as a button press.

In this case, the program on the other end (octoprint) does detect the dropped connection, and I can ask it to re-establish the connection; when it does, however, the printer never responds. If I power cycle the printer first it re-establishes the connection fine.

It is possible that this is a bad interaction with octoprint. In particular I made some changes to the serial connection settings when I first set it up to work around a bug in the stock MPMD firmware that likely does not exist in mpmd_marlin. So I'll investigate that angle first; from what you've said here, it sounds like pressing the button on the printer and then attempting to reestablish the serial connection should work.

[aegean-odyssey]

You're observation is spot on. And it looks like Octoprint is robust enough so that maybe it will be possible to change the firmware to use a "serial re-connection" to indicate a "button press" in this particular situation. I'll look into it.

Thank you for following up. The information is helpful.

[aegean-odyssey]

Ok, here's what I think can work. Please bear with me as I first run through the scenario:

1. the machine is connected via USB
2. for whatever reason, kill is called (messages sent to USB)
3. the LED flashes red, but the serial connection is still up
4. pressing the button, the LED turns to solid red for 2s
5. the machine restarts, the serial connection is dropped

I believe this is the sequence. And if the case, the serial port is still operational while waiting for the button press. This is good -- there is already a mechanism in Marlin for this case: M108 (essentially, fake a button press). I can add the code to make this work. So the fix would be:

4. pressing the button, the LED turns to solid red for 2s, OR sending M108 via the USB connection to restart

I'll also send a "kill action" to the USB host, so it can respond automatically to the situation. The action is a specially formatted message sent to host that would look something like // action:killed. With this, OctoPrint could respond with M108.

I think this can work. If it does, then M112, emergency stop, could be used to abort long commands, since there would be a way to programmatically continue afterwards. Though not very graceful, the process does not need to "hang" waiting for a button press.

[UPDATE Aug 3, 2020]

I've added this to the upcoming release, 119r13. It seems to work pretty well. Testing with a terminal program, I was able to abort long commands with M112 and continue (reboot) with M108 -- no physical pressing of the button is necessary. Thank you for pointing out the issue, and for following up. This change is a nice improvement to the firmware.

[aegean-odyssey]

Closing, as I think everything is covered with the 119r13 release.

Please do not hesitate to re-open the issue if I've missed something.