Hi,
I was wondering if it’s possible to schedule a pause in the print at a specific layer?
If not, it would be a very useful feature for embedding an item inside a print.
Of course it’s possible to do it manually but you have to time it and wait for the correct layer which is somewhat tedious and time consuming.
I haven’t seen that option anywhere in Luban. Cura has a post-processing script to do it (as well as others), but I haven’t personally tested it. I don’t what it does, or if it requires firmware support on the device.
You could select the correct line if you open your .gcode with wordpad or something similar, splitting your code into two pieces.
This is absolutely a standard function in normal g-code, it’s called an M00 command (those are zeros). And it is supposed to force a pause in the running program, which the user has to resume by pressing the “run” button. I have no idea if it’s supported though, certainly worth checking out!
I did not find a way to do this in Luban, but it is easy with Cura and Octoprint. The piece below was paused using the preprocessing script in Cura. After placing my magnet, I just hit resume on octoprint.
I can confirm the M00 command does work with SM. Well, sort of. The only problem is there isn’t an unpause option.
-S
That is where Octoprint comes in.
I get the appeal of Octoprint but I have so little need for it and no desire to spend the time or money to get it set up for what I do.
Especially since there’s no reason SM can’t have pauses built in.
It can resume after a power failure or filament runout, so obviously just a matter of enabling and reprogramming the firmware.
-S
I agree with you. Octoprint is necessary for me since I am too far from the printer to stay directly attached. If they would put a web interface on the touchscreen and give us the missing features, I’d drop Octoprint. It just seems easier to extend Octoprint than replicate it.
The following applies to a Snapmaker 2.0, cannot speak to the original:
Yea, I just tested that too and found that M108 doesn’t respond properly. Looking through the firmware it appears that EMERGENCY_PARSER is disabled (due to a chip restriction maybe?) and I’m guessing the serial buffer is full / not being parsed properly once the pause happens.
If I could put a plug into the developers to see if we can enable EMERGENCY_PARSER a few things would suddenly work as they should (@Edwin please?) :
I could see the developers leaving it disabled since the intention of M0 would be pop up confirmation on the screen, preferably by implementing the firmware’s built-in notification UIs like EXTENSIBLE_UI. But even without a true pop-up, being able to use M108 and M112 would be something that a 3rd party machine interface (like Simplify3D’s) could use.
+1 here. While I have Octoprint set up and working, when I use it for a job instead of the SM2 touch screen, I lose features such as filament runout sensor and power recovery, and those are important to me, and even more so on really long prints of big projects. So, switching to Octoprint control when I need to do a “Pause at Height” task, is doable but not ideal.
Really, ideal would be to have best of both worlds: SM2 supporting resume after a “Pause at Height” task, and also having SM2 support Octoprint having access to filament runout sensor (and power recovery too?).
Snapmaker has accepted the continual beatdown of people wanting pause/resume added and has agreed to do so on github.
Now they just have to actually release a firmware update with it included.
-S
I guess I need to eat my words.
They just released a new firmware. (It’s about time!)
Who’s ready to break their machine?
-S
The firmware doesnt seem to have included much of interest though, unless it just isnt in the release notes.
I feel like their release notes have been consistently inconsistent.
Only way to know is to play with it.
-S
None of the commits from January were included it seems…
I’ll be off to compile my own version again then I guess…
It was just confirmed on github that the new firmware was still based on the non public repository. I was a bit disappointed at first that doing the firmware upgrade meant going back to a previous version as I was already running my own slightly modified version. (I hoped that my fix that was committed was already included)
On the other hand, it’s not such a big deal for me personally. But the commit to allow toolchanges while the device is powered on by shutting of power to the toolhead by @brent113 and my own to start the calibration at the first calibration point in stead of at the back (which causes the printhead to smash into the bed if your buildplate is higher than expected (my heated bed is on an mdf wasteboard) would have been nice.
but not such a big deal to recompile with those included again.
Did you change your gcode to pause in octo print? Or did you manually wait and pause it?
I tried using gcode a while ago and while the machine paused, I found no way to resume.
I did the pause with a Cura postprocessor command, then resumed it from Octoprint.