Firmware Retraction M101, M102?

oozeBot

@Phaedrux Thanks. Where I found reference to it was in an old thread about firmware retraction and Simplify3D (which I still prefer). David had mentioned ticking "Include M101/M102/M103 commands" under G-Code options but warned Simplify3D had issues (which it does and cannot be trusted in v4.12).

However, there was a way..

What I ended up doing is NOT using that option but adjusting the retraction settings to have no vertical lift and only retract .01mm at a 3333. This introduced predictable lines (G1 E-0.0100 F3333 and G1 E0.0100 F3333) that I could replace within my Post Processor with G10 and G11. This is working beautifully and fit nicely into our workflow as all our gCode files are already getting run through our post processor..

jay_s_uk

@oozeBot there is some post processing code kicking about that converts M101 etc to G10 for s3d that's automatically ran when you output the file.
Might be worth looking into if you want to play with firmware retraction again

Phaedrux

Well if S3D reliably inserts M101 and M102 then the macro option I mentioned would easily substitute them for G10 G11 without post processing, but if you already have a post processor that works for you then right on.

oozeBot

@jay_s_uk Actually, I may have just found a predictable pattern using the M101/M102/M103 option within Simplify3d.. it's just not what I was expecting. It sucks Simplify3d has gone dark and will likely drive me away here soon..

oozeBot

@Phaedrux Thanks - that's really good to know about unique M/G code macros as I didn't understand that was an option. That could be very powerful! will start playing with this here soon..

Phaedrux

Yes it's quite powerful especially with conditional gcode, you could create your own M/G code to do something unique/specific if you wanted.

jay_s_uk

@oozeBot i've followed this guide in the past to get it working https://thrinter.com/using-firmware-retraction-with-simplify3d/

oozeBot

@jay_s_uk that is legit almost identical to what I just implemented in our post processor..! thanks

dc42

RRF still support M101 and M102. However, the use of those codes to implement firmware retraction isn't perfect because S3D doesn't generate them exactly when a G10 or G11 would be appropriate. So a post-processor is preferred.

If the S3D developers can't be bothered to support firmware retraction after all these years then IMO it's time to ditch S3D. I already have, in favour of PrusaSlicer.

oozeBot

@dc42 yeah, I agree that it's time to ditch it, I just can't bring myself to it with everything else we have going on. Instead, I just keep patching S3D's problems through my post processor, however, that guide @jay_s_uk posted can probably be expanded to completely replace my home grown solution..