optimize gcode for retraction tuning about teachingtechyt.github.io

[bitfabrikken]

I agree. Even two layers for the base would be enough for me.

Also a bit worried that you can't input flow - in my case, I had a flow of 0.9 / 90% from the previous calibration step, and that won't be taken into account when calibrating the retraction.

[unnameduser2]

and now I also noticed that the gcode is using z lifting (by 0.2 on right tower/0.4mm on left tower) for retraction:
; layer 19, Z = 3.800
; feature inner perimeter
G1 Z4.000 F1200
G1 X135.202 Y111.994 F6000
G1 Z3.800 F1200
.
.
; feature inner perimeter
G1 Z4.200 F1200
G1 X90.798 Y111.994 F6000
G1 Z3.800 F1200
.
.
; layer 20, Z = 4.000
; feature inner perimeter
G1 Z4.200 F1200
G1 X90.798 Y111.994 F6000
G1 Z4.000 F1200

So z axis lifting could be used as separate test parameter (and probably should be set to 0 by default)

[bitfabrikken]

I concur @unnameduser2 - I did the retraction calibration earlier, and it came out perfect. But when I went back to my slicer and input those values (without z-hop), it was back to stringing. Am currently printing PETG, where I've heard that z-hop is a bad idea.

[firestrife23]

I concur @unnameduser2 - I did the retraction calibration earlier, and it came out perfect. But when I went back to my slicer and input those values (without z-hop), it was back to stringing. Am currently printing PETG, where I've heard that z-hop is a bad idea.

Same here, I'm surprise to see Z-hop fixed my stringing issues too.

[teachingtechYT]

Z hop is now removed, and will be made a user set feature shortly.
I agree it would make the print more efficient to have a thinner base, but a lot of manual changes have been made to the source gcode now which would make reslicing and preparing very laborious.