After probing the first corner the first time M112 emergency stop issued, same as stuck waiting?

[jbodhorn]

After probing the first corner the first time, occasionally my printer will issue an M112 emergency stop command and need to be reset/restarted and I'm not sure why

Steps to reproduce

Not sure honestly, it'll occasionally happen a couple times in a row. When I haven't been able to get past the first probe I've tried running G29 P4 T(Running the Bed Level Visualizer mesh update gcode for marlin), it's run from the bed level visualizer plugin for octoprint. I'll adjust the bed and eventually try AutoBim again and it'll work

Expected outcome

That it will go through the whole tramming/probing sequence without sending an M112

Actual outcome

M112

Environment (leave empty if unknown or not relevant)

• OctoPrint version: OctoPrint: 1.7.3
• Python version: Python 2.7.16
• Marlin version: 2.0.9.3
• Probe (e.g. BL-Touch, EZABL, ...):
• Printer: Ender 3, BTT SKR MINI E3 V2.0 + TFT35 E3 V3, dual z, Micro Swiss DD and Hotend
• Browser Un-Google'd Chromium on Arch Linux X86-64

Question

I wouldn't have asked about this if I was stuck at waiting as in the troubleshooting section, so I'm sorry if this is the same thing. Is this the same issue as the stuck at waiting after first probe

[jbodhorn]

I really love the plugin BTW, I tried the tramming wizard marlin has, this is way better. IMO you should contact Marlin's dev's via Github and have them make the Tramming wizard work as you have here for this plugin

[j-be]

Hi, sorry for the late response. I've been busy the last couple of days.

That said, thank you very much for your kind words. I, too, think that Marlin should support something like this. I have to admit I never actually got the LEVEL_CORNERS_USE_PROBE feature of 2.0.8 (iirc) to work (frankly: I didn't really try), so I'm not sure if it isn't already kind of there. And honestly, it feels a bit weird to go to them and say "hey guys, you should implement my way of doing this - it is way better than yours", as I am obviously biased. In any case: feel free to propose the feature 😄

About the M112: my guess would be that is due to the bed being to tilted: there is a safety mechanism in Marlin doing something like: "do not lower Z below the given threshold when trying to probe". I can see how that makes sense, like if a probe fails to trigger. I caught this once. See Z_PROBE_LOW_POINT here. 2 mm (seems default) sounds like a lot at first glance, but it really isn't.

It is the only way I can think of how to get a safety shutdown with the things I am doing - the plugin is only using G0, G28, G29, G30, and M117.

If it isn't Z_PROBE_LOW_POINT and you can reproduce it, please post the last couple of lines from OctoPrint's Terminal tab starting with the G30 command here (please disable temperature reporting first). Maybe there is a clue on what is going on in there.