Pause and stop fan for next layer (bridges)
Pause and stop fan for next layer (bridges)
I'm trying to print a phone stand model I made, the base of which I plan to fill with sand to add some weight, because it's cheap, I have some on hand and it fits well with how my model is designed. However, because sand can easily get thrown around by the print fan, I need to stop it to print the bridges right above the compartments where the sand is stored. Some sagging is OK as I designed my "sand storage compartments" to avoid long bridges. In essence, I want to pause right before the bridges are printed, fill with sand, then resume with the fan turned off, print the bridges and turn the fan back on.
I tried multiple combinations of pauses and custom gcode but can't figure it out. I think I got it "right" with my latest attempt (the preview in PrusaSlicer shows exactly what I want) but during printing the fan turns on and stays on after resuming the print and while printing bridges, as if the print resume overrode the zero fan speed I set for that layer.
Here's a test part I'm using to try to figure this out. Here, I'm using M601 (pause) and M107 (stop print fan) on layer 4, then M106 (start print fan) on layer 5. As you can see, the bridges are displayed as if they would be printed with a fan speed of zero but that's not what happens when printing. The fan starts as soon as the print is resumed and never stops. It does not do what the preview shows:
I have included my test project if you want to check out the settings.
Thanks in advance for any help!
RE: Consider sparse infill
Stefan did a video on weighting prints on his CNC Kitchen YouTube channel, using infill sparse enough to allow filling with resin. Different patterns allow you to drill a hole after printing and fill it up easily. This alternate approach might be safer for your printer and easier to produce.
RE: RE: Consider sparse infill
Thanks for the info @bobstro! I will definitely consider it for some other prints. I'm still interested in understanding what's happening here though (and I don't have any resin on hand at the moment). It may not be the best way to do it, but it's still a valid way I think. A few advantages compared to resin is no holes required and no drying time. Any insight on how to do exactly what I'm trying to do slicer/gcode-wise and why the printer does not do what the preview shows?
Sparse infill may work well with fine sand
Sorry, I didn't finish my thought. If you can find fine sand, some of the infill patterns can probably be used with that. The adaptive patterns which are more sparse near the base and increase density further up the model may be ideal.
I haven't done it myself, but may people just insert a pause gcode command that moves the nozzle out of the way for part insertion. It's a lot like a manual filament color change procedure.
RE: Sparse infill may work well with fine sand
Thanks, I'll look that up (I didn't find the CNC Kitchen video you're talking about though, mind to post a link?)
Although the information you provided is useful it still doesn't directly address the slicer/gcode behaviour I'm observing (details in the original post). Do you have any insight on that specifically? I'd probably still have the print fan issue to deal with even with sparse/adaptive infill filled with sand as you suggest. I'd really like to understand what's happening and figure out why the slicer preview and printer behaviour seem inconsistent. Is it a bug? A global setting taking precedence? Something in the firmware's resume procedure that I can't override?
RE: Pause and stop fan for next layer (bridges)
I tried it on my i3MK3+ with the following results:
Print head goes to back left corner, when I hit resume the head heats up, fan ON, goes to part, starts to print and shut down fan at the same time. That is of course a bit too late, the sand has already blown away.
Fan turns OFF, printer go back left, hit resume, printer heat up, goes to part, print "bridge" layer, fan ON, prints next layer 👍
As said, this is on i3MK3S+
This is a great idea, sand, lead pellets or something similar. Thanks for the tip
RE: RE: Pause and stop fan for next layer (bridges)
I tried your suggestion (comparing with your 3mf to make sure) but unfortunately the fan turns on and stays on as soon as I hit resume on the printer. I'm starting to wonder if that might be a bug in the printer's firmware or at least a limitation implied by the way the resume procedure is currently implemented.
I'd be curious to have someone else with a MINI try this.
Ok, I figured it out. The solution is far from obvious, though.
I figured that if the M107 command was ignored after the pause (M601), it may have been a matter of concurrency, e.g. the command being run at the wrong time (possibly before the resume sequence ends and before that sequence’s “turn fan back on” command) due to the way the firmware is implemented, or possibly a bug.
In multiple languages and programming environments introducing a timed delay causes things to be enqueued to be run later instead of being run synchronously. I had also heard about Marlin using a “planner” of some sort to process commands, which screams concurrency to me. Thus, to try to have my M107 command run after the resume sequence is fully completed, I added a small 1ms delay (AKA "dwell" as per the Prusa documentation):
M601 G4 P1 ; 1ms delay M107
That worked! Now the printer does exactly what I want: pause, resume with the fan turned off, print bridges, then turn the fan back on (M106 on the next layer).
However it felt like a bit of a hack. It still does, but I found a better way to do it:
M601 M400 M107
According to the Marlin documentation, M400 “pauses and waits in a loop until all moves in the planner are completed”, which seems to let the printer finish its resume sequence before enqueueing more commands on the planner. To me this looks much less like a hack than the 1ms delay even if the result is the same. Still, intuitively this shouldn't be required to make the printer act like the slicer's says it will.
In conclusion, I suggest the second approach (M400) to anyone wishing to do what I described in my original post. I also wonder if this should be considered a bug (I guess so?) and if I should create an issue on the MINI’s firmware repo on Github. What do you think?
Glad you found a workaround 👍
I would consider it a bug. It does not do what it says in the code!