Перейти к основному содержанию

Системные, связанные с производительностью и ошибки служб

На этой странице собраны вопросы, связанные с тайм-аутами связи при хоминге, ошибками таймера MCU, производительностью上位机, прошивкой и запуском службы Klipper.

Проблема тайм-аута хоминга​

Сообщение об ошибке: Во время хоминга появляется Communication timeout during homing, Error during homing xxx. Часто встречается в сценариях хоминга по оси Z с несколькими MCU.

Распространенные причины:

  • Высокая нагрузка на上位机, одновременная работа KlipperScreen, видеопотоков камер и т. д.
  • Во время хоминга несколько осей двигаются одновременно, сигналы больших токов связи наводятся на линии CAN/USB, что приводит к прерыванию связи.
  • Нестабильный отклик связи нескольких MCU.
  • Плохое качество или неправильная прокладка линий связи CAN/USB.

Методы решения:

Отключение питания

Перед повторной прокладкой линий CAN/USB, проверкой экранирования или заземления полностью выключите принтер и отключите блок питания. Не изменяйте самостоятельно заземление питания, проводку электросети или внутреннюю структуру блока питания.

  1. Сначала исключите электромагнитные помехи: проверьте, отделены ли линии CAN/USB от проводов двигателей и нагревателей, обратитесь к шагам по поиску помех в Конфигурация сети CAN и поиск ID.
  2. Попробуйте изменить параметр тайм-аута TRSYNC_TIMEOUT или временно отключить KlipperScreen, подробнее см. в Проблема тайм-аута хоминга.
  3. Проверьте корректность заземления машины и экранирования.

MCU 'mcu' shutdown: Stepper too far in past​

Сообщение об ошибке: Запланированные Klipper'ом события шагового двигателя для MCU отстали от текущего времени, MCU не может выполнить эти команды движения в ожидаемое время, принтер переходит в состояние shutdown.

Loading...

Причина ошибки: Обычно это вызвано не какой-то фиксированной настройкой, а результатом того, что планирование движения на стороне хоста, вывод шаговых импульсов MCU или планирование связи не успевают обработать данные. Высокая нагрузка на上位机, слишком высокая скорость/ускорение печати, слишком высокое микрошаговое разрешение, задержки связи с несколькими MCU, плохое качество связи USB/CAN, генерация большого количества команд движения за короткое время макросами или G-code — все это может вызвать данную проблему.

Пример сценария: При выполнении многоточечного сканирования кровати, если значение probe_count в [bed_mesh] установлено слишком большим, и при этом задано высокое mesh_pps, может генерироваться слишком плотная сетка данных, увеличивающая нагрузку на вычисления и планирование движения на上位机. Это лишь один из распространенных сценариев; даже без сканирования кровати другие ситуации, приводящие к повышению нагрузки на систему или задержкам связи, могут вызвать Stepper too far in past.

Сценарий зависания после возобновления печати: Ошибка также может появиться после PAUSE / RESUME, восстановления после обрыва нити или продолжения печати после сбоя питания. Типичные записи в журнале: после возобновления значение buffer_time в строке Stats резко падает с ~1s до ~0.2s, sd_pos почти перестает расти (прогресс печати останавливается), но sysload не высокий и отключения MCU нет. Это указывает на то, что буфер шаговых импульсов не пополняется командами движения после возобновления, принтер "начал печать, но почти не двигается" и переходит в shutdown. При поиске причин особое внимание уделите проверке того, не отправляют ли макросы возобновления/продолжения (resume_gcode, start_gcode) аномально большие перемещения или команды ретракта в момент возобновления, а также не было ли повторных передач данных (bytes_retransmit) до возобновления.

Методы решения:

  1. Сначала просмотрите строку Stats перед ошибкой в klippy.log, чтобы подтвердить наличие одновременно высокого использования CPU, bytes_retransmit, bytes_invalid, Timer too close, отключения MCU или аномалий в очереди.
  2. Временно отключите видеопотоки камер, KlipperScreen, плагины удаленного управления и другие службы с высоким потреблением ресурсов, чтобы снизить нагрузку на上位机, и повторите тест.
  3. Снизьте скорость печати, ускорение и микрошаговое разрешение, проверьте, исчезнет ли ошибка.
  4. Если ошибка возникает при многоточечном сканировании кровати, уменьшите probe_count в [bed_mesh], например, до 7,7 или 9,9 для теста.
  5. Если задано высокое mesh_pps, уменьшите его или удалите эту настройку, например, установите mesh_pps: 2,2.
  6. Проверьте качество связи USB/CAN; при использовании CAN убедитесь в корректности длины очереди, терминальных резисторов, порядка проводов, питания и скорости CAN прошивки.
  7. Проверьте макросы или G-code, выполняемые перед ошибкой, чтобы избежать циклов в макросах, слишком плотных коротких сегментов или аномальных скриптов, отправляющих большое количество команд движения за короткое время.

Ссылки на соответствующую конфигурацию: Введение в макросы, Часто используемые команды отладки.

MCU 'mcu' shutdown: Timer too close​

Сообщение об ошибке: Таймер MCU слишком близок, что привело к тайм-ауту системы.

Loading...

Причина ошибки: Слишком высокая нагрузка на обработку на нижнем уровне (MCU), тайм-аут отклика上位机, слишком высокая скорость печати, слишком высокое микрошаговое разрешение, помехи синхронизации системного времени или помехи на линиях связи MCU могут вызвать данную проблему.

Недавние распространенные сценарии:

  • После ожидания в течение некоторого времени в M600, PAUSE, RESUME, макросах обнаружения обрыва нити или смены материала и последующего возобновления печати возникает Timer too close.
  • При участии EDDY / TAP / CAN-платы инструмента в Z-хоминге, Z_TILT_ADJUST, QUAD_GANTRY_LEVEL или сканировании кровати в журнале одновременно появляются повторные передачи по CAN, аномальные показания I2C или пики нагрузки на上位机.
  • При одновременной работе нескольких инструментальных головок, нескольких узлов CAN или低производительного上位机 с камерой, KlipperScreen, плагинами удаленного управления запас по планированию недостаточен.

Методы решения:

  1. Уменьшите микрошаговое разрешение шаговых двигателей, чтобы снизить нагрузку на обработку импульсов MCU.
  2. Снизьте скорость и ускорение печати, проверьте, исчезает ли проблема.
  3. Проверьте нагрузку на上位机, питание и качество связи USB/CAN.
  4. После отключения питания проверьте, не проходят ли линии связи между MCU и上位机 рядом с проводами двигателей, нагревателей, стола или питания; при необходимости проложите их заново или замените на экранированные линии связи.
  5. При проверке заземления машины убедитесь только в состоянии заземляющей точки, предоставленной производителем, и розетки; не разбирайте блок питания и не изменяйте заземление электросети самостоятельно.
  6. Если проблема возникает на этапе хоминга, обратитесь к разделу Проблема тайм-аута хоминга.
  7. Если проблема возникает после M600 или восстановления после обрыва нити, проверьте, нет ли повторного PAUSE в макросе, не срабатывает ли датчик обрыва нити ложно во время смены материала, а также совпадают ли имена SAVE_GCODE_STATE / RESTORE_GCODE_STATE.
  8. Если проблема возникает при EDDY TAP, Z-наклоне или выравнивании портала, сначала обратитесь к Методы отладки режима EDDY TAP или следуйте разделу Сборник проблем EDDY.
  9. Если проблема сохраняется, рассмотрите возможность перепрошивки системы上位机 или прошивки.

Ссылки на соответствующую конфигурацию: Часто используемые команды отладки, Руководство по хомингу и калибровке направлений.

MCU shutdown: Missed scheduling of next digital out event​

Сообщение об ошибке: MCU 'xxx' shutdown: Missed scheduling of next digital out event.

Причина ошибки: После включения хостовой частью Klipper цифровых выходов, таких как нагреватели, вентиляторы, MCU должен своевременно получать последующие планирование и подтверждение. Если нагрузка на上位机 слишком высока, задержка планирования системы, нестабильная связь USB/CAN или аномальная очередь шины CAN, MCU не получает вовремя следующее событие цифрового выхода и переходит в состояние shutdown.

Внимание

Эта ошибка связана с планированием выходов нагревателей. Не пытайтесь обойти ошибку, отключая защиту по температуре, отключая verify_heater или удаляя конфигурации безопасности. Сначала проверьте нагрузку на上位机 и качество связи.

Методы решения:

  1. Сначала просмотрите строку Stats перед этой ошибкой в klippy.log, чтобы подтвердить наличие одновременно bytes_retransmit, bytes_invalid, Timer too close или записей об отключении MCU.
  2. Снизьте нагрузку на上位机, временно отключите видеопотоки камер, KlipperScreen, плагины удаленного управления или другие службы с высоким потреблением ресурсов.
  3. Проверьте качество связи USB/CAN; при использовании CAN убедитесь в корректности длины очереди CAN0, терминальных резисторов, порядка проводов, питания и скорости CAN прошивки.
  4. Снизьте скорость печати, ускорение и микрошаговое разрешение, проверьте, исчезает ли проблема.
  5. Если ошибка появляется только при нагреве, одновременно проверьте нагрузку на стол, хотэнд, вентиляторы и блок питания; не разбирайте блок питания и не проверяйте высоковольтную проводку стола самостоятельно.
  6. Если проблема возникает на CAN-плате инструмента, следуйте разделу Поиск ошибок CAN для дальнейшего решения.

Ссылки на соответствующую конфигурацию: Часто используемые команды отладки, Сеть CAN и поиск ID.

Rescheduled timer in the past​

Сообщение об ошибке: В журнале появляется Rescheduled timer in the past или аналогичное предупреждение.

Причина ошибки: Проблемы с системными часами上位机 или слишком высокая нагрузка на CPU приводят к тому, что фактическое время выполнения запланированных задач отстает от запланированного.

Методы решения:

  1. Если включена синхронизация NTP, временно отключите ее для теста.
  2. Снизьте нагрузку от других служб, работающих на上位机, например, отключите ненужные веб-интерфейсы, видеопотоки камер и т. д.
  3. При работе в виртуальной машине рассмотрите возможность перехода на физическую машину или использования более стабильного источника времени.
  4. Проверьте использование CPU上位机: с помощью htop посмотрите, нет ли аномального потребления CPU процессом klippy. Соответствующая конфигурация для справки: Часто используемые команды отладки.

MCU 'mcu' shutdown: Move queue overflow​

Сообщение об ошибке: MCU 'mcu' shutdown: Move queue overflow.

Причина ошибки: Очередь движения MCU переполнена, хост-сторона не успела своевременно синхронизировать планирование движения и состояние с MCU. Обычно возникает при недостаточной производительности хоста, большом количестве мелких перемещений за короткое время, несоответствии версий Klipper на хосте и прошивки MCU, или когда модифицированный производителем Klipper добавляет в каждую команду движения блокирующую логику, такую как синхронная запись на диск, восстановление печати после сбоя питания и т.п.

Ключевые моменты для диагностики:

  • В klippy.log наблюдается значительное расхождение между Git version и базовой версией в Loaded MCU 'xxx' ... version.
  • В журнале появляются dirty, сторонние файлы klippy/extras, модифицированное производителем восстановление после сбоя питания или неофициальный Klipper.
  • Один и тот же G-code файл не выполняется примерно в одном и том же месте, а модель содержит множество коротких сегментов, плотные поддержки, спиральный Z-hop или сложные траектории.
  • Низкопроизводительный上位机 одновременно запускает камеру, экран, удаленное управление или другие высоконагруженные службы.

Методы решения:

  1. Просмотрите полный klippy.log, сначала убедитесь, нет ли более ранних ошибок Timer too close, потери связи CAN, bytes_invalid или ошибок температуры/TMC.
  2. После обновления Klipper перекомпилируйте и перепрошейте все прошивки MCU, чтобы версии прошивки хоста, материнской платы и платы инструмента совпадали.
  3. Временно отключите поток с камеры, KlipperScreen, плагины удаленного управления и другие службы с высоким потреблением ресурсов и повторите тест.
  4. Снизьте скорость печати, ускорение, микрошаг, или в слайсере уменьшите точность кривых, сложность поддержек и плотность коротких сегментов.
  5. Если используются модифицированные производителем функции восстановления после сбоя питания, автоматической записи высоты или сторонние плагины, сначала проведите кросс-тест с оригинальным Klipper или отключив соответствующие функции; не изменяйте напрямую исходный код Klipper как стандартную процедуру для обычных клиентов.
  6. Если это происходит только с определенным G-code файлом, переслайсите и проверьте, не выдает ли слайсер аномально плотные пути.

Соответствующая конфигурация для справки: Часто используемые команды отладки, Рекомендации по аппроксимации дуг.

stepcompress / syncemitter / flush_handler внутренняя ошибка​

Сообщение об ошибке: stepper.error: Internal error in stepcompress, stepcompress ... Invalid sequence, Error in syncemitter 'extruder' step generation, Exception in flush_handler, Flush Handler error.

Причина ошибки: Klipper обнаружил внутреннее исключение при генерации или сжатии импульсов шаговых двигателей. В недавних случаях в сообществе подобные проблемы часто возникают одновременно с быстрым сканированием стола, плагинами датчиков типа scanner / EDDY / Cartographer, input_shaper, сложными траекториями движения или сторонними модификациями Klipper. Это не обязательно вызвано только слайсером, и не следует считать переслайсинг единственным способом определения корневой причины.

Методы решения:

  1. Сохраните полный klippy.log, обратите особое внимание на Python Traceback до и после ошибки, выполняемые команды и строки Stats.
  2. Если ошибка возникает во время BED_MESH_CALIBRATE, QUAD_GANTRY_LEVEL или сканирования стола сканером, сначала снизьте скорость сканирования, количество точек, плотность интерполяции и параметры сканирования плагина.
  3. Временно отключите сторонние сканеры, автоматическое регулирование скорости, расширенные функции автоуровня, пакеты макросов или модификации производителя и повторите тест с оригинальным Klipper.
  4. После обновления Klipper перепрошейте все прошивки MCU и убедитесь, что версии прошивки периферийных устройств и Klipper на хосте совпадают.
  5. Если одна и та же модель вызывает ошибку повторно, переслайсите и уменьшите плотность коротких сегментов; если после переслайсинга ошибка возникает случайным образом, продолжайте проверку с учетом нагрузки на хост, параметров движения и совместимости плагинов.
  6. Если принтер совершает аномальные движения, пропуск шагов или существует риск столкновения, немедленно выполните аварийную остановку и повторную процедуру возврата в исходное положение, не пытайтесь продолжить исходную задачу.

Соответствующая конфигурация для справки: Ошибки движения, ограничений и выравнивания, Сборник проблем EDDY.

Internal error during connect / has no attribute​

Сообщение об ошибке: После обновления Klipper не удается завершить запуск, в журнале появляется Unhandled exception during connect, Internal error during connect, конец Traceback может выглядеть примерно так:

AttributeError: 'MCU' object has no attribute '_serialport'

Также могут отображаться другие сообщения has no attribute, got an unexpected keyword argument или указания на отсутствие интерфейса модуля.

Характер ошибки: Эта ошибка означает, что Klipper столкнулся с исключением при выполнении Python-кода на этапе инициализации соединения. В недавних случаях в сообществе, если Traceback указывает на сторонний модуль klippy/extras/, это обычно означает, что Klipper обновил внутренние интерфейсы, а старая версия расширения или модуль, модифицированный производителем, по-прежнему вызывает исходный интерфейс; это, как правило, не повреждение прошивки MCU, и не следует сначала рассматривать это как неисправность последовательного порта.

Частые причины:

  • Klipper был обновлен, но сторонние датчики, модули смены материала, пакеты макросов или другие расширения не были обновлены.
  • Используется модифицированная производителем ветка Klipper, но применяются расширения, совместимые только с оригинальным Klipper.
  • При обновлении расширения файлы были сохранены не полностью, старые и новые Python-файлы остались одновременно.
  • Traceback на самом деле указывает на другие исключения в конфигурационных файлах, переменных файлах или оригинальных модулях, а не на проблему совместимости расширений.

Методы решения:

  1. Сохраните полный klippy.log, начиная с первого Unhandled exception during connect, прочитайте Traceback до конца, запишите самое последнее исключение и имя файла klippy/extras/xxx.py, которое предшествует исключению.
  2. Просмотрите Git version, Modified files и Untracked files в начале журнала. Если файл с исключением принадлежит стороннему расширению, сначала обновите его до версии, совместимой с текущим Klipper, следуя инструкциям по обслуживанию этого расширения.
  3. Временно отключите сторонний модуль или соответствующие include, на которые указывает Traceback, затем перезапустите, чтобы убедиться, что оригинальный Klipper может нормально подключиться. Не пытайтесь решить проблему отсутствия атрибута Python многократной перепрошивкой MCU.
  4. Если используется модифицированный производителем Klipper, следует использовать способ обновления, явно поддерживаемый этой системой; не смешивайте произвольно оригинальный Klipper, модифицированные ветки и расширения разных версий.
  5. Если Traceback указывает только на файлы оригинального Klipper, а в Modified files / Untracked files нет аномалий, обновитесь до текущей стабильной версии, снова соберите полный журнал и сообщите в сообщество Klipper воспроизводимые шаги.
  6. Понижение версии допустимо только для кратковременного подтверждения, является ли это проблемой совместимости версий. Долгосрочным решением должно быть обновление расширения или удаление несовместимого модуля, не оставайтесь на длительное время на заведомо устаревшей версии.

Internal error during ready callback: Unable to save variable​

Сообщение об ошибке: Klipper сразу после запуска переходит в shutdown, в журнале появляются следующие ключевые слова:

Unable to save variable
reactor.ReactorError: Internal error - reactor pause disabled
Unhandled exception during ready callback
Internal error during ready callback: Unable to save variable

Характер ошибки: Unable to save variable — это лишь результат ошибки записи переменной. В недавних случаях в сообществе, если она появляется одновременно с reactor pause disabled, ready callback, это обычно означает, что стороннее расширение вызывает SAVE_VARIABLE на этапе ready-обратного вызова Klipper, что несовместимо с новым механизмом асинхронной записи; это не эквивалентно повреждению устройства хранения или потере связи с MCU.

Частые причины:

  • После обновления Klipper старое стороннее расширение по-прежнему синхронно записывает переменные в обратном вызове запуска.
  • Расширение или модуль, модифицированный производителем, не был обновлен, Traceback указывает на его файл klippy/extras/.
  • Если в журнале нет reactor pause disabled, это также может быть ошибка пути к файлу переменных, доступ только для чтения к каталогу, исчерпание дискового пространства или аномалия прав доступа.

Методы решения:

  1. Начиная с первого Unable to save variable в klippy.log, прочитайте полный Python Traceback, запишите путь к первому стороннему модулю и оригинальный текст исключения, не смотрите только на последнюю строку о shutdown.
  2. Если одновременно появляются reactor pause disabled и путь к стороннему расширению, сначала обновите это расширение до версии, совместимой с текущим Klipper, затем перезапустите Klipper; если совместимой версии расширения нет, свяжитесь с разработчиком расширения.
  3. Можно временно отключить стороннее расширение или соответствующие include, на которые указывает Traceback, и повторить тест, чтобы убедиться, что оригинальный Klipper может нормально запуститься. Не изменяйте напрямую исходный код ядра Klipper как обычную процедуру диагностики.
  4. Если Traceback указывает на Permission denied, Read-only file system или No space left on device, выполните следующие команды для проверки дискового пространства и прав доступа к файлу переменных, затем исправьте фактический путь или права; не используйте chmod 777 для расширения прав на несвязанные каталоги.
df -h
ls -l ~/printer_data/config/
  1. Понижение версии Klipper допустимо только для кратковременной проверки совместимости и не должно использоваться как долгосрочное решение; после подтверждения проблемы следует восстановить поддерживаемую версию Klipper и обновить соответствующие расширения.

Internal error on command​

Сообщение об ошибке: Internal error on command:"XXX", Klipper переходит в состояние shutdown.

Распространенные причины:

  • Макрос или G-code команда вызвали внутреннее исключение Python в Klipper.
  • В конфигурационном файле присутствуют ошибочные ссылки на макросы или ошибки синтаксиса шаблона Jinja2.
  • Несовместимость версии Klipper с форматом конфигурационного файла.
  • Имя G-code файла содержит специальные символы, вызывающие ошибку кодировки.
  • Ошибки stepcompress, syncemitter или flush_handler, приводящие к прерыванию выполнения команды.

Методы решения:

  1. Просмотрите полный Python Traceback под сообщением Internal error в klippy.log.
  2. По Traceback определите, какой конфигурационный файл или макрос вызывает проблему.
  3. К распространенным причинам относятся ошибки синтаксиса шаблона Jinja2 в [gcode_macro], отсутствие конфигурации [respond], неверный путь в [virtual_sdcard].
  4. Если ошибка связана с SDCARD_PRINT_FILE и появляется сообщение ascii codec can't decode, переименуйте G-code файл, используя только латиницу, цифры, символы подчеркивания или дефиса.
  5. Если в Traceback присутствуют stepcompress, syncemitter или flush_handler, продолжайте диагностику согласно разделу Внутренние ошибки stepcompress / syncemitter / flush_handler.

Справочная конфигурация: Введение в макросы, Инструкция по изменению конфигурации.

Unable to open file / SD busy​

Сообщение об ошибке: При печати файла появляется Unable to open file, Unable to get file list, SD busy, SD write not supported, SDCARD_RESET_FILE cannot be run from the sdcard.

Распространенные причины:

  • G-code файл не существует, переименован или загрузка не завершена.
  • [virtual_sdcard] path указывает на неверный каталог.
  • Аномальные права доступа к файлу, пользователь Klipper не может его прочитать.
  • Имя файла содержит специальные символы, вызывающие проблемы обработки пути в некоторых интерфейсах или системах.
  • Во время печати или чтения файла одновременно выполняются команды открытия, выбора, сброса или записи на виртуальную SD-карту.
  • В [virtual_sdcard] path ошибочно указан каталог исходного кода Klipper, каталог конфигурации или другая не-G-code директория.

Методы решения:

  1. Повторно загрузите G-code файл через веб-интерфейс и убедитесь, что имя файла соответствует команде печати.
  2. Проверьте, указывает ли [virtual_sdcard] path на фактический каталог хранения G-code файлов.
  3. Проверьте права доступа к каталогу: ls -la ~/printer_data/gcodes/.
  4. Переименуйте файл, используя только латиницу, цифры, символы подчеркивания или дефиса, затем протестируйте снова.
  5. При появлении SD busy сначала приостановите или отмените текущую печать, убедитесь, что другие макросы не работают с файлом виртуальной SD-карты.
  6. Не устанавливайте ~/klipper, ~/printer_data/config или системные каталоги в качестве каталога хранения G-code файлов.

Справочная конфигурация: Инструкция по изменению конфигурации.

MCU CRC does not match config / Can not update MCU config​

Сообщение об ошибке: MCU 'xxx' CRC does not match config, Can not update MCU 'xxx' config as it is shutdown, Unable to configure MCU 'xxx'.

Ключевой момент диагностики: Can not update MCU 'xxx' config as it is shutdown обычно не является первоначальной корневой причиной, а представляет собой последующую ошибку, возникающую при повторном подключении или перенастройке MCU, когда MCU уже находится в состоянии shutdown/error. При диагностике не следует смотреть только на последнюю строку журнала, нужно прокрутить выше и найти более раннюю первую реальную ошибку.

Методы решения:

  1. Выполните FIRMWARE_RESTART, при необходимости полностью обесточьте устройство на 10 секунд и снова подайте питание.
  2. Просмотрите в klippy.log более раннюю первую ошибку shutdown, Timer too close, Lost communication, Verify heater, ошибку TMC или температуры, сначала устраните корневую причину shutdown.
  3. На машинах с несколькими MCU проверьте USB ID или CAN UUID для каждого [mcu], [mcu xxx].
  4. Если Klipper был недавно обновлен, перекомпилируйте и прошейте прошивку всех MCU.
  5. При использовании [mcu host] проверьте, что служба klipper-mcu запущена корректно, затем перезапустите Klipper.
  6. При использовании предустановленной или модифицированной системы Klipper убедитесь в полноте журналов и соответствии версий Klipper и прошивки MCU по происхождению.

MCU 'xxx' shutdown: Command request​

Сообщение об ошибке: MCU 'xxx' shutdown: Command request.

Распространенные причины:

  • Несоответствие версии прошивки CAN-платы и версии Klipper на хост-компьютере, хост отправляет команды, не поддерживаемые этой прошивкой.
  • После обновления Klipper или системы не была перекомпилирована и прошита прошивка платы.
  • В конфигурации включены функции, не скомпилированные в прошивку данного MCU (например, EDDY / ADXL сконфигурированы без включенного I2C).

Методы решения:

  1. Просмотрите в klippy.log строки Loaded MCU 'xxx' ... version и Git version, убедитесь в соответствии версий.
  2. Перекомпилируйте и прошейте прошивку проблемного MCU, способ прошивки уточняйте в документации соответствующей платы.
  3. На машинах с несколькими MCU убедитесь, что все прошивки MCU получены из одной компиляции.
  4. После прошивки выполните FIRMWARE_RESTART и убедитесь, что ошибка не повторяется.

Общая проверка версий: Ошибка протокола MCU

Shutdown due to M112 command / webhooks request​

Сообщение об ошибке: Shutdown due to M112 command или Shutdown due to webhooks request.

Методы решения:

  1. Проверьте, не была ли аварийная остановка вызвана человеком; если да, после устранения рисков выполните FIRMWARE_RESTART.
  2. Найдите в пользовательских макросах M112, action_emergency_stop, emergency_stop.
  3. Проверьте, не вызывает ли интерфейс, плагин удаленного управления или скрипты автоматизации случайное срабатывание аварийной остановки.

Недостаточная производительность хост-компьютера, вызывающая задержки при печати​

Сообщение об ошибке: Явных ошибок нет, но в процессе печати возникают периодические паузы, прерывистая экструзия.

Методы решения:

  1. Снизьте скорость и ускорение печати.
  2. Отключите ненужные веб-службы, потоки камер и т. д. на хост-компьютере.
  3. Уменьшите probe_count и mesh_pps в [bed_mesh].
  4. Если слайсер выводит дуги G2 / G3, отрегулируйте или отключите их согласно Рекомендации по аппроксимации дуг.
  5. Если производительности хост-компьютера действительно недостаточно, рассмотрите замену на более производительный.

Аномальная перезагрузка хост-компьютера / сбой системы​

Сообщение об ошибке: Во время печати Klipper / Moonraker внезапно отключаются, klippy.log внезапно обрывается без явной корневой причины shutdown; после переподключения Mainsail / Fluidd обнаруживает, что хост-компьютер или Klipper перезагрузились.

Распространенные причины:

  • Недостаточное питание хост-компьютера, изменения нагрузки USB, камеры, экрана или вентиляторов во время печати приводят к потере питания.
  • Аномалии чтения/записи системного диска, TF-карты или eMMC, внезапное прерывание журналов или повреждение файлов.
  • Перегрев CPU хост-компьютера, защитное снижение частоты, зависание или перезагрузка.
  • Обратная подача питания по USB или аномальные пути питания периферийных устройств, вызывающие взаимное влияние платы, экрана или хост-компьютера.
  • Сторонние службы, потоки камер, AI-плагины или чрезмерное количество веб-подключений потребляют ресурсы.

Методы диагностики:

Операции с отключением питания

Перед проверкой кабелей питания хост-компьютера, USB-кабелей, кабелей экрана, вентиляторов или прокладкой проводов полностью выключите принтер и отключите блок питания. Не разбирайте блок питания и не изменяйте электрические соединения сети.

  1. Сначала просмотрите klippy.log, moonraker.log и системные журналы, чтобы определить, произошла ли ошибка Klipper или перезагрузка всего хост-компьютера.
  2. Проверьте характеристики блока питания хост-компьютера, избегайте использования кабелей питания с недостаточным током или заметным падением напряжения.
  3. Проверьте состояние системного диска, при необходимости замените надежную TF-карту, eMMC или переустановите систему.
  4. Проверьте охлаждение хост-компьютера: убедитесь, что вентилятор работает, радиатор прилегает, корпус вентилируется.
  5. Временно отключите потоки камер, KlipperScreen, плагины удаленного управления и другие высоконагруженные службы, затем проведите тестовую печать.
  6. При подозрении на обратную подачу питания по USB предпочтительно замените кабель на готовый USB-кабель или используйте решение с гальванической развязкой питания; обычным пользователям не рекомендуется самостоятельно изменять проводку.

Приостановка, возобновление и сохранение состояния​

Сообщение об ошибке: Print already paused, Print is not paused, resume aborted, Unknown g-code state: PAUSE_STATE.

Распространенные причины:

  • Повторное выполнение PAUSE, или выполнение RESUME после отмены печати.
  • Несоответствие имен SAVE_GCODE_STATE NAME= и RESTORE_GCODE_STATE NAME= в пользовательских макросах приостановки/возобновления.
  • Дублирование определений или конфликт логики между сторонними пакетами макросов и стандартными макросами приостановки/возобновления Mainsail / Fluidd.
  • После аварийной остановки, FIRMWARE_RESTART или ошибки Klipper исходное состояние приостановки было потеряно. Способы решения:
  1. Проверьте текущее состояние печати, не выполняйте RESUME до постановки на паузу.
  2. Проверьте, включён ли [pause_resume], и не дублируются ли определения макросов PAUSE / RESUME / CANCEL_PRINT.
  3. Проверьте, полностью ли совпадают имена SAVE_GCODE_STATE и RESTORE_GCODE_STATE в макросах.
  4. После ошибки или аварийной остановки Klipper не рекомендуется продолжать печать, необходимо устранить риск и начать заново.

Klipper 反复重启 (Klippy not connected 反复闪烁)​

Сообщение об ошибке: В Mainsail / Fluidd отображается Klippy not connected, которое появляется повторно, Klipper постоянно перезапускается автоматически и завершает работу в течение нескольких секунд. В логах может наблюдаться Klipper restarting too fast или очень короткий klippy.log при каждом перезапуске.

Метод поиска:

  1. Сначала просмотрите конец файла журнала, чтобы подтвердить причину последнего завершения работы:

    tail -100 ~/printer_data/logs/klippy.log

  2. Если в конце журнала находится Python Traceback, это означает сбой из-за ошибки синтаксического анализа конфигурации или внутреннего исключения.

  3. Не судите о корневой причине только по сообщению Klipper restarting too fast; обычно это лишь результат повторных неудачных запусков systemd, следует в первую очередь обрабатывать первую реальную ошибку в klippy.log.

  4. Если в конце журнала отображается MCU Protocol error, Unknown command и т.п., это указывает на несоответствие версий прошивки, необходимо перекомпилировать и прошить прошивку MCU.

  5. Если журнал очень короткий и явных ошибок нет, попробуйте использовать метод бинарного поиска с минимальной конфигурацией для локализации.

  6. Проверьте наличие циклических ссылок в подключаемых файлах (include files).

Unhandled exception during run​

Сообщение об ошибке: Unhandled exception during run, на фронтенде отображается Printer is shutdown, в журнале сопровождается Python Traceback.

Распространённые причины:

  • Это не отдельный аппаратный сбой, а общее сообщение об ошибке после перехвата необработанного исключения главным циклом Klipper. Реальную причину необходимо искать в конкретной ошибке выше Traceback.
  • Частые источники: ошибка чтения UART TMC (Unable to read tmc uart 'stepper_x' register DRV_STATUS), прерывание связи CAN, ошибка выполнения макроса шаблона, исключение стороннего модуля расширения.
  • Несовместимость старой конфигурации или старых макросов с новой версией API после обновления Klipper.
  • Повреждение окружения Python на верхнем компьютере или отсутствие зависимостей.

Способы решения:

  1. Откройте полный klippy.log, найдите Traceback выше Unhandled exception during run и найдите первую реальную ошибку (например, Unable to read tmc uart, CanError, TypeError и т. д.).
  2. Если реальная ошибка — сбой связи UART TMC, проверьте проводку и конфигурацию согласно Поиск ошибок TMC.
  3. Если это аномалия связи CAN, проверьте состояние шины согласно Поиск ошибок CAN.
  4. Если Traceback указывает на какой-либо макрос или модуль расширения, проверьте совместимость этого модуля с текущей версией Klipper, при необходимости обновите или временно отключите его.
  5. Если эта ошибка появилась после обновления Klipper, проверьте Config_Changes.md на наличие требований миграции конфигурации.
  6. Не судите о проблеме только по строке Unhandled exception during run, это лишь оболочка, истинная причина всегда находится в Traceback.

Missed scheduling of next hard pwm event​

Сообщение об ошибке: MCU 'mcu' shutdown: Missed scheduling of next hard pwm event.

Распространённые причины:

  • Аналогично Missed scheduling of next digital out event, это означает, что верхний компьютер не смог отправить событие PWM на MCU в установленный срок.
  • Слишком высокая нагрузка на ЦП верхнего компьютера (видеопоток, KlipperScreen, одновременная работа множества плагинов).
  • При использовании лазерного модуля или высокочастотного PWM-инструмента слишком малый cycle_time приводит к чрезвычайно коротким интервалам планирования.
  • Слишком высокая задержка шины CAN, событие истекло по таймауту во время передачи.

Способы решения:

  1. Проверьте нагрузку на ЦП верхнего компьютера, временно отключите камеру, KlipperScreen и другие необязательные службы и проведите повторное тестирование.
  2. При использовании лазерного или PWM-инструмента соответственно увеличьте cycle_time (например, с 0.00002 до 0.0001).
  3. Проверьте состояние шины CAN, убедитесь, что tx_error, bytes_retransmit не растут непрерывно.
  4. Замените кабель USB на качественный или снизьте скорость передачи CAN (например, с 1M до 500K) для тестирования.
  5. Для верхнего компьютера с низкой производительностью (старые телефоны, малопроизводительные платы разработки) рекомендуется сократить количество одновременно работающих служб.

Связанная ошибка: Missed scheduling of next digital out event

Can't reset time when stepper active​

Сообщение об ошибке: MCU 'mcu' shutdown: Can't reset time when stepper active, часто сопровождается автоматическим перезапуском Klipper посреди печати; после перезапуска может сразу появиться TMC stepper_x failed to init: Timeout on wait for 'tmcuart_response' response.

Распространённые причины:

  • Это не отдельный аппаратный сбой, а ситуация, когда верхний компьютер пытается сбросить базовое время шагового двигателя, когда шаговый двигатель всё ещё движется, MCU отказывает и переходит в защитное отключение.
  • Наиболее частый триггер — самопроизвольный перезапуск службы Klipper (со стороны верхнего компьютера) посреди печати: в журнале вы увидите Starting Klippy..., идущий сразу после строки статистики Stats печати за предыдущую секунду.
  • Клиент или плагин, подключённый через Moonraker, неоднократно запрашивает перезапуск службы.
  • Недостаточное питание верхнего компьютера, перегрев, исчерпание памяти и т.п., в результате чего система убивает службу klipper и поднимает её заново.

Способы решения:

  1. Откройте полный klippy.log, найдите Starting Klippy..., подтвердите, перезапускался ли Klipper посреди печати, и временной интервал с предыдущей строкой статистики печати.
  2. Выполните systemctl status klipper.service и journalctl -efu klipper, чтобы просмотреть записи и причины перезапуска службы.
  3. Проверьте клиенты и плагины, подключённые к Moonraker (видеопоток, сторонние плагины, пользовательские скрипты), убедитесь, что ни одно устройство не запрашивает перезапуск службы или перезагрузку машины.
  4. Проверьте питание, охлаждение и использование памяти верхнего компьютера; старые Raspberry Pi или малопроизводительные платы разработки при одновременной работе с камерой и KlipperScreen могут быть убиты системой из-за нехватки памяти.
  5. Появляющийся после перезапуска Timeout on wait for 'tmcuart_response' является результатом перезапуска, а не корневой причиной, поэтому не начинайте поиск с проверки проводки TMC.

Связанные ошибки: Klipper 反复重启、Unhandled exception during run

Loading...