OrcaSlicer 만든 gcode가 프린터에 안 먹힌다 — 펌웨어의 비공개 검증 규칙

슬라이서가 낸 gcode를 프린터로 직접 보내는 것까지는 누구나 할 만해 보입니다. 그런데 특정 펌웨어는 미리 알려주지 않는 엄격한 검증 규칙을 들고 있습니다. 저는 3DWOX 1 프린터에 리눅스에서 파일 복사 없이 네트워크로 바로 출력하는 걸 하다가, 「출력 GCODE 파일에 문제가 있습니다(409)」 라는 에러를 만났습니다. 이 펌웨어가 원하는 형식을, 실제 OEM gcode를 ground truth로 역추적해서 하나씩 잡은 과정을 정리했습니다.

네트워크 출력 자체는 의외로 간단했습니다

파일 복사는 필요 없었습니다. TCP 9100 포트에 raw gcode를 그대로 쏘면 됩니다. PJL 같은 별도 래핑이 필요하지 않았고, 보내는 단계까지는 정상 동작했습니다. 문제는 보낸 뒤에 시작되었습니다. 프린터가 받아들여 주질 않았습니다.

409 에러는 세 가지가 원인이었습니다

에러 문구만 봐서는 「파일에 문제가 있다」 는 것 외에는 알 수 없습니다. 그래서 실제 OEM이 만든 gcode를 ground truth로 삼아, 우리 gcode와 한 줄씩 비교했습니다. 그렇게 잡은 원인이 세 가지였습니다. 첫 번째는 ;LOCATION 헤더의 불일치였습니다. 이 펌웨어는 LOCATION이 실제 툴패스의 최소 코너(min corner)와 일치해야 하는데, 저는 처음에 중심 좌표를 넣었습니다. 그래서 「모델 오류」로 거부되었습니다. min corner로 고치니 이 항목은 통과했습니다. 두 번째는 본문(M532 이후)에 들어간 음수 E 값이었습니다. OrcaSlicer가 리트랙션 때문에 E-6.00000 같은 음수 E를 본문에 넣는데, 이 펌웨어는 본문의 음수 E를 허용하지 않았습니다. 해당 명령을 제거하니 통과했습니다. 세 번째는 M298 명령이었습니다. 실제 OEM 출력에는 없는 명령이라서 제거했습니다. 이렇게 하면서 포맷 기준도 확립했습니다. 헤더 키(;PRINTER_MODEL 등), 시작 시퀀스, LF 줄바꿈, 그리고 본문 구조(M532 L<n>)를 실제 OEM ground truth와 정확히 매칭했습니다. 검증 규칙이 문서화되어 있지 않다 보니, 「이렇게 쓰면 통과한다」 라는 사실 자체를 실물에서 되찾아오는 작업이었습니다.

진짜 함정은 터치스크린에 있었습니다

gcode 오류가 나면 터치스크린에 에러 팝업이 뜹니다. 그 상태에서 9100 포트로 대용량 전송을 하면 타임아웃이 나서 스톨됩니다. 문제는 웹 모니터로는 이 팝업을 해제할 수 없다는 점입니다. 반드시 터치스크린에서 직접 닫아야 재전송이 가능했습니다. 웹 모니터(80 포트)는 상태코드(프린팅 중, 컨트롤 비활성, 유휴)와 진행률만 알려줍니다. 409의 구체적인 원인은 알려주지 않았습니다. 실제 오류 내용은 터치스크린에서만 확인할 수 있었습니다. 그래서 결론적으로 OrcaSlicer의 표준 gcode는 이 프린터에 그대로 호환되지 않습니다. 후처리 스크립트나 수동 수정이 반드시 필요합니다.

좋았던 점과 아쉬운 점

좋았던 점은, 파일 복사 없이 리눅스에서 직접 프린트가 가능해졌다는 것입니다. 그리고 검증 실패의 원인 세 가지를 명확히 규명했습니다. 다만 아쉬운 점도 있습니다. 펌웨어 규칙이 비공개라서 ground truth(실제 OEM gcode)를 직접 구해 역추적해야 했습니다. OrcaSlicer 출력도 아직 후처리가 필요합니다. 그래서 다음 단계로는 자동 후처리 스크립트를 만들고, 상태 감시 데몬으로 오류 팝업이 뜨면 자동으로 대기하도록 만들려고 합니다.