본문으로 건너뛰기

시스템, 성능 및 서비스 오류

이 페이지에서는 통신 타임아웃, MCU 타이머 오류, 상위 컴퓨터 성능, 펌웨어 플래싱 및 Klipper 서비스 시작 관련 문제를 정리합니다.

귀환 타임아웃 문제​

오류 메시지: 귀환 중 Communication timeout during homing, Error during homing xxx 발생. 주로 다중 MCU Z축 귀환 시나리오에서 나타납니다.

일반적인 원인:

  • 상위 컴퓨터 부하가 높음. KlipperScreen, 카메라 스트림 등이 동시에 실행됨.
  • 귀환 시 여러 축 모터가 동시에 움직이며, 대전류 구동 신호가 CAN/USB 통신선에 결합되어 통신이 중단됨.
  • 다중 MCU 통신 응답이 불안정함.
  • CAN/USB 통신선 품질 문제 또는 배선 부적절.

해결 방법:

전원 차단 작업

CAN/USB 배선을 재정리하거나, 차폐층을 확인하거나, 접지를 점검하기 전에 프린터를 완전히 종료하고 전원 공급을 차단하십시오. 전원 접지선, AC 배선 또는 전원 공급 장치 내부를 임의로 변경하지 마십시오.

  1. 먼저 전자기 간섭을 배제하십시오: CAN/USB 선이 모터선, 히터선과 분리되어 배선되었는지 확인하십시오. CAN 네트워크 구성 및 ID 검색의 간섭 확인 단계를 참조하십시오.
  2. TRSYNC_TIMEOUT 타임아웃 매개변수를 조정하거나 KlipperScreen을 임시로 비활성화해 보십시오. 자세한 내용은 귀환 타임아웃 문제를 참조하십시오.
  3. 기기 접지 및 차폐층 접지가 정상적인지 확인하십시오.

MCU 'mcu' 셧다운: Stepper too far in past​

오류 메시지: Klipper가 MCU로 보내려고 계획한 스테핑 이벤트가 현재 시간보다 뒤쳐져 MCU가 더 이상 예정된 시간에 이러한 모션 명령을 실행할 수 없으며, 프린터가 셧다운 상태가 됩니다.

Loading...

오류 원인: 이는 일반적으로 특정 고정 구성 항목 때문이 아니라, 호스트 측 모션 계획, MCU 스텝 출력 또는 통신 스케줄링이 제때 처리되지 못한 결과입니다. 상위 컴퓨터 부하 과다, 인쇄 속도/가속도 과다, 스텝 미세분할 과다, 다중 MCU 통신 지연, USB/CAN 통신 품질 저하, 매크로 또는 G-code가 짧은 시간에 많은 모션 명령을 생성하는 등의 경우 모두 이 문제를 유발할 수 있습니다.

참고 시나리오: 다중 포인트 베드 메싱을 수행할 때 [bed_mesh]의 probe_count 설정이 너무 크고 동시에 높은 mesh_pps가 구성된 경우, 과도하게 조밀한 그리드 데이터가 생성되어 상위 컴퓨터 계산 및 모션 계획 부하가 증가할 수 있습니다. 이는 일반적인 시나리오 중 하나일 뿐입니다. 베드 메싱이 없더라도 시스템 부하 또는 통신 지연을 증가시키는 다른 상황에서도 Stepper too far in past가 발생할 수 있습니다.

인쇄 재개 후 정체 시나리오: 이 오류는 PAUSE/RESUME, 필라멘트 부족 복구 또는 정전 복구 후에도 나타날 수 있습니다. 일반적인 로그 패턴: 복구 후 Stats 라인의 buffer_time이 약 1초에서 약 0.2초로 급감하고, sd_pos가 거의 증가하지 않으며(인쇄 진행 정체), sysload는 높지 않고 MCU 연결 끊김도 없습니다. 이는 복구 후 모션 명령이 스텝 버퍼를 지속적으로 채우지 못해 프린터가 "작동은 하지만 거의 움직이지 않다가" 셧다운됨을 의미합니다. 문제 해결 시 resume_gcode, start_gcode와 같은 재개/복구 매크로가 재개 순간에 비정상적인 대량 이동 또는 회수 명령을 보냈는지, 그리고 재개 전에 이미 통신 재전송(bytes_retransmit 증가)이 있었는지 확인하는 데 중점을 둡니다.

해결 방법:

  1. 먼저 klippy.log에서 오류 발생 전의 Stats 라인을 확인하여 CPU 점유율 높음, bytes_retransmit, bytes_invalid, Timer too close, MCU 연결 끊김 또는 큐 이상이 동시에 존재하는지 확인하십시오.
  2. 카메라 스트림, KlipperScreen, 원격 제어 플러그인 및 기타 높은 점유율 서비스를 임시로 비활성화하여 상위 컴퓨터 부하를 줄인 후 다시 테스트하십시오.
  3. 인쇄 속도, 가속도 및 스텝 미세분할을 낮추고 오류가 사라지는지 관찰하십시오.
  4. 오류가 다중 포인트 베드 메싱 중에 발생하는 경우 [bed_mesh]의 probe_count를 낮추십시오. 예: 7,7 또는 9,9로 변경하여 테스트.
  5. 높은 mesh_pps가 구성된 경우 해당 구성을 낮추거나 삭제하십시오. 예: mesh_pps: 2,2로 변경.
  6. USB/CAN 통신 품질을 확인하십시오. CAN을 사용하는 경우 큐 길이, 터미네이션 저항, 배선 순서, 전원 공급 및 펌웨어 CAN 속도를 확인하십시오.
  7. 오류를 트리거하기 전에 실행 중인 매크로 또는 G-code를 확인하여 매크로 루프, 과도하게 조밀한 짧은 선분 또는 비정상적인 스크립트가 짧은 시간에 많은 모션 명령을 보내지 않도록 하십시오.

관련 구성 참조: 매크로 소개, 일반 디버그 명령어.

MCU 'mcu' 셧다운: 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. 기기 접지 상태를 확인할 때는 제조사가 제공한 접지점과 콘센트 상태만 확인하고, 전원 공급 장치를 분해하거나 AC 접지선을 임의로 변경하지 마십시오.
  6. 문제가 귀환 단계에서 발생하는 경우 귀환 타임아웃 문제를 참조하십시오.
  7. M600 또는 필라멘트 부족 복구 후 발생하는 경우, 매크로에서 PAUSE가 반복되는지, 필라멘트 감지 센서가 필라멘트 교체 중에 오작동하는지, SAVE_GCODE_STATE/RESTORE_GCODE_STATE 이름이 일치하는지 확인하십시오.
  8. EDDY TAP, Z 기울기 또는 갠트리 레벨링 중에 발생하는 경우, 먼저 EDDY TAP 모드 디버깅 방법을 참조하십시오.
  9. 문제가 지속되면 상위 컴퓨터 시스템 또는 펌웨어 재플래싱을 고려하십시오.

관련 구성 참조: 일반 디버그 명령어, 귀환 및 방향 보정 가이드.

MCU 셧다운: Missed scheduling of next digital out event​

오류 메시지: MCU 'xxx' shutdown: Missed scheduling of next digital out event.

오류 원인: Klipper 호스트가 히터, 팬 등 디지털 출력을 켠 후, MCU는 제때 후속 스케줄링과 확인을 받아야 합니다. 상위 컴퓨터 부하가 높거나, 시스템 스케줄링 지연, USB/CAN 통신 불안정, 또는 CAN 버스 큐 이상이 있는 경우 MCU가 다음 디지털 출력 이벤트를 제때 수신하지 못하여 셧다운 상태가 됩니다.

주의

이 오류는 히터 출력 스케줄링과 관련됩니다. 온도 보호 비활성화, verify_heater 비활성화 또는 안전 구성 삭제를 통해 오류를 우회하지 말고, 먼저 상위 컴퓨터 부하와 통신 품질을 확인하십시오.

해결 방법:

  1. 먼저 klippy.log에서 이 오류 앞의 Stats 라인을 확인하여 bytes_retransmit, bytes_invalid, Timer too close 또는 MCU 연결 끊김 기록이 동시에 존재하는지 확인하십시오.
  2. 상위 컴퓨터 부하를 낮추고 카메라 스트림, KlipperScreen, 원격 제어 플러그인 또는 기타 높은 점유율 서비스를 임시로 비활성화하십시오.
  3. USB/CAN 통신 품질을 확인하십시오. CAN을 사용하는 경우 CAN0 큐 길이, 터미네이션 저항, 배선 순서, 전원 공급 및 펌웨어 CAN 속도를 확인하십시오.
  4. 인쇄 속도, 가속도 및 스텝 미세분할을 낮추고 문제가 사라지는지 관찰하십시오.
  5. 가열 시에만 발생하는 경우 히트베드, 핫엔드, 팬 및 전원 공급 부하를 함께 확인하십시오. 전원 공급 장치를 임의로 분해하거나 AC 히트베드 고압 배선을 확인하지 마십시오.
  6. CAN 툴보드에서 문제가 발생하는 경우 CAN 오류 문제 해결에 따라 계속 처리하십시오.

관련 구성 참조: 일반 디버그 명령어, CAN 네트워크 및 ID 검색.

Rescheduled timer in the past​

오류 메시지: 로그에 Rescheduled timer in the past 또는 유사한 경고가 나타납니다.

오류 원인: 상위 컴퓨터 시스템 클록 문제 또는 CPU 부하 과다로 인해 타이머 작업의 실제 실행 시간이 계획 시간보다 늦어집니다.

해결 방법:

  1. NTP 동기화가 활성화된 경우 임시로 비활성화하고 테스트하십시오.
  2. 상위 컴퓨터에서 실행 중인 다른 서비스 부하를 줄이십시오. 예: 불필요한 웹 인터페이스, 카메라 스트림 등을 비활성화.
  3. 가상 머신에서 실행 중인 경우 물리적 머신으로 마이그레이션하거나 더 안정적인 클록 소스를 사용하는 것을 고려하십시오.
  4. 상위 컴퓨터 CPU 사용률을 확인하십시오: htop으로 klippy 프로세스에 비정상적인 CPU 점유율이 있는지 확인. 관련 설정 참고: 常用调试指令.

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 또는 scanner 베드 프로빙 중에 발생하는 경우, 먼저 프로빙 속도, 포인트 수, 보간 밀도 및 플러그인 스캔 매개변수를 낮춥니다.
  3. 서드파티 scanner, 자동 속도 조절, 자동 레벨링 강화, 매크로 패키지 또는 제조사 수정을 임시로 비활성화하고 원본 Klipper로 재테스트합니다.
  4. Klipper를 업데이트한 후 모든 MCU 펌웨어를 다시 플래시하고, 주변 장치 펌웨어가 호스트 Klipper 버전과 일치하는지 확인합니다.
  5. 동일한 모델에서 반복적으로 트리거되는 경우, 다시 슬라이싱하여 짧은 선분 밀도를 줄입니다. 재슬라이싱 후에도 무작위로 발생하면 호스트 부하, 모션 매개변수 및 플러그인 호환성을 계속 확인합니다.
  6. 프린터에 비정상적인 움직임, 탈조 또는 충돌 위험이 있는 경우 즉시 비상 정지하고 재귀점(Home)을 수행하며, 원래 작업을 재개하지 마십시오.

관련 설정 참고: 运动、限位与调平报错, EDDY 问题合集.

Internal error on command​

오류 메시지: Internal error on command:"XXX", Klipper가 shutdown 상태가 됩니다.

일반적인 원인:

  • 매크로 또는 G-code 명령이 Klipper 내부 Python 예외를 트리거했습니다.
  • 설정 파일에 잘못된 매크로 참조 또는 Jinja2 템플릿 구문 오류가 있습니다.
  • Klipper 버전과 설정 파일 형식이 호환되지 않습니다.
  • G-code 파일 이름에 특수 문자가 포함되어 인코딩 오류가 발생했습니다.
  • stepcompress, syncemitter 또는 flush_handler 오류로 인해 명령 실행이 중단되었습니다.

해결 방법:

  1. klippy.log에서 Internal error 아래의 전체 Python Traceback을 확인합니다.
  2. Traceback을 기반으로 어떤 설정 파일 또는 매크로에 문제가 있는지 찾습니다.
  3. 일반적인 원인으로는 [gcode_macro]의 Jinja2 템플릿 구문 오류, [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 카드를 열기, 선택, 재설정 또는 쓰기 명령을 다시 실행했습니다.
  • Klipper 소스 코드 디렉토리, 설정 디렉토리 또는 기타 G-code가 아닌 디렉토리를 [virtual_sdcard] path로 잘못 설정했습니다.

해결 방법:

  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가 이미 shutdown/error 상태가 된 후 Klipper가 다시 연결하거나 MCU를 재구성할 때 나타나는 후속 오류입니다. 조사 시 로그의 마지막 줄만 보지 말고, 위로 스크롤하여 더 이른 첫 번째 실제 오류를 찾아야 합니다.

해결 방법:

  1. FIRMWARE_RESTART를 실행하고, 필요한 경우 전체 장치의 전원을 10초간 차단한 후 다시 켭니다.
  2. klippy.log에서 더 이른 시점에 나타난 첫 번째 shutdown, Timer too close, Lost communication, Verify heater, TMC 또는 온도 오류를 확인하고, shutdown을 유발한 근본 원인을 먼저 수정합니다.
  3. 다중 MCU 기계의 경우 각 [mcu], [mcu xxx]의 USB ID 또는 CAN UUID를 개별적으로 확인합니다.
  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 펌웨어가 컴파일 시 지원하지 않는 기능을 구성한 경우 (예: I2C를 활성화하지 않았는데 EDDY / ADXL을 구성).

해결 방법:

  1. klippy.log에서 Loaded MCU 'xxx' ... version과 Git version을 확인하여 버전이 일치하는지 확인합니다.
  2. 오류가 발생한 MCU의 펌웨어를 다시 컴파일하고 플래시합니다. 플래시 방법은 해당 툴보드 제품 문서를 따르십시오.
  3. 다중 MCU 사용 시 모든 MCU 펌웨어가 동일한 컴파일에서 나왔는지 확인합니다.
  4. 플래시 완료 후 FIRMWARE_RESTART를 실행하여 오류가 더 이상 발생하지 않는지 확인합니다.

일반 버전 확인: MCU Protocol error

M112 명령 / webhooks 요청으로 인한 종료​

오류 메시지: Shutdown due to M112 command 또는 Shutdown due to webhooks request.

해결 방법:

  1. 사용자가 의도적으로 비상 정지를 눌렀는지 확인합니다. 그렇다면 위험을 제거한 후 FIRMWARE_RESTART를 실행합니다.
  2. 사용자 정의 매크로에서 M112, action_emergency_stop, emergency_stop을 검색합니다.
  3. 프론트엔드, 원격 제어 플러그인 또는 자동화 스크립트가 비상 정지 인터페이스를 잘못 트리거했는지 확인합니다.

##上位机 성능 부족으로 인한 출력 끊김

오류 메시지: 명확한 오류는 없으나 출력 도중 간헐적인 멈춤, 압출 불연속 현상 발생.

해결 방법:

  1. 출력 속도와 가속도를 낮춥니다. 2.上位机에서 불필요한 웹 서비스, 카메라 스트림 등을 종료합니다.
  2. [bed_mesh]의 probe_count와 mesh_pps 값을 줄입니다.
  3. 슬라이서가 G2 / G3 호를 출력했다면 호 피팅 권장 사항을 참고하여 조정하거나 비활성화합니다. 5.上位机 성능이 정말 부족하다면 더 강력한上位机로 교체를 고려합니다.

##上位机 비정상 재시작 / 시스템 충돌

오류 메시지: 출력 중 Klipper / Moonraker가 갑자기 연결 해제되고, klippy.log가 갑자기 중단되며 명확한 종료 원인이 없음. Mainsail / Fluidd가 재연결되었을 때 상위 컴퓨터 또는 Klipper가 이미 재시작된 상태.

일반적인 원인:

-上位机 전원 공급 부족으로 출력 중 USB, 카메라, 화면 또는 팬 부하 변화로 인해 전원이 꺼짐.

  • 시스템 디스크, TF 카드 또는 eMMC 읽기/쓰기 오류로 로그가 갑자기 중단되거나 파일이 손상됨. -上位机 CPU 과열로 시스템이 보호적으로 클럭 다운, 정지 또는 재시작됨.
  • USB 역전원 공급 또는 주변기기 전원 경로 이상으로 메인보드, 화면 또는 상위 컴퓨터가 서로 영향을 미침.
  • 타사 서비스, 카메라 스트림, AI 플러그인 또는 과도한 웹 페이지 연결로 리소스가 소모됨.

문제 해결 방법:

전원 차단 작업

上位机 전원선, USB 케이블, 화면 케이블, 팬 케이블을 점검하거나 선 정리를 하기 전에 프린터의 전원을 완전히 차단하고 전원 공급 장치를 분리하십시오. 전원 공급 장치를 분해하거나 주 전원 배선을 변경하지 마십시오.

  1. 먼저 klippy.log, moonraker.log 및 시스템 로그를 확인하여 Klipper 오류인지 상위 컴퓨터 자체 재시작인지 확인합니다. 2.上位机 전원 사양을 확인하고 전류 부족이나 전압 강하가明显的인 전원 케이블 사용을 피합니다.
  2. 시스템 디스크 상태를 확인하고 필요한 경우 신뢰할 수 있는 TF 카드, eMMC로 교체하거나 시스템을 다시 플래시합니다. 4.上位机 방열을 확인하고 팬이 정상 작동하며 방열판이 밀착되고 케이스 통풍이 잘 되는지 확인합니다.
  3. 카메라 스트림, KlipperScreen, 원격 제어 플러그인 및 기타 고부하 서비스를 임시로 중단한 후 출력 테스트를 진행합니다.
  4. 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, 프론트엔드에 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를 열고 Unhandled exception during run 위쪽의 Traceback을 검색하여 첫 번째 실제 오류(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에 있습니다.

다음 하드 PWM 이벤트 스케줄링 누락​

오류 메시지: 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가 이를 거부하고 shutdown 보호 모드에 진입하는 경우입니다.
  • 가장 흔한 트리거는 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 반복 재시작, 실행 중 처리되지 않은 예외

Loading...