Arc command (G2, G3) sometimes reverses the direction of extruder

Is anyone else experiencing an issue where Arc commands reverse the direction of the extruder? I have a start_print macro setup that looks like this:

[gcode_macro START_PRINT]
gcode:
    {% set BED_TEMP = params.BED_TEMP|default(60)|float %}
    {% set EXTRUDER_TEMP = params.EXTRUDER_TEMP|default(220)|float %}
    # Use absolute coordinates
    G90
    M82
    # Start bed heating
    M140 S{BED_TEMP}
    # Start nozzle heating
    M104 S{EXTRUDER_TEMP}
    # Home the printer
    G28
    # Reset the G-Code Z offset (adjust Z offset if needed)
    #SET_GCODE_OFFSET Z=0
    #Set bed mesh profile
    BED_MESH_PROFILE LOAD=default
    #Wait for bed and nozzle heating
    M190 S{BED_TEMP}
    M109 S{EXTRUDER_TEMP}
    # Move the nozzle near the bed
    G1 X-126 Y0 Z0.4 F3000
    # Extrude about 40 mm by printing a 90 degree arc
    G3 X0 Y-126 I126 E40 F2700
    # Retract and move nozzle up
    G92 E0
    G1 E-1.5 F1800
    G0 Z0.5
    G1 E0 F300

The line that causes the issue is: G3 X0 Y-126 I126 E40 F2700.

Looking at the Klipper documentation it says the I and J parameters go at the end. I changed the line so that it is now: G3 X0 Y-126 E40 F2700 I126 and the issue hasn’t happened since. However, looking at all the arc_welder generated code, it does not follow this format with I and J parameters at the end, and I am afraid this issue is happening during my prints. Anyone else experiencing an issue? Any ideas what is going on? Does the order of parameters really matter?

I cannot much comment on the arc feature as I do not use it. General consent is:

  • arcs do not increase precision, on the contrary, they typically lower the precision
  • main benefit of arcs is the reduced amount of data that needs to be transferred to the MCU. This is not needed when using Klipper and a modern web-interface (or octoprint with the virtual sd-card feature)