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

На этой странице собраны вопросы, связанные с тайм-аутом связи, ошибками таймера 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-код, генерирующие большое количество команд движения за короткое время — все это может вызвать проблему.

Типичный сценарий: При выполнении многоточечного измерения сетки, если в [bed_mesh] установлено слишком большое probe_count и одновременно настроено высокое 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, чтобы проверить, есть ли одновременно высокая загрузка ЦП, 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-код, выполнявшиеся перед возникновением ошибки, избегайте циклов макросов, слишком плотных коротких сегментов или аномальных скриптов, отправляющих большое количество команд движения за короткое время.

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

MCU 'mcu' shutdown: Timer too close

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

Loading...

Причина ошибки: Слишком высокая нагрузка на обработку на стороне нижнего контроллера, тайм-аут ответа от управляющего компьютера, слишком высокая скорость печати, слишком высокое микрошаговое разрешение, помехи синхронизации системного времени или помехи на линии связи 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.
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 или аналогичное предупреждение.

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

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

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

Завершение работы MCU 'mcu': Переполнение очереди перемещений

Сообщение об ошибке: 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. Временно отключите сторонние scanner, автоматическую регулировку скорости, расширенное выравнивание, макропакеты или модификации производителя, протестируйте с оригинальным Klipper.
4. После обновления Klipper перепрошейте прошивку всех MCU и убедитесь, что версии прошивки периферийных устройств соответствуют версии Klipper на хосте.
5. Если одна и та же модель вызывает ошибку повторно, переслайсите и уменьшите плотность коротких сегментов; если после переслайсирования ошибка возникает случайным образом, продолжайте диагностику, проверяя нагрузку на хост, параметры движения и совместимость плагинов.
6. Если принтер совершает аномальные движения, теряет шаги или есть риск столкновения, немедленно выполните экстренную остановку и верните оси в исходное положение, не пытайтесь продолжить задачу.

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

Internal error on command

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

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

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

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

1. Просмотрите в klippy.log полный Python Traceback, расположенный ниже сообщения Internal error.
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 не совпадает с конфигурацией / Невозможно обновить конфигурацию MCU

Сообщение об ошибке: 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 обычно не является первопричиной, а является последующей ошибкой, которая появляется, когда Klipper пытается повторно подключиться или перенастроить 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': 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 Protocol error

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, камеры, экрана или вентилятора приводит к отключению питания.
• Аномалии чтения/записи системного диска, SD-карты или eMMC; внезапное прерывание логов или повреждение файлов.
• Перегрев CPU хост-компьютера, приводящий к защитному снижению частоты, зависанию или перезагрузке.
• Обратное питание по USB или аномалии в цепи питания периферии, приводящие к взаимному влиянию материнской платы, экрана или хост-компьютера.
• Сторонние сервисы, потоки камер, AI-плагины или слишком много веб-соединений потребляют ресурсы.

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

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

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

1. Сначала проверьте klippy.log, moonraker.log и системные логи, чтобы определить, произошла ли ошибка в Klipper или перезагрузка всего хост-компьютера.
2. Проверьте спецификацию блока питания хост-компьютера; избегайте использования проводов с недостаточным током или заметным падением напряжения.
3. Проверьте состояние здоровья системного диска; при необходимости замените на надежную SD-карту, 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-файлах.

Unhandled exception during run

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

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

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

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

1. Откройте полный klippy.log, найдите Traceback выше Unhandled exception during run и найдите первую реальную ошибку (например, Unable to read tmc uart, CanError, TypeError и т.д.).
2. Если реальная ошибка — сбой связи TMC UART, проверьте соединения и конфигурацию согласно Диагностика ошибок 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 в установленный срок.
• Высокая нагрузка на CPU хост-компьютера (поток камеры, KlipperScreen, одновременная работа множества плагинов).
• При использовании лазерного модуля или высокочастотного PWM-инструмента слишком малый cycle_time приводит к чрезвычайно коротким интервалам планирования.
• Высокая задержка шины CAN, приводящая к тайм-ауту передачи события.

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

1. Проверьте загрузку CPU хост-компьютера; временно отключите камеру, 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

Нельзя сбросить время, когда шаговый двигатель активен

Сообщение об ошибке: 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 постоянно перезапускается, Необработанное исключение во время выполнения