Troubleshooting и тюнинг#

То, что кусает при работе Sovol Zero на mainline Klipper, и как это разгрести. Только факты и фиксы — полные процедуры живут на страницах слоёв.

Прошивка и CAN#

canbus_query / flashtool.py -q показывает 0 нод#

Если Klipper остановлен, запрос, возвращающий Total 0 uuids, — это нормально: эти инструменты перечисляют только неинициализированные / bootloader-ноды, а сконфигурированная в Klipper app-нода не отвечает. Читай это как «всё крутит своё приложение», а не «шина мертва». Запусти Klipper (или переведи ноду в её bootloader), чтобы увидеть её в запросе.

Перепрошивка тулхеда по CAN падает с Error sending command [CONNECT]#

Katapult тулхеда должен быть собран для CAN-обмена. Если он собран (или задефолчен через olddefconfig) под USB, он входит в bootloader, но молчит на шине. Собери F103 Katapult CANSERIAL (засей .config из заведомо рабочего CAN-конфига, а не с голого сида). CAN-совместимый Katapult тулхеда означает, что будущие обновления приложения шьются по CAN — вскрывать голову снова не нужно.

Смена версии Klipper: прошивай все три, а не только хост#

Eddy tap (и другие фичи, добавляющие команды на стороне MCU) требуют, чтобы хост и оба приложения MCU были на одном коммите Klipper. Перевод на master только хоста, пока MCU остаются на теге, падает на старте с чем-то вроде mcu 'extruder_mcu': Unknown command: trigger_analog_query_state. Пересобери и прошей приложение для хоста, F103 и мейнборда (собранного как STM32H743 — смотри Сборку прошивки) из одного коммита. С CAN-совместимым Katapult тулхеда это больше не значит вскрывать голову — F103 по CAN, мейнборд по USB-Katapult.

Не доверяй офсету из .config на диске#

Вендорские .config103 / .config750 заявляют FLASH_APPLICATION_ADDRESS=0x8000000, что устарело — приложение на самом деле живёт по 0x8002000 (F103) / 0x8020000 (мейнборд). Читай реальный офсет из живого bootloader (Katapult CONNECT сообщает Application Start) и гейти каждую прошивку на reset-векторе собранного .bin перед записью. Смотри Миграцию MCU и Сборку прошивки.

Eddy-проба (LDC1612)#

START_NACK на первом пробинге / хоминг-движении#

Здесь складываются две причины:

  1. Mainline на этой плате нужен software I2C — вендорских обходов errata аппаратного I2C у STM32F1 в mainline нет, так что аппаратный i2c2 кидает START_NACK. Используй i2c_software_scl_pin / i2c_software_sda_pin на extruder_mcu:PB10 / PB11.
  2. Потревожен FFC. Разъём eddy на заводе термофиксирован; разборка головы ломает фиксацию, и слегка перекрученный шлейф даёт тот же NACK. Переусади FFC (и заново закрепи его горячим клеем снаружи контактов, а не переплавляя фиксацию).

probe_eddy_current sensor not in valid range после нескольких soft-рестартов#

Датчик на software I2C может уйти в плохое состояние за серию soft-рестартов Klipper — soft-рестарт его не переинициализирует, а полное передёргивание питания — да. Передёрни питание принтера, а не гоняйся за позицией Z; не замазывай это через SET_KINEMATIC_POSITION (это просто уводит кинематический Z куда-то не туда).

Опции eddy отвергнуты (“not valid in section”)#

Ты на теге v0.13.0, а не на master. descend_z и max_sensor_hz — ключи tap-эры, которые существуют только на master; на теге tap нет и вместо них требуется z_offset. Это одна из причин, по которой гайд собирает из master — если ты всё же запинил тег, приведи конфиг eddy под него (смотри Конфиг Klipper).

Хоминг гонит стол вниз и грайндит Z-ремень#

Отрепорченный триггер: если стол оставили опущенным при выключении, G28 не достаёт до высоты eddy-скана с первого прохода и шагает столом вниз ~5 мм за попытку, грайндя Z-ремень (экран-крутилка показывает 104/113). Сначала прогони LDC_CALIBRATE_DRIVE_CURRENT — он пишет reg_drive_current и хомит из известного состояния.

Ошибка eddy-хоминга из-за сдвинутого FFC#

Error during homing z: Eddy current sensor error (экран «TIP 123») обычно значит, что FFC eddy сидит криво — заводской жёлтый клей позволяет ему сдвинуться после вскрытия головы. Пересади разъём.

Input shaping и акселерометр#

Резонанс-тест → MCU 'mcu' shutdown: Timer too close#

Хост Allwinner H616 не тянет диагональный TEST_RESONANCES на полной частоте, пока стримит камера. Два фикса, нужны оба: systemctl stop crowsnest на время теста и HZ_PER_SEC=2 (потолок в конфиге — 2.0). После перезапусти crowsnest.

Трассы акселерометра выглядят шумными#

Шумные резонанс-трассы у вендора идут от двух вещей, обе починены на mainline: старое однокадровое чтение LIS2DW (чанкованное FIFO-чтение bulk_sensor на mainline чистое) и жёстко запиненное узкое окно [resonance_tester] min_freq: 35 / max_freq: 45, которое навязывает липовый результат ~40 Гц. На mainline с широким окном MEASURE_AXES_NOISE сидит на однозначных мм/с² на ось, и всплывает реальный резонанс (часто ~55–65 Гц на этой раме).

Прежде чем винить датчик в шуме на одной оси: мёртвый LIS2DW сыпет по всем осям или NACK-ает, так что шум на одной оси указывает скорее на механику/проводку/драйвер. Различающий тест — MEASURE_AXES_NOISE с запитанными моторами против того же после M84: если с выключенными моторами шум падает, это standstill-вибрация чоппера TMC, которую датчик честно измеряет, а не сам датчик.

Ускорение печати против ускорения резонанс-теста#

[printer] max_accel в десятках тысяч — это потолок резонанс-теста, а не печатное значение. После SHAPER_CALIBRATE выставь max_accel в связывающий пер-осевой рекомендованный лимит (часто это ось с шейпером ei, около ~6000–6500) ради чистой геометрии, и держи ускорения стенок в слайсере на нём или ниже.

Вентиляторы#

fan3 / PE14 ничего не крутит#

Вендорский конфиг тащит [fan_generic fan3] pin: PE14 для вентилятора обдува платы, который выпилили / не распаяли в продакшен-релизе. Он ничего не крутит и только захламляет UI — удали секцию.

RPM вентилятора хотэнда читается примерно вдвое больше#

Вентилятор хотэнда (heatbreak) выдаёт 2 импульса на оборот, так что [heater_fan hotend_fan], настроенный с tachometer_ppr: 1, заставляет Klipper показывать примерно вдвое больше реального RPM — неправдоподобные ~16000+ для мелкого вентилятора. Выставь tachometer_ppr: 2, и он покажет истинные ~7800–8400. Вентилятор в порядке; удвоилось только показание. (И наоборот, тахо-вентилятор, который читается примерно вдвое меньше ожидаемого, — обратный случай: этот и правда 1-ppr.)

Хост / ОС#

Проверка готовности: спрашивай API, а не лог#

Свежий Klipper больше не выдаёт старые строки лога Stats / Klipper state: Ready, так что греп лога на готовность делает готовый принтер похожим на зависший. Спрашивай Moonraker /printer/info (или сокет klippy {"id":1,"method":"info"}) → state: ready.

apt update падает на bullseye-backports#

Suite bullseye-backports убрали с зеркал (404). Закомментируй активную строку backports в /etc/apt/sources.list (сохрани бэкап) перед любой установкой через apt. Оставайся в пределах bullseye — dist-upgrade bullseye→bookworm двигает Python 3.9→3.11 и ломает venv-ы Klipper/Moonraker, без восстановления живого rootfs, если только ты не можешь перепрошить eMMC вне полосы (смотри страницу Armbian).

Ветки ядра Armbian и встроенный Ethernet#

Встроенный Ethernet (внутрикорпусной AC300 EPHY на втором EMAC) сейчас работает из коробки только на ядре 6.12.68 из Armbian 26.2.1 — поэтому установка с чистого листа держит пакеты ядра на hold. Более новые ветки ломают его способами, которые все продиагностированы и уже пофикшены upstream — все четыре фикса вмёржены в main armbian/build (помечены на релиз Q3 2026), просто ещё не в stable-релизе. Ничего из этого не кусает, пока hold на месте:

  • 6.18 stable (26.5.1): интерфейса ethernet нет вообще — стек BSP-драйверов выпилили до того, как подключили mainline-путь. Отрепорчено в armbian/build#10084, dts-фикс в armbian/build#10155.
  • 6.18 nightly / 7.1 edge: гонка при probe — встроенный PHY-драйвер ac300 откладывается на модульном провайдере тактов pwm-sunxi-enhance, и generic PHY-драйвер первым хватает обесточенный EPHY (залипает до ребута; сигнатура: PHY [...] driver [Generic PHY] переподключается каждые ~6 с, линк флапает, RX стоит на 0, пока TX считает). Попадёт ли конкретная плата — чистый тайминг загрузки, проверено в обе стороны на двух платах. Фикс: armbian/build#10242; локальный обход: ранняя загрузка pwm_sunxi_enhance через /etc/modules-load.d/ + /etc/initramfs-tools/modules.
  • Ещё две dts-проблемы CB1, найденные по пути, относящиеся к встроенному радио: тактовый сигнал pwrseq у wifi назван так, что 32 kHz LPO никогда не включается (armbian/build#10240), а линии питания/пробуждения wifi выставлены как gpio-LED, которые armbian-led-state пульсирует посреди инициализации SDIO (armbian/build#10241).

Сними hold, как только выйдет stable-релиз Q3 2026; до тех пор трактуй «нет сети после apt full-upgrade» как это, а не как сломанное железо. Страница обновляемой ОС отслеживает путь с hold.

pip загрузки с платы виснут навсегда#

Большие загрузки с CDN PyPI могут виснуть с сетевой позиции принтера: pip сидит на мёртвом соединении (ss показывает CLOSE-WAIT с непрочитанными байтами) с нулевым прогрессом, тогда как apt и GitHub работают нормально. Пиннинг другого edge CDN в /etc/hosts не помогает. Не борись с этим — скачай колёса на другой машине (pip download <pkg> --only-binary=:all: --platform manylinux2014_aarch64 --python-version 3.13 --implementation cp), закинь их через scp и pip install --no-index *.whl.

Obico стримит на 0.1 FPS#

moonraker-obico падает до снапшот-стриминга на 0.1 FPS, когда не может запустить свой встроенный Janus — а на этой плате из коробки он не может никогда. find_precompiled_dir() строит имя precompiled-варианта из board_id(), который возвращает NA на всём, что не Raspberry Pi и не плата MKS, так что резолвер ищет NA.debian.<ver>.64-bit; fallback-regex требует тот же префикс платы, так что встроенные сборки rpi.*/mks.* даже не рассматриваются. Аппаратный h264-энкодер на самом деле НЕ нужен для рабочего стрима: как только Janus запущен, агент отдаёт MJPEG по WebRTC data-каналу на реальной частоте кадров камеры.

Обход (пока upstream-резолвер не принимает сборки для чужих плат): выстави aarch64-сборку MKS под именем, которое ждёт резолвер, и дай ей две библиотеки OpenSSL 1.1, которых ей не хватает на текущем Debian:

cd ~/moonraker-obico/moonraker_obico/bin/janus/precomplied
ln -s mks.debian.10.64-bit "NA.debian.$(. /etc/os-release; echo $VERSION_ID).64-bit"
# fetch the libssl1.1 arm64 .deb from the Debian archive, dpkg-deb -x it, and copy
# libssl.so.1.1 + libcrypto.so.1.1 into mks.debian.10.64-bit/lib/
# (ldd bin/janus | grep "not found" confirms these are the only two gaps)

Проверь: под агентом появляется процесс janus, а предупреждение «Webcam is now streaming in 0.1FPS» перестаёт светиться в логе. Оба добавленных файла не отслеживаются в чекауте moonraker-obico — они переживают git pull, но не hard reset; перепроверь их после крупного обновления агента.

Moonraker: “Failed to load extension crowsnest” + каскад “Unparsed config option”#

Две подставы в одной. Первая: широко скопированный легаси-сниппет [update_manager crowsnest] указывает на install_script: tools/pkglist.sh, которого в crowsnest v5 больше нет (он переехал на раскладку venv + requirements.txt + system-dependencies.json) — а несуществующий путь install_script роняет загрузку всей секции. Вторая: последующие предупреждения “Unparsed config option ‘origin: …’” / “‘managed_services: …’” на других строках секции — симптом этого одного сбоя, а не отдельные проблемы, не гоняйся за ними по отдельности.

Фикс: возьми сниппет из самого установленного чекаута — ~/crowsnest/resources/moonraker_update.txt — дословно, и перезапусти Moonraker. То же правило обобщается: добавляя любой компонент в [update_manager], предпочитай moonraker_update.txt (или эквивалент), поставляемый внутри репозитория этого компонента, сниппетам из доков или из памяти; раскладки дрейфуют, а поставляемый файл соответствует коду, который у тебя реально есть.