Massive overestimate of print time

[FrnchFrgg]

I tried to use klipper_estimator and every gcode file I gave it resulted in a very overestimated print time.

For instance, this gcode file gcode file was printed in 6h13m (6h18m total time) yet klipper_estimator_linux --config_moonraker_url http://chiron.frnchfrgg.pw estimate file.gcode says:

  Total moves:                 527354
  Total distance:              1495631.625mm
  Total extrude distance:      43868.467mm
  Minimal time:                9h9m25.656s (32965.656s)
  Total print move time:       8h6m27.482s (29187.482s)
  Total extrude-only time:     27m45.877s (1665.877s)
  Total travel time:           35m11.847s (2111.847s)

chiron.frnchfrgg.pw is not accessible from outside my LAN but here is the result of
klipper_estimator_linux --config_moonraker_url http://chiron.frnchfrgg.pw dump-config:

{
  "max_velocity": 300.0,
  "max_acceleration": 1200.0,
  "max_accel_to_decel": 600.0,
  "square_corner_velocity": 5.0,
  "instant_corner_velocity": 1.0,
  "move_checkers": [
    {
      "axis_limiter": {
        "axis": [
          0.0,
          0.0,
          1.0
        ],
        "max_velocity": 20.0,
        "max_accel": 60.0
      }
    },
    {
      "extruder_limiter": {
        "max_velocity": 79.82432411074329,
        "max_accel": 319.29729644297316
      }
    }
  ]
}

These values match the klipper configuration I use. If needed I can attach parts of said klipper configuration.

Note that klipper_estimator should probably give an estimate between 5h50m and 6h instead because I use a timelapse which adds at least 3 seconds per layer, and I did not yet try to add accounting for that.

[dalegaard]

Hi @FrnchFrgg

You are using absolute extrusion but klipper_estimator expects relative extrusion unless told otherwise. You can fix the issue by using relative extrusion or adding M82 in your slicer start gcode. The tool can't see M83 in your print start macro.

Best regards
Lasse

[FrnchFrgg]

I saw a bug where you told that. I checked before I filed this bug and there is an M82 in the gcode file itself.
cat spool-holder_0.2mm_PLA_Chiron_6h21m.gcode | grep M82 returns a line. So klipper_estimator should see it. Note that I also tried to put some M82 in the gcode too and that didn't change the timings.

[dalegaard]

Ah it's after the prime line. I'll take a closer look then

Best regards
Lasse

[dalegaard]

Hi @FrnchFrgg

Your klipper config file or the start of a klippy.log would be useful to help diagnose the issue. Everything looks correct on a test run.

Best regards,
Lasse

[FrnchFrgg]

config.zip

[dalegaard]

Hi @FrnchFrgg

Thanks for reporting. This was caused by the junction deviation not being updated after parsing the config. Since you have no acceleration control(like many users do) there were no commands that ever updated the value and masked the bug.

I've verified with your gcode file, taking out the macros, that Klippy and estimator now agree on the total time (20482.533s).

Best regards,
Lasse

[FrnchFrgg]

Since my acceleration settings in SuperSlicer are the same than the klipper ones I selected "for estimation only". Thanks for the quick fix.