가공 당일 오전, 막 셋업을 끝낸 머시닝센터에 NC 데이터를 올립니다. 전날 CAM 화면에서 충돌도 과삭도 없이 깔끔하게 통과한 공구경로였습니다. 그런데 사이클 스타트를 누르자마자 제어반에 알람이 뜨고, 프로그램이 첫 블록을 넘기지 못한 채 멈춥니다.

첫 반응은 대개 둘 중 하나입니다. ‘CAM이 잘못 계산한 건가’, 아니면 ‘프로그램을 처음부터 다시 짜야 하나’. 그런데 같은 형상을 다시 검토해도 CAM 시뮬레이션은 여전히 정상이라고 표시합니다. 화면 속 결과와 기계 위 결과가 서로 어긋나는 셈입니다.

이 사고는 담당자가 실수해서 생긴 것이 아닙니다. CAM이 보여주는 시뮬레이션과 기계가 실제로 읽는 G코드 사이에는, 눈으로 확인하기 어려운 구조적 간극이 있습니다. 원인을 알면 대응 순서도 달라집니다.

CAM에서 통과시킨 NC 데이터, 기계에 올리자 프로그램이 멈췄다

같은 도면, 같은 공구경로인데 화면과 현장의 결과가 다르다면 가장 먼저 의심해야 할 것은 CAM의 계산 능력이 아닙니다. 시뮬레이션이 정상으로 표시했다는 사실 자체가, 문제가 다른 곳에 있다는 신호이기 때문입니다.

프로그램을 다시 짜기 전에, 어디에서 화면과 기계가 갈라졌는지를 먼저 짚어야 합니다. 그 분기점은 거의 언제나 CAM과 G코드 사이, 즉 포스트프로세서 단계에 있습니다.

CAM 시뮬레이션은 G코드를 보지 않는다: 구조적 간극의 원인

CAM 내장 시뮬레이션은 대부분 포스트프로세서를 거치기 전 단계인 공구경로(CLS) 데이터를 기준으로 동작합니다. 공구가 어떤 좌표를 따라 움직이는지는 정밀하게 그려 주지만, 그 경로가 실제 G코드로 번역됐을 때의 구문 오류나 제어기별 문법 차이까지 읽어 주지는 않습니다.

CAM 결과를 기계가 알아듣는 G코드로 바꾸는 단계가 포스트프로세서입니다. 문제는 CNC 제어기마다 같은 동작을 표현하는 문법, 이른바 방언이 조금씩 다르다는 점입니다. 포스트프로세서가 이 방언을 정확히 맞추지 못하면, 그 오류는 CAM 화면에서는 보이지 않다가 기계 위에서야 알람으로 드러납니다.

국내 가공 현장이 쓰는 CNC 제어기는 거의 전량을 일본·독일산 수입에 의존하고 있습니다. 한국기계연구원이 정리한 국산 CNC 원천기술 현황을 보면 핵심 기술 대부분이 해외에 있는 상황이고, 브랜드와 버전마다 방언이 제각각입니다. 전담 인력을 두기 어려운 소규모 가공업체가 포스트프로세서를 직접 관리하기 까다로운 환경인 셈입니다.

포스트프로세서 오류 진단 4단계

도구를 새로 들이기 전에도, 원인 범위를 좁히는 4단계 점검만으로 상당수 오류를 잡을 수 있습니다. 비용을 들이지 않고 가장 먼저 해볼 수 있는 대응입니다.

1단계, 제어기 브랜드와 버전을 확인합니다. Fanuc 30i와 21i처럼 같은 브랜드 안에서도 버전이 다르면 지원하는 문법이 달라집니다. 기계 명판이나 제어반 화면에서 정확한 모델을 확인하고, 포스트프로세서가 그 모델에 맞춰져 있는지부터 점검합니다.

2단계, 원호(G2/G3) 출력 포맷을 확인합니다. 중심 좌표를 IJK 절대값으로 쓰는지 증분값으로 쓰는지, 180도가 넘는 원호에서 R 값 부호를 어떻게 처리하는지가 제어기마다 다릅니다. 현장에서 가장 자주 나오는 오류 유형이 바로 이 원호 포맷 불일치입니다.

3단계, 공구 교환 구문을 확인합니다. Fanuc과 Haas는 M06과 T 코드를 조합하고, Siemens는 CYCLE81, Heidenhain은 CYCL DEF 같은 대화식 구문을 씁니다. 포스트프로세서가 제어기에 맞게 정확히 변환하지 못하면 이 블록에서 프로그램이 멈춥니다.

4단계, 이송 단위(G20/G21)를 확인합니다. 인치와 밀리미터가 어긋나면 좌표와 이송속도가 통째로 잘못 해석됩니다. 1인치는 25.4mm이므로 단위 하나가 틀리면 그만큼 값이 어긋나는데, 이 오류는 CAM 시뮬레이션 화면에는 전혀 드러나지 않습니다.

이 네 가지는 G코드 오류가 현장에서야 드러나는 대표 패턴과도 대체로 일치합니다. 순서대로 짚어 나가면 원인을 한두 개 항목으로 좁힐 수 있습니다.

에어컷팅도 위험할 수 있다: G코드 기반 소프트웨어 시뮬레이션이 필요한 이유

진단을 끝냈다면 보통 에어컷팅으로 확인합니다. 공작물 없이 공중에서 프로그램을 돌려 보는 방식인데, 이때는 제어기가 실제 G코드를 그대로 실행합니다. 그래서 포스트프로세서 오류를 잡아낼 수는 있지만, 급이송(G0) 방향이 틀렸거나 공구 교환 구문이 잘못돼 있으면 그 자체가 기계 충돌로 이어질 수 있습니다.

예를 들어 Fanuc 제어기에서는 공구경 보정을 시작하거나 취소하는 블록에 직선·급이송(G00/G01) 이외의 이동이 섞이면 PS0034 알람이 발생합니다. 에어컷팅으로 이걸 확인한다는 것은, 위험을 기계 앞에서 직접 마주한다는 뜻이기도 합니다. 그래서 가능하면 소프트웨어 단계에서 먼저 걸러내는 편이 안전합니다.

G코드 기반 시뮬레이션은 CAM이 만든 공구경로가 아니라 포스트프로세싱이 끝난 실제 NC 코드를 읽어 들입니다. 덕분에 포스트프로세서 오류를 검출하면서도 기계를 물리적으로 위험에 노출시키지 않습니다. 에어컷팅이 주던 확신을 기계 충돌 위험 없이 미리 얻는 방법인 셈입니다.

코드 기반 검증을 지원하는 CAM 소프트웨어도 있다

앞서 설명한 G코드 기반 시뮬레이션을, 별도 도구 없이 CAM 안에서 지원하는 경우도 있습니다. 포스트프로세싱이 끝난 NC 코드를 그대로 읽어 들여, 제어기 종류에 맞춘 거동을 미리 확인하는 방식입니다.

국내에서 접할 수 있는 도구 가운데 ENCYCAM이나 Siemens NX CAM 등이 이런 코드 기반 검증을 지원합니다. 일부 도구는 단순히 NC 코드를 해석하는 데서 더 나아가, 장비 키네마틱 모델까지 함께 돌려 충돌이나 오버트래블을 검증하기도 합니다. 다만 도구마다 재현 범위와 지원하는 제어기가 다르므로, 실제 도입을 검토한다면 자사 제어기 환경에서 어디까지 확인되는지를 직접 따져 보는 편이 좋습니다.

핵심은 포스트프로세서를 수정한 뒤 G코드 기반 시뮬레이션으로 다시 검증하는 루프입니다. 수정과 재검증을 짧게 반복하는 구조가, 현장에서 실질적인 안전망이 됩니다.

직접 수정할 것인가, CAM 벤더 기술지원을 요청할 것인가: 판단 기준

모든 오류를 외부에 맡길 필요는 없습니다. 아크 포맷, 단위 모드, 공구 교환 코드처럼 파라미터 한두 개 수준의 불일치는, 제어기 방언 문서를 참고해 직접 조정할 수 있는 범위입니다.

반면 5축 후처리, 매크로 변수, 서브프로그램 중첩 구조에서 생기는 오류는 제어기 인터프리터 내부 동작을 알아야 진단할 수 있습니다. 이런 경우는 무리해서 손대기보다 CAM 벤더의 기술지원을 요청하는 편이 빠르고 안전합니다.

소규모 가공업체라면 한 가지 습관을 더 권합니다. 장비를 새로 들이거나 제어기 버전을 바꿀 때, 포스트프로세서 재검증 일정을 공정 계획 처음부터 넣어 두는 것입니다. 사고가 난 뒤가 아니라, 셋업 단계에서 미리 시간을 확보해 두는 방식입니다.

정리: CAM 시뮬레이션과 G코드 검증은 역할이 다르다

CAM 시뮬레이션과 G코드 검증은 어느 하나가 다른 하나를 대체하는 관계가 아닙니다. 공구경로의 형상 충돌은 CAM이 잡고, 제어기 방언에서 비롯된 오류는 G코드 기반 검증이 잡습니다. 둘은 경쟁이 아니라 순서입니다.

• CAM 시뮬레이션은 공구경로 형상 충돌을, G코드 기반 시뮬레이션은 제어기 방언 오류를 잡습니다.
• 진단 4단계는 제어기 확인, 원호 포맷, 공구 교환 구문, 이송 단위 점검 순서로 진행합니다.
• 에어컷팅은 실제 G코드를 실행하므로, 소프트웨어 검증으로 위험을 먼저 걸러내는 편이 안전합니다.
• 파라미터 수준 불일치는 직접, 인터프리터 내부 동작이 얽힌 오류는 벤더 기술지원으로 나눠 대응합니다.

도구를 새로 검토하기 전에도 진단 4단계로 원인 범위를 좁힐 수 있습니다. 다음 장비 도입이나 제어기 교체를 앞두고 있다면, 포스트프로세서 재검증을 공정 계획 첫 단계에 넣는 것부터 시작해 보세요.

이처럼 빠르게 변화하는 CAx의 최신 트렌드와 심층 분석을 놓치고 싶지 않으시다면, 지금 바로 [멤버십 가입]과 [뉴스레터 신청]을 하고 이거 DAM에서 발행하는 다양한 컨텐츠와 정보를 받아보세요.