https://www.duet3d.com/forum/thread.php ... 648#p37648
Community FYI post
I'd been doing test getting firmware retraction hooked up in RepRapFirmware.
As a baseline I first tested using S3D's software retraction. Then using the trick where you write a little text-replace script in S3D so it replaces all of it's retraction gcode with RRF G10's & G11's (and made sure my RRF's M207 values matched S3D's), and it printed exactly the same results. So that's good. But it's annoying that you have to write this little script in S3D to pull it off. I believe in other slicers, like Slic3r, this is handled far more elegantly.
Recently I read in a Duet forum post that you can actually use S3D's 'Include M101/M102/M103' 'G-Code Options', and RRF will respect that as an alternate path to firmware retraction: So, I disabled 'normal retraction', killed my scripts, and checked that option on. No more little scripts needed. A downside is that S3D no longer shows the 'retraction bubbles' in its gcode preview.
It does work but, the results are substantially worse that the other other method mentioned above. It seems to retract a 'lot more' during printing, and the overall print quality suffers in general. My guess was that it (that 'Include M101...' checkbox) may not be respecting S3D's own slicers settings when it comes to things like 'Only Retract When Crossing Open Spaces', and the side effect is it retracting a lot more often than it should. I decided to diff the two gcode files: Sure enough, the 'bad' one was retracting a lot more than the good one, confirming my suspicions.
Here's a chunk of 'good gocde' (no extraneous retractions)
Code: Select all
G1 X12.541 Y-4.566 E0.0311
G1 X-4.566 Y2.562 F9000
G1 X5.938 Y13.066 E0.6225 F1426Code: Select all
G1 X12.541 Y-4.566 E0.0311
M103
G1 X-4.566 Y2.562 F9000
M101
G1 X5.938 Y13.066 E0.6225 F1426I'm going to go back to the scripted route, just a headsup to the community, and the developers, since this feels like a bug.
