Possible Firmware retract bug?

3D_low

I don't know if the issue is on the board side or if it has to be corrected by S3D...

Here is a section of my startup gCode file

[...]
G1 Y80.0 F3000.0 ;wipe nozzle quickly
G92 E0
G10
G1 Z0.200 F1002
; process Process1
; layer 1, Z = 0.200
T0
; tool H0.200 W0.400
; skirt
G1 X105.746 Y113.922 F6600
G1 E1.0000 F1800
[...]

Here is my M207 at the start...

M207 S0.5 F1800 T1200 Z0.5

I'm using the script to change the retraction in s3d to the firmware retraction. The problem is, the first G10 is called but the G11 is not before the skirt is started... so the skirt is done at 0.7 (Z0.2 + 0.5 retract z hop). I guess S3D should correct this or is there a way to bypass?

dc42

Someone else pointed out that the M10x commands generated by S3D are not quite right to use as firmware retraction commands. His solution was to configure S3D for normal retraction and add a post processing script that replaces the resulting G1 E commands by G10 and G11 commands.

S3D is being very tardy in implementing firmware retraction properly. You might want to try slic3r or Cura instead, they have improved dramatically over the last couple of years while S3D seems to be stuck in a rut.

deckingman

I did some work on it back in 2016 - thread is here https://forum.duet3d.com/topic/389/setting-firmware-retraction-with-simplify3d-slicer

Things may have changed since then - for sure RepRap firmware has but you might find something useful in that thread. For various other reasons, I gave up on S3D and got my hard earned refunded shortly after that.

3D_low

@dc42

It's exactly what i'm doing. I'm not using the M10 but the post processing script.

There is no way to get rid of that retraction before starting the part it seems... I tried to remove the priming with no success.. I'll give other slicers a try

MSquared

@3d_low I would recommend KISSlicer, it has a bit of a learning curve but @mhackney has some wonderful videos on it. I also wrote a script in both node.js and .NET Core to post process files from KISS and use firmware retraction; works like a charm.

dc42

Looks like the G1 E1.0000 F1800 command should be converted to G11.

3D_low

yeah i just noticed that they changed the pre-part retraction.

Concerning the firmware side of thing i guess the retraction Z hop is just applied like a M290 command?

dc42

@3d_low said in Possible Firmware retract bug?:

yeah i just noticed that they changed the pre-part retraction.

Concerning the firmware side of thing i guess the retraction Z hop is just applied like a M290 command?

The Z hop is applied when you send G10 and undone when you send G11.

G10 commands do not nest, so if you send more than one then the second and subsequent ones will be ignored. Similarly, G11 will be ignored unless there is an outstanding G10 that hasn't been undone yet.