klipper_estimator — точная оценка времени печати

Встроенная оценка слайсера почти всегда врёт: она считает по своим «лимитам машины», которые
на Klipper-флейворе в g-код не попадают (см. Ускорение в Klipper).
klipper_estimator — утилита на Rust, которая симулирует планировщик движения Klipper по
реальному printer.cfg и даёт секунд-точную оценку, переписывая время прямо в g-коде.

Наблюдаемо: имя файла из Orca ..._2h0m (внутренняя оценка Orca «замораживается» при экспорте)
vs время в заголовке того же файла 1h16m (уже переписано estimator’ом по реальным лимитам).

Два способа подключить

  1. Post-process в слайсере — на экспорте слайсер вызывает
    klipper_estimator ... post-process <файл>, тот переписывает время. Работает с любым Klipper,
    но зависит от доступности источника конфига на каждом экспорте.
  2. Moonraker [analysis] (enable_auto_analysis: true) — Moonraker обрабатывает файл при
    загрузке на принтер. Поддерживаемый преемник (та же функциональность, без сетевой
    завязки экспорта). Компонент появился в Moonraker ~2024 — на старых вендорских форках
    его может не быть
    (нет analysis.py, среди компонентов не грузится). Тогда остаётся только
    способ 1.

Проект архивирован

Репозиторий (Annex-Engineering / dalegaard) архивирован, последний релиз v3.7.3
(апрель 2024) — новее официально не будет. Форки крошечные. Развитие функции — через
Moonraker [analysis].

CLI

Подкоманды: dump-config, estimate, post-process, dump-moves. Источник конфига — глобальный флаг:

# живой конфиг с принтера (перечитывается каждый вызов):
klipper_estimator --config_moonraker_url http://<printer_ip> dump-config > cfg.json
# оффлайн из файла (без сети):
klipper_estimator --config_file cfg.json estimate model.gcode
klipper_estimator --config_file cfg.json post-process model.gcode

Формат конфига (ключи): max_velocity, max_acceleration (не max_accel!),
minimum_cruise_ratio, square_corner_velocity, instant_corner_velocity, mm_per_arc_segment,
move_checkers.

Гоча 1: зависание на move_checkers

С некоторыми конфигами estimate/post-process уходит в бесконечный цикл (5-ходовый файл
не считается и за минуты, хотя без чекеров — мгновенно). Виновник — блок move_checkers
(лимитеры осей Z и экструдера): любой из них вешает, с пустым move_checkers: [] считает сразу.
Похоже на несходимость итеративного солвера (замечено на x86-бинаре под Rosetta; на нативной
машине та же версия сходилась).

Обход: dump-config, затем обнулить move_checkers в JSON и звать через --config_file.
Эти лимиты на практике почти не биндят (лимит экструдера — тысячи мм/с при реальном потоке
единицы; Z-ходы редки), так что точность XY-времени не страдает. Изолировать виновника —
estimate c поочерёдно оставленным одним чекером.

Гоча 2: live-URL — сетевая завязка

--config_moonraker_url тянет конфиг на КАЖДОМ экспорте. Если принтер занят печатью или
выключен — экспорт виснет/деградирует (на слабом SoC даже estimate подвисал во время
печати). Надёжнее — один раз dump-config > cfg.json и звать --config_file. Минус: файл
статичен → пересоздавать при смене velocity/accel в printer.cfg (иначе оценка устареет).

M73 и линейный прогресс-бар

Прогресс по позиции в файле нелинеен (быстро на редких слоях, медленно на плотных). M73 —
это прогресс по времени, и он линеен. Гоча: klipper_estimator только переписывает уже
существующие M73, не вставляет их
(issue #69). Значит:

  • слайсер должен эмитить M73 (в Orca — машинная настройка disable_m73 = 0);
  • estimator их уточнит до Klipper-точных;
  • UI должен брать прогресс/ETA из слайсера/M73, а не из позиции файла (в Fluidd —
    printProgressCalculation / printEtaCalculation = ["slicer"], см.
    Fluidd — настройки в БД Moonraker).

Механика прошивки — Klipper; что вообще влияет на печать —
Настройка параметров печати 3д модели.

Источники

  • github.com/Annex-Engineering/klipper_estimator (архив, v3.7.3), issue #69 (M73)
  • Moonraker docs: компонент [analysis], enable_auto_analysis