Oh. And thank you to the fine members of the community who figured this out.
I remember at the time it was coming up on Christmas last year. I had bought all the parts to do this mod, but hadn’t needed to… At first.
Then just as I was desperately trying to finish printing a ton of gifts I got slammed by the intermittent skips. Was able to do the mod which let me finish printing stuff in time for Santa Claus.
Cheers also to Snapmaker for the new hotends. They’re good too, though a bit disappointed by the custom heat block and press fit. They work great though.
Yes, this is exactly the risk when you add three separate threaded items on top of each other, which is why sonewhere in this huge thread a corresponding warning is buried if I recall correctly - and why I chose to use the spacer shown in the presentation on top instead
Hunh… you mention something there which I never wrote about. One of the very first things I did when I created my Prusaslicer configuration based on the initial stuff @McGybeer and @macdylan created about two years ago was to change the start gcode to “let the bed heat up to 5°C below target temp, then let the bed and the hotend(s) heat up to target temp” - easy to do in Prusaslicer since you can use the internal variables, other slicers are probably not so flexible.
And then all the stuff that lead to this thread here came…
I use prusaslicer too and I ended up removing a lot of the custom gcode from the macdylan profiles. There is a lot of unnecessary stuff in there. I don’t have any temperature related gcode in my start gcode because prusaslicer can handle all of that automatically if you don’t put any temp commands in your start gcode. It heats bed first before heating the hot end. All I’ve got left in my start gcode is g28 and m83. That’s literally it lol. I use a skirt in my print settings, so no need for the terrible purge sequence that was in the start gcode. No need for the start gcode to set machine limits since going to the “machine limits” tab and changing the dropdown to “emit to gcode” does the exact same thing.
Changed the tool change gcode a lot too, but most notably was removing the snapmaker custom gcode for fast tool change and using normal marlin gcode to park extruder on switch so I won’t have any issues sending via octoprint.
Hm, I very much prefer to control start gcode myself. Last time I tried, Prusaslicer did not cope too well with varying bed temperatures for both hotends for example since it is not optimised for an IDEX printer yet. And the purge line is actually something I definitely keep - if you print a very small part a single skirt line is not enough to purge the amount I want, and many skirt lines in order to reach a minimum of extruded material take much longer than that single purge line. I had your “just skirt” method for years on my old printer, was happy when I first saw a purge line and implemented that on my own back then.
Anything tool change code is handled by the correponding RRF macro in my case - so yes, when it comes to Snapmaker code, we are in the same boat again. But that is the nice thing about an open slicer - just configure it as you want
Yes, simple impatience is the reason behind it - 5° is roughly the temp difference the bed manages while the hotend heats up, meaning a little less waiting time
- 5° is roughly the temp difference the bed manages while the hotend heats up, meaning a little less waiting time