Bug in Duet 0.8.5 firmware 1.23 with G10: Retract


  • administrators

    The behaviour of G10 was changed several firmware versions ago because a user needed to be able to use G10 to set the temperatures for the current tool without knowing the tool number. So now G10 with a P or S or R parameter sets temperatures and/or offsets, and G10 with none of those parameters is a retraction command.

    I've not heard before of S1 being used to choose between 2 different retraction lengths. I think it must be a recent addition.

    Are you sure that the G10 S1 command isn't in a tool change script that can be edited?



  • 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.


  • administrators

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



  • @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?



  • 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.




  • administrators

    @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.



  • Understood, thanks @dc42.



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



  • Submitted Bug Report to Cura.

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




Log in to reply