본문으로 건너뛰기

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

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

해결 방법:

  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) 처리 부하 과다, 호스트 응답 타임아웃, 인쇄 속도 과다, 마이크로스텝 과다, 시스템 시간 동기화 간섭 또는 MCU 통신선 간섭 등으로 인해 이 문제가 발생할 수 있습니다.

해결 방법:

  1. 스텝 모터 마이크로스텝을 줄여 MCU 펄스 처리 부담을 줄이십시오.
  2. 인쇄 속도와 가속도를 낮추고 문제가 사라지는지 확인하십시오.
  3. 호스트 부하, 전원 공급 및 USB/CAN 통신 품질을 확인하십시오.
  4. 전원을 차단한 후 MCU와 호스트 간 통신선이 모터선, 히터선, 베드선 또는 전원선 근처에 있는지 확인하고, 필요한 경우 재배선하거나 차폐된 통신선으로 교체하십시오.
  5. 기계 접지를 확인할 때는 제조사가 제공한 접지점과 콘센트 상태만 확인하고, 전원 공급 장치를 직접 분해하거나 AC 접지선을 변경하지 마십시오.
  6. 문제가 귀환 단계에서 발생하는 경우 귀환 타임아웃 문제를 참조하십시오.
  7. 문제가 지속되면 호스트 시스템 또는 펌웨어 재플래싱을 고려하십시오.

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

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 점유율이 있는지 확인하십시오.

관련 구성 참조: 일반 디버그 명령어.

Internal error on command​

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

일반적인 원인:

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

해결 방법:

  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 파일 이름을 영어, 숫자, 밑줄(_) 또는 하이픈(-)으로 변경하십시오.

관련 구성 참조: 매크로 소개, 구성 수정 설명.

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가 이미 셧다운/오류 상태가 된 후 Klipper가 다시 연결하거나 MCU를 재구성할 때 발생하는 후속 오류입니다. 로그의 마지막 줄만 보지 말고 더 이전의 첫 번째 실제 오류를 위로 찾아보십시오.

해결 방법:

  1. FIRMWARE_RESTART를 실행하고, 필요한 경우 전체 기계의 전원을 10초 동안 껐다가 다시 켜십시오.
  2. klippy.log에서 더 이전에 나타난 첫 번째 shutdown, Timer too close, Lost communication, Verify heater, TMC 또는 온도 오류를 확인하고, 먼저 셧다운을 초래한 근본 원인을 수정하십시오.
  3. 다중 MCU 기계의 경우 각 [mcu], [mcu xxx]의 USB ID 또는 CAN UUID를 개별적으로 확인하십시오.
  4. Klipper를 방금 업데이트한 경우 모든 MCU 펌웨어를 다시 컴파일하고 플래싱하십시오.
  5. [mcu host]를 사용하는 경우 klipper-mcu 서비스가 정상적으로 시작되었는지 확인한 후 Klipper를 다시 시작하십시오.
  6. 사전 설치된 또는 맞춤형 Klipper 시스템을 사용하는 경우 로그가 완전하고 Klipper와 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. [bed_mesh]의 probe_count와 mesh_pps를 줄이십시오.
  4. 슬라이서가 G2/G3 호를 출력하는 경우 호 피팅 권장 사항을 참조하여 조정하거나 비활성화하십시오.
  5. 호스트 성능이 정말 부족하다면 더 강력한 호스트로 업그레이드를 고려하십시오.

호스트 비정상 재시작 / 시스템 충돌​

오류 메시지: 인쇄 중 Klipper/Moonraker가 갑자기 연결 해제되고, klippy.log가 갑자기 중단되며 명확한 셧다운 근본 원인이 없습니다. Mainsail/Fluidd가 다시 연결되면 호스트 또는 Klipper가 재시작된 것을 발견합니다.

일반적인 원인:

  • 호스트 전원 공급 부족. 인쇄 중 USB, 카메라, 화면 또는 팬 부하 변화로 인해 전원이 꺼집니다.
  • 시스템 디스크, TF 카드 또는 eMMC 읽기/쓰기 오류. 로그가 갑자기 중단되거나 파일이 손상됩니다.
  • 호스트 CPU 과열로 인한 시스템 보호 클럭 다운, 정지 또는 재시작.
  • USB 역전원 공급 또는 주변 장치 전원 공급 경로 이상으로 인해 메인보드, 화면 또는 호스트가 서로 영향을 미칩니다.
  • 타사 서비스, 카메라 스트림, AI 플러그인 또는 과도한 웹 연결 리소스 점유.

진단 방법:

전원 차단 작업

호스트 전원선, USB 케이블, 화면 케이블, 팬 케이블을 확인하거나 배선을 정리하기 전에 프린터를 완전히 끄고 전원 공급 장치를 분리하세요. 전원 공급 장치를 분해하거나 AC 배선을 변경하지 마십시오.

  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 파일에 순환 참조가 있는지 확인하십시오.

Loading...