Bug in Duet 0.8.5 firmware 1.23 with G10: Retract

PDBeal

I don't have any tool change things defined in Cura. I had to stop Cura from trying to control the heaters too as it's dual extrusion expects two heaters from what I've seen. In my case, I don't even have anything in tfree0, tpre0, tpost0 either because I don't need it. And I just adjust my start code for my desired temperatures.

From what I suspect, based on the RepRap Wiki for G10 S1, Repetier has something implemented for a long retract probably to support one of those promethius setups with 1 hotend and 2 filaments with the filament switch happening above the cold zone of the hotend. I'm also guessing Cura has implemented this G10 S1 for those types of cases also with it only using G10 S1 on Tool change locations.

dc42

Perhaps @burtgoogle can change Cura so that it doesn't generate the S parameter when the GCode flavour is RepRapFirmware?

burtoogle

@dc42 said in Bug in Duet 0.8.5 firmware 1.23 with G10: Retract:

Perhaps @burtgoogle can change Cura so that it doesn't generate the S parameter when the GCode flavour is RepRapFirmware?

My ears are burning.

Looking at the Cura code, it currently does this:

        *output_stream << "G10";
        if (extruder_switch)
        {
            *output_stream << " S1";
        }

And what you want is more like this: ?

        *output_stream << "G10";
        if (extruder_switch && flavor != EGCodeFlavor::REPRAP)
        {
            *output_stream << " S1";
        }

I understand why you want to remove the S1 but, surely, it's not ideal to have G10 so overloaded. How did that happen?

burtoogle

BTW, the Cura developers have pretty much stopped processing PRs on the Cura slicer. I have quite a backlog of PRs that they are simply ignoring. It's not personal (I think) because they don't appear to be processing any PRs unless they provide some kind of sexy feature (like gyroid infill) which they grabbed with (relatively) indecent haste.

burtoogle

See https://github.com/Ultimaker/CuraEngine/pull/972

I will incorporate this into my next Cura release which you can find at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

smartavionics opened this pull request in Ultimaker/CuraEngine

closed Bug Fix - Only add S1 param to G10 when generating repetier flavour gcode. #972

dc42

@burtoogle said in Bug in Duet 0.8.5 firmware 1.23 with G10: Retract:

I understand why you want to remove the S1 but, surely, it's not ideal to have G10 so overloaded. How did that happen?

I think it started when someone developing some 3D printer firmware (Marlin?) appropriated G10 for firmware retraction, ignoring the fact that G10 had been used for many years by the CNC community for coordinate setting functions (it's in the NIST GCode standard). It didn't help that the early developers of RepRapFirmware independently added temperature-setting functions to G10, although that didn't clash with NIST.

I have been considering moving the temperature-setting functions (and possibly also the tool offset functions) away from G10 to a completely new M-code, perhaps maintaining a backwards-compatibility option for several firmware versions to give users a chance to update DWC and PanelDueFirmware. The M104/M109 temperature setting functions are not flexible enough to fully handle RepRapFirmware's versatile tool and heater management, but perhaps M104 could be extended.

burtoogle

Understood, thanks @dc42.

PDBeal

Apparently, in Cura 4.0.0, for RepRapFirmware, it still generated G10 S1.

PDBeal

Submitted Bug Report to Cura.

https://github.com/Ultimaker/Cura/issues/5881

PDBeal created this issue in Ultimaker/Cura

closed [3.6-4.0] G10: Retract Issue with RepRap machine selection #5881

burtoogle

See https://github.com/Ultimaker/CuraEngine/commit/00bc58391afd6b94b4112d3492d5bd8adba013a5

0

smartavionics committed to Ultimaker/CuraEngine

Only add S1 param to G10 when generating repetier flavour gcode.

The other firmwares can interpret the S1 differently so don't let them see it.