본문으로 건너뛰기

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

이 페이지에서는 통신 타임아웃, 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​

오류 메시지: 스텝 이벤트가 MCU가 처리할 수 있는 시간 범위를 초과하여 프린터가 셧다운 상태가 됩니다.

Loading...

참조 시나리오: 이 오류가 항상 베드 메시 구성으로 인해 발생하는 것은 아닙니다. 실제 원인은 klippy.log와 현재 작업을 결합하여 판단해야 합니다. 다중 포인트 베드 메싱을 수행할 때 [bed_mesh]의 probe_count가 너무 크게 설정되고 동시에 높은 mesh_pps가 구성되면 너무 조밀한 메시 데이터가 생성되어 호스트 계산 및 모션 계획 부하가 증가할 수 있습니다.

해결 방법:

  1. 오류가 다중 포인트 베드 메싱 중에 발생하면 먼저 [bed_mesh]의 probe_count를 7,7 또는 9,9로 낮추어 테스트하십시오.
  2. 높은 mesh_pps가 구성된 경우 해당 구성을 낮추거나 삭제하십시오(예: mesh_pps: 2,2).
  3. 구성을 저장하고 Klipper를 다시 시작한 후 오류를 트리거한 작업을 다시 실행하십시오.
  4. 그래도 오류가 발생하면 호스트 부하, 인쇄 속도, 가속도, 통신 품질 및 현재 실행 중인 매크로 또는 G-code를 계속 확인하십시오.

관련 구성 참조: 매크로 소개, 일반적인 디버그 지시어.

MCU 'mcu' 셧다운: Timer too close​

오류 메시지: MCU 타이머가 너무 가까워 시스템 시간 초과가 발생합니다.

Loading...

오류 원인: 하위 MCU 처리 부하 과다, 호스트 응답 시간 초과, 인쇄 속도 과다, 마이크로스텝 과다, 시스템 시간 동기화 간섭 또는 MCU 통신선 간섭으로 인해 이 문제가 발생할 수 있습니다.

해결 방법:

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

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

과거로 예약된 타이머(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)​

오류 메시지: 파일 인쇄 중 Unable to open file 오류가 발생합니다.

일반적인 원인:

  • G-code 파일이 존재하지 않거나, 파일 이름이 변경되었거나, 업로드가 완료되지 않음.
  • [virtual_sdcard] path가 잘못된 디렉토리를 가리킴.
  • 파일 권한이 비정상적이어서 Klipper 사용자가 읽을 수 없음.
  • 파일 이름에 특수 문자가 포함되어 일부 프론트엔드 또는 시스템 경로 처리에 문제가 발생함.

해결 방법:

  1. 웹 인터페이스에서 G-code 파일을 다시 업로드하고 파일 이름이 인쇄 명령과 일치하는지 확인하십시오.
  2. [virtual_sdcard] path가 실제 G-code 저장 디렉토리를 가리키는지 확인하십시오.
  3. 디렉토리 권한을 확인하십시오: ls -la ~/printer_data/gcodes/.
  4. 파일 이름을 영문, 숫자, 밑줄 또는 하이픈으로 변경한 후 다시 테스트하십시오.

관련 구성 참조: 구성 수정 설명.

MCU CRC가 구성과 일치하지 않음 / MCU 구성을 업데이트할 수 없음​

오류 메시지: MCU 'xxx' CRC does not match config, Can not update MCU 'xxx' config as it is shutdown, Unable to configure MCU 'xxx'.

해결 방법:

  1. FIRMWARE_RESTART를 실행하고, 필요한 경우 전체 기계의 전원을 10초 동안 차단했다가 다시 켜십시오.
  2. klippy.log에서 더 일찍 나타난 첫 번째 오류를 확인하고 셧다운을 유발한 근본 원인을 먼저 수정하십시오.
  3. 다중 MCU 기계에서 [mcu], [mcu xxx]의 USB ID 또는 CAN UUID를 개별적으로 확인하십시오.
  4. Klipper를 최근에 업데이트한 경우 모든 MCU 펌웨어를 다시 컴파일하고 플래싱하십시오.

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. 호스트에서 불필요한 웹 서비스, 카메라 스트림 등을 종료하십시오.
  3. [bed_mesh]의 probe_count와 mesh_pps를 줄이십시오.
  4. 호스트 성능이 실제로 부족한 경우 더 성능이 좋은 호스트로 교체하는 것을 고려하십시오.

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...