Firmware Retraction

dc42

The retraction and Z-hop are done simultaneously. Similarly for the un-retract. The Z speed will be adjusted so that the Z hop takes the same time as the retract.

kraegar

Gotcha, that's exactly what I was looking for. Thanks David!

dc42

btw someone else has asked for the retract and hop to be done separately.

kraegar

It's an odd thing, for sure. All the slicers do it differently, and I go back and forth on the "best" way to do it.

A lot of it has to do with your filament, backpressure, speed you can retract & z-hop at, etc. Not sure what the "best" is, or even if there really is a "best" way that works in all cases.

kraegar

I think it would be interesting to have two speeds you could configure… one for retract speed, and one for zhop speed.

So, say G1 E-3 F3600; G1 Z2 F6000 and have them run at the same time, so as soon as the lift starts the retraction runs. Their speeds occur independently.

I'm not sure if RRF can handle a case like that, but if so it would be a real advantage, and I think it'd cut down on stringing if you're doing a bigger z-hop.

Most slicers do the retract, then the zhop (see here: https://pastebin.com/zhuJGVR1 ) and all of them of course do it in two steps. So if you have a long retract your nozzle can sit on the print for a bit. (or in the case of slic3r, it does the hop and then the retraction)

(That link was specific to layer changes, but most of it still applies)

adavidm

That's along the lines I was thinking in a reprap.org forum post a few days ago. Specifically I was trying to compare how Smoothieware firmware retract works compared to RRF.

Smoothie uses a Q parameter to set the zhop feedrate, defaulted to 6000mm/min. The order is, I think:

[[language]]
G10 -> Perform retract -> Perform zhop at Qmm/min(default 6000) -> Travel -> G11

RRF uses a feedrate that ensures the lift completes at the same time as the retract, as David says above. This can lead to some very slow zhop movements (144mm/m based on 0.2mm lift, 5mm retract at 60mm/s). The order is:

[[language]]
G10 -> Calculate feedrate based on retract params -> Perform retract and zhop together -> Travel ->G11

You can see how zlift feedrate is affected by playing with the parameters in this spreadsheet:
https://docs.google.com/spreadsheets/d/1UcQYFa4AETvtIABqo0rkbtBlvGnCniSLq_P8JxoRxJc/edit#gid=0

(Please note, DC42 hasn't verified that data, It's just my interpretation of the source code.)

Regards

David

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.