Firmware Retraction

kraegar

You're spot on to my observations.

I really prefer firmware retractions, it gives me a lot more flexibility and control during a print, as well as the separate un-retract speed. With the way RRF currently works, to keep down stringing it works best to use a very low z-hop. 0.3mm seems to be the ideal limit with a 60mm/s retraction.

dc42

I've written the code to do the retraction first and then the z-hop, and to undo retraction in the opposite order. Currently I have the Z hop set to happen at the maximum Z speed set by M203. I could add a Z hop speed parameter, but z-hop is generally small, so I think it will normally be acceleration-limited rather than speed-limited.

kraegar

Is it possible to do them at the same time, but with individually definable speeds? If not, I agree on your need approach. Though I should see what my max speed is even set to.

adavidm

@dc42:

I've written the code to do the retraction first and then the z-hop, and to undo retraction in the opposite order. Currently I have the Z hop set to happen at the maximum Z speed set by M203. I could add a Z hop speed parameter, but z-hop is generally small, so I think it will normally be acceleration-limited rather than speed-limited.

One of the tricks I remember from using Marlin/Repetier was to set the retract rate and zhop rate way above the maximum rates that the firmware would allow for the motors. The speed of retracts would then remain constant regardless of the speed multiplier in use.

Is this still relevant today or are retracts/unretracts immune to speed multiplier settings?

David

dc42

All moves are limited by the configured maximum speeds and accelerations regardless of the speed multiplier. Firmware retraction moves are not affected by the speed multiplier.

Guyaros

Hi all,

I have a question in regards to Firmware retraction usage.

I know I need to configure Firmware retraction by using the command:
M207 S4.0 F2400 Z0.075
that enables and configure retraction and unretraction using G10 and G11 commands.

Now for the GCODE point of view, does the GCODe file must contain G10 and G11 commands instead of G1 E-XX FXXXX commands
or that the firmware auto replaces the G1 E-XX commands with the configuration that was set in the M207 command.
(I don't think this is the case, but I am not sure)

In case I do need to replace the G1 E-xx command with G10/G11 in the GCODE file, as far as I know, I need to use Post script that replaces the G1 E-XX commands with G10, because there is no support for firmware retractions in Silmpify3d.

2. In case I am using firmware retraction, is there an option to configure Nozzle wipe? or that's only available while using "slicer retractions"

Thanks,

dc42

In S3D you can get firmware retraction by disabling S3D's retraction and enabling "Include M101/102/102 commands". RRF will recognise those commands as an alternative to G10/G11.

Guyaros

Thanks for your kindly support.

paboman

@dc42
Do I need to have the Retraction check box (Ooze control in S3D) activated in order to have M102 etc commands in the Gcode?
In other post I read that Retraction need to be ON but all values need to be set to ZERO

dc42

@paboman said in Firmware Retraction:

@dc42
Do I need to have the Retraction check box (Ooze control in S3D) activated in order to have M102 etc commands in the Gcode?
In other post I read that Retraction need to be ON but all values need to be set to ZERO

No, but you need to have the box labelled "Generate M101/M102" instructions (sorry, I can't remember the exact term) checked.

However, it has turned out that using this option doesn't work quite right. So the best answer is don't use S3D until they have added proper support for firmware refraction. It's the only major slicer that doesn't have this support.