Cura, firmware retraction and M207

garyd9

I've decided that I'd like to tinker with hardware retraction. Being that I don't use the duet "filament manager" (and have no intention of doing so), I'd like my slicer (cura) to be able to set up the initial retraction related values via M207 in the startup gcode.

For example, the following in cura's machine startup gcode almost does what I want:

M207 S{retraction_amount} R{retraction_extra_prime_amount} F{retraction_speed} T{retraction_prime_speed}

The only problem here is that the duet's M207 expects the F and T parameters to be specified in mm/min while the cura values are in mm/sec. So, the above gcode actually sends something like "M207 S1.5 R0 F60 T20" instead of "M207 S1.5 R0 F3600 T1200" Obviously, retracting at 60mm/minute is a bit too slow.

Can anyone offer any suggestion on how I can get around this? I remember reading once about the ability to create custom gcode's using macros, but I can't seem to find that reference anymore to see if those macros will accept parameters, allow math to be performed on them, and then have the resulting values passed to normal gcodes.

Thanks
Gary

SIam

I'm not working with cura but have you tried to multiply the F Value with 60 ?

M207 S{retraction_amount} R{retraction_extra_prime_amount} F{retraction_speed*60} T{retraction_prime_speed*60}

garyd9

@SIam said in Cura, Hardware retraction and M207:

I'm not working with cura but have you tried to multiply the F Value with 60 ?
M207 S{retraction_amount} R{retraction_extra_prime_amount} F{retraction_speed*60} T{retraction_prime_speed*60}

That results in the following gcode being generated:

M207 S1.5 R0.0 F*{retraction_speed*60} T*{retraction_prime_speed*60}

garyd9

Here's an irony:

It appears that the RRF object model stores the M207 set retraction/unretract speeds in mm/sec (not mm/min as is set with M207.)

So, if I send "M207 S1.5 R0.0 F3600 T1200", the object model shows a retraction speed of "60" and an unretract speed of "20".

Why does that matter? I was going to write a macro that uses the object model to detect if the M207 parameters were set to mm/sec and if so, multiply the values by 60 and call M207 again. However, that won't work because after sending "M207 S1.5 R0 F60 T20" and then querying the object model, I get the following useless values:

{
    "key": "tools[0].retraction",
    "flags": "",
    "result": {
        "extraRestart": 0,
        "length": 1.5,
        "speed": 1,
        "unretractSpeed": 1,
        "zHop": 0
    }
}

If it matters, I'm using RRF and DSF 3.2. @dc42, can you please comment on this inconsistency? Is it intentional that the values shown in the OM are in a different scale than the values set with M207?

garyd9

@garyd9 said in Cura, firmware retraction and M207:

The only problem here is that the duet's M207 expects the F and T parameters to be specified in mm/min while the cura values are in mm/sec. So, the above gcode actually sends something like "M207 S1.5 R0 F60 T20" instead of "M207 S1.5 R0 F3600 T1200" Obviously, retracting at 60mm/minute is a bit too slow.

Can anyone offer any suggestion on how I can get around this? I remember reading once about the ability to create custom gcode's using macros, but I can't seem to find that reference anymore to see if those macros will accept parameters, allow math to be performed on them, and then have the resulting values passed to normal gcodes.

The macro's won't accept parameters. Along with conditional g-code variables, that's on the RRF todo list.

I guess the inconsistency of M207 parameters being in mm/min, but being retained/reported in mm/sec is intentional.

In the meantime, here's what I've come up with to work around the problem. This should be put in the "start gcode" in cura's machine settings:

;Store the cura values in pseudo-variables (workspace coordinates for a workspace that is never used by me):
G10 L2 P2 X{retraction_amount} Y{retraction_speed} Z{retraction_prime_speed}
M98 P"/macros/SetM207"

Then create a macro called "SetM207" that contains the following:

;use conditional gcode to do the math needed to translate the values into M207 acceptable parameters
M207 S{move.axes[0].workplaceOffsets[1]} R0 F{move.axes[1].workplaceOffsets[1] * 60} T{move.axes[2].workplaceOffsets[1] * 60} Z0

I originally tried to put the M207 line above into the start gcode (instead of using a macro) but doing so resulted in Cura not translating the {retraction_amount} stuff. I'm not sure why.

If needed, the "extra prime amount" could also be stored in a workspace axis offset ( G10 L2 P3 X{retraction_extra_prime_amount}) and then set by replacing "R0" in the macro above with "R{move.axes[0].workplaceOffsets[2]}

Note that I have the Z parameter to M207 set to 0 always. One thing that can't be helped with the current version of cura is z-hop. Cura doesn't seem to consider z-hop to be something firmware retraction is responsible for, so it still emits z-hop commands to the gcode even when firmware retraction is enabled. (I suppose this might be a good thing because Cura gives more control over when z-hop is used instead of just always hopping with any retraction.) Anyway, it works fine if you left cura do the hopping and the Duet to do the retracting.

Phaedrux

That's a clever work around. It'll be exciting to see what people come up with when actual variables are introduced.

@garyd9 said in Cura, firmware retraction and M207:

That results in the following gcode being generated:
M207 S1.5 R0.0 F*{retraction_speed60} T{retraction_prime_speed*60}

I think that might still work but the *60 would need to be outside of the curly bracket otherwise cura won't recognize it as an internal variable.

garyd9

@Phaedrux said in Cura, firmware retraction and M207:

That's a clever work around. It'll be exciting to see what people come up with when actual variables are introduced.

I'm actually afraid of that. I generally slice models once and leave them on my duet's sdcard for all time. (That was one reason for changing my stuff to use firmware retraction.)

Once variables are implemented and working, I'll have to go through and edit all my gcode files and macros to use proper variables instead of crazy hacks. (I can't assume that the hacks will always be supported.)