비전 판정은 끝났는데 PLC는 왜 늦게 알까

INTERFACE

이 셋업에서 판정을 늦추는 가장 긴 구간은 추론 25 ms보다 영상 전송 106.9 ms이고, 늦게 온 결과를 제자리에 붙이는 열쇠는 트리거 번호입니다.

트리거 입력부터 결과 출력까지 비전 쪽 지연을 여섯 구간으로 나누고, 디지털 출력과 주기형 네트워크의 최악 대기, 결과가 다음 트리거 뒤로 밀리는 비율을 계산했습니다.

읽는 시간 약 12분

검사 로그에는 판정이 25 ms 만에 끝났다고 찍혀 있는데, 설비 쪽에서는 결과가 늦게 도착했다고 합니다. 비전 담당자는 추론 시간을 보여 주고, 제어 담당자는 결과를 받은 시각을 보여 주죠. 두 숫자 사이의 공백은 누구의 로그에도 없습니다.

그 공백이 커지면 늦게 도착한 결과가 다른 부품의 결과로 읽히는 순간이 옵니다. 결과에 부품을 가리키는 번호가 없으면 한 번 밀린 결과가 뒤따르는 부품들의 판정을 줄줄이 어긋나게 만들고, 불량이 양품으로 기록된 채 지나갑니다.

그래서 저는 트리거에서 결과 출력까지를 비전 쪽에서 구간별로 쪼개 각 구간의 최악값을 재고, 결과에 트리거 번호와 타임스탬프를 붙여 내보냅니다. 예로 들 셋업은 무광 사출 커버의 100 μm 결함을 4,096 × 3,000 px 카메라로 보는 라인이고, 부품은 150 ms마다 한 개씩 트리거를 받는다고 가정합니다. PLC가 결과를 읽는 주기와 로직은 PLC 쪽 설계라서 별도 검토가 필요하고, 여기서는 비전 시스템이 책임질 수 있는 구간만 계산합니다.

지연은 여섯 구간의 합이다

비전 쪽 지연은 추론 시간 하나로 끝나지 않고, 트리거 입력부터 결과 출력까지 여섯 구간의 합으로 쌓입니다. 트리거 입력(입력 필터와 지연), 노출, 센서 읽기와 전송, 대기열(앞 영상을 처리하는 동안 기다리는 시간), 처리(전처리, 추론, 판정), 결과 출력(디지털 출력이나 네트워크 메시지)입니다. 벤치마크의 추론 시간은 다섯 번째 구간의 일부일 뿐이에요.

숫자를 넣으면 순서가 뒤집힙니다. 4,096 × 3,000 px 8비트 영상 한 장은 12.29 MB이고, 1GigE 링크의 실효 대역폭¹을 약 115 MB/s로 가정하면 전송에만 106.9 ms가 걸립니다. 노출을 0.2 ms, 처리를 평소 25 ms로 두면 가장 긴 구간은 추론이 든 처리보다 네 배 넘게 긴 전송이고, 셋을 합친 132.1 ms는 트리거 간격 150 ms 안에 들어옵니다. 제 눈에는 이 뒤집힌 순서가 지연 이야기의 출발점입니다. 인터페이스 자체를 바꾸는 계산은 인터페이스 대역폭 글에 있습니다.

구간마다 시작과 끝에 타임스탬프를 찍어야 어디서 늦었는지 말할 수 있습니다. 카메라의 노출 종료 이벤트가 싣는 타임스탬프와 프레임 ID를 기준점으로 쓰면, 노출과 전송의 경계를 카메라 시계로 기록할 수 있어요. GenICam SFNC²는 이 이벤트에 타임스탬프와 프레임 ID를 싣는 항목을 정의합니다. 처리 시간은 평균 말고 p99 지연³으로 남기고, 구간별로 쪼개는 방법은 p99 지연 예산 글에 있습니다.

출력 경로가 최악 대기의 모양을 바꾼다

결과를 디지털 출력 신호로 내보내는지, 산업용 이더넷 메시지로 내보내는지에 따라 최악 지연의 모양이 달라집니다. 디지털 출력⁴은 비전 장치가 출력을 바꾸는 순간 배선으로 전달되니, 비전 쪽 지연은 출력을 갱신하는 시점에서 닫힙니다. 전선은 기다리지 않습니다. 반면 EtherNet/IP에서 주기형(Cyclic) 트리거로 설정한 I/O 연결은 RPI⁵라는 정해진 간격으로 데이터를 보냅니다.

그림 위쪽 A는 결과가 준비된 순간 신호가 올라가는 디지털 출력이고, B는 다음 패킷 시점까지 기다리는 주기형 메시지입니다. 결과가 준비된 직후라도 B는 다음 전송까지 기다려야 하고, 최악의 경우 그 대기는 한 주기에 가깝습니다. RPI를 10 ms로 설정했다면 처리가 끝난 시점에 따라 결과 전송까지 0~10 ms가 더해져요. 10 ms가 최악입니다. 저라면 이 대기를 예산표에 따로 한 줄로 적어 둡니다. 그 데이터를 PLC가 로직에서 읽는 시점은 PLC 쪽 설계라 별도 검토가 필요합니다.

PLC 통신 지연을 이야기할 때 IEC 61131-3⁶이 함께 거론되곤 하지만, 이 규격은 PLC 프로그래밍 언어를 다루고 통신은 같은 시리즈의 5부가 다룹니다. 비전 쪽 책임은 결과가 준비된 시각과 실제로 링크에 실린 시각을 나눠 기록하는 데까지입니다. 저라면 결과가 마감에 가까울 때 네트워크 주기를 줄이기 전에, 판정 비트는 디지털 출력으로, 상세 데이터는 네트워크로 나누는 이원화를 먼저 검토합니다.

결과에는 트리거 번호를 붙인다

결과 메시지에는 판정값과 함께 트리거 번호(또는 프레임 ID)와 노출 타임스탬프를 반드시 담습니다. 제가 결과 형식에서 맨 처음 정하는 필드도 이 둘입니다. 처리 시간이 흔들리는 시스템에서 ‘다음에 도착한 결과는 다음 부품의 결과’라는 가정은 한 번의 지연으로 무너지거든요. 번호가 있으면 수신 측은 늦게 도착한 결과를 해당 부품에 정확히 붙이거나, 마감을 넘긴 결과를 ‘판정 불가’로 분명하게 떼어 낼 수 있습니다.

얼마나 자주 무너지는지 계산해 봅니다. 노출 0.2 ms와 전송 106.9 ms를 빼면, 결과가 다음 트리거(150 ms) 전에 나오려면 처리와 출력 대기가 합쳐서 42.9 ms 안에 끝나야 합니다. 처리 시간의 p99가 60 ms라면, 60 ms를 넘는 1%는 출력 대기가 0이어도 모두 다음 트리거 뒤에 도착합니다. 150 ms마다 한 개씩 8시간이면 192,000개이고, 그 1%는 1,920개예요. 결코 적지 않습니다. 번호 없이 도착 순서로 붙이는 수신 측이라면, 이 1,920번이 모두 한 칸씩 밀린 매칭의 출발점이 될 수 있습니다.

세 숫자가 말하는 순서는 분명합니다. 가장 긴 줄은 전송이고, 출력 경로는 최악 10 ms를 더하며, 늦게 도착하는 1%는 번호로만 제자리를 찾습니다. 카메라와 비전 PC, PLC의 시계가 서로 다르면 타임스탬프끼리 비교할 수 없으니, GigE Vision 2.0에 통합된 PTP⁷로 여러 장치의 시계를 맞춰 같은 시간축에 올립니다.

트리거 1001의 결과가 마감을 넘겨 트리거 1002 뒤에 도착해도, 번호가 붙어 있으면 1001번 부품에만 적용되고 1002번 판정과 섞이지 않습니다. 번호가 없으면 수신 측은 이 결과를 1002번의 것으로 읽을 수 있고, 그 순간부터 한 칸씩 밀린 매칭이 이어집니다. 마감을 넘긴 결과를 어떻게 처리할지는 설비 쪽 결정이지만, 그 결정을 가능하게 하는 번호와 시각은 비전 쪽이 내줘야 합니다. 제 기준으로 번호 없는 결과 메시지는 사양서에서 받지 않습니다.

100 μm 결함을 지키는 지연 대책

지연 대책을 사양서 줄로 옮기면 아래와 같습니다. 해상도를 깎는 대책이 왜 마지막인지가 ① 줄에 들어 있습니다.

항목	기준값	조건·근거	풀어 쓰면
① 최소 불량 사이즈	100 μm = 4.1칸(24.4 μm/px)	2×2 비닝으로 전송을 26.7 ms로 줄이면 48.8 μm/px에서 2.05칸	해상도를 깎는 지연 대책은 마지막
② 센서 · 인터페이스	4,096 × 3,000 px 8비트(12.29 MB/장), 1GigE 실효 약 115 MB/s 가정	전송만 106.9 ms/장, 여섯 구간 가운데 최대	가장 긴 줄은 추론보다 전송
② WD	물체 거리 약 202 mm 기준, 실제 WD는 제조사 데이터로 확정	재설치 뒤에도 노출 조건이 유지되도록 도면으로 고정	거리가 바뀌면 노출과 분해능이 같이 바뀐다
③ 타임스탬프 기준	노출 종료 이벤트 타임스탬프 + 프레임 ID	GenICam SFNC 3.66, 15.5	셔터가 닫힌 순간을 기준 시각으로
③ 결과 메시지 필드	판정값, 트리거 번호, 노출 타임스탬프, 처리 완료 시각	수신 측 번호 매칭	결과마다 이름표를 붙인다
③ 출력 경로	판정 비트는 디지털 출력, 상세 데이터는 네트워크(RPI 10 ms 가정)	네트워크 최악 대기 약 1 RPI	급한 것은 전선으로
③ 감시 지표	구간별 p99, 다음 트리거 뒤 도착 건수	처리 p99 60 ms면 8시간 192,000개 중 1,920개 이상	평균 대신 늦게 온 개수를 센다

이 조건에서 가장 긴 구간은 추론 25 ms보다 전송 106.9 ms입니다. 네트워크 출력의 주기 대기는 최대 한 RPI에 그치지만 전송은 영상 한 장마다 되풀이되니, 대책의 우선순위는 전송, 대기열, 출력 경로 순서가 됩니다. 2×2 비닝⁸으로 전송을 26.7 ms로 줄이는 대책은 분해능을 48.8 μm/px로 거칠게 만들어 100 μm 결함을 2.05칸으로 떨어뜨리니, 세 칸 기준을 지키려면 마지막 선택지로 남깁니다. 해상도는 마지막입니다.

이 방법을 고르지 않는 편이 나은 경우도 있습니다. 판정 비트 하나만 필요하고 처리 시간이 언제나 한 트리거 간격 안에 끝난다면, 번호 매칭 없이 하드웨어 트리거와 디지털 출력만으로 구성하는 편이 단순하고 검증하기 쉽습니다. 카메라 여러 대를 동시에 쓴다면 카메라마다 트리거 배선을 까는 대신, PTP로 시계를 맞추고 예약 액션 커맨드로 이더넷을 통해 동시에 촬영하는 구성이 배선을 줄입니다. 처리 여유가 큰 오프라인 검사라면 구간 분해의 순위가 내려가고요. 부품이 광택 금속으로 바뀌면 노출 시간과 조명이 달라져 지연 분포도 바뀌니, 실제 분포는 샘플 테스트 전 확언 불가입니다.

구간별 타임스탬프를 찍어 지연을 나눠 보는 일은 비전 시스템을 설비에 붙이는 일을 처음 맡는 사람에게 가장 먼저 권할 만한 연습입니다. 설비를 운영하는 쪽에서 보면, 결과 메시지에 번호 필드 하나를 넣는 비용이 한 칸씩 밀린 판정을 거슬러 추적하는 비용보다 훨씬 작습니다. 이 글은 기술 설명이며 투자 권유가 아닙니다. 자세한 내용은 면책조항을 참고하세요.

현장 노트

설비 기록에 판정이 가끔 한 칸씩 밀려 있다는 연락이 오면, 저는 먼저 결과 메시지의 필드 목록을 받아 봅니다. 트리거 번호와 노출 타임스탬프가 없다면 전송 대기로 한 번 늦은 결과가 다음 부품의 판정으로 읽혔을 가능성이 크기 때문입니다. 번호가 있다면 구간별 타임스탬프로 다음 트리거 뒤에 도착한 결과의 개수를 세고, 그 개수가 처리 p99로 계산한 1%와 맞는지 봅니다. 재설치를 거친 라인이라면 WD와 노출 시간이 도면 값 그대로인지도 함께 확인합니다.

현장 체크포인트

현장 노트의 확인 순서를 사양서 점검 항목으로 옮기면 아래와 같습니다.

• 재설치 뒤에도 WD와 노출 조건(노출 시간, 광량)이 바뀌지 않도록 도면으로 확정되었는가? (거리가 바뀌면 노출과 분해능이 함께 바뀐다)
• 여섯 구간 각각에 시작과 끝 타임스탬프를 기록하는가? (어디서 늦었는지 말하려면)
• 결과 메시지에 트리거 번호(프레임 ID)와 노출 타임스탬프가 있는가? (늦은 결과를 제자리에 붙이려면)
• 네트워크 출력이라면 RPI를 알고, 최악 대기 한 주기를 예산에 넣었는가? (RPI 10 ms면 최대 10 ms)
• 평균 대신 p99와 다음 트리거 뒤 도착 건수로 판단하는가? (처리 p99 60 ms면 1% 이상)
• PLC 쪽 읽기 주기와 로직 지연은 별도 검토 대상이라는 경계를 문서로 합의했는가? (비전 쪽 책임 범위)

자주 묻는 질문

디지털 출력이면 지연 걱정이 없나요?

출력 자체의 대기는 거의 없지만 앞의 다섯 구간은 그대로입니다. 이 셋업이라면 전송 106.9 ms가 그대로 남고, 처리 시간이 흔들리면 결과가 다음 트리거 뒤로 밀리는 일도 똑같이 생깁니다. 디지털 출력을 쓰더라도 판정 비트를 번호가 실린 네트워크 메시지와 짝지어 확인할 방법이 필요한 이유입니다.

RPI를 1 ms로 줄이면 해결되나요?

출력 대기는 최대 1 ms로 줄지만 네트워크 부하와 장치 처리량이 늘어납니다. 이 셋업에서 RPI가 차지하는 몫은 최대 10 ms로 전송 106.9 ms보다 훨씬 작아서, 주기를 줄이는 효과는 제한적입니다. RPI 설정 범위는 장치와 PLC에 따라 달라서 별도 검토가 필요합니다.

카메라 시계와 비전 PC 시계가 다르면 어떻게 하나요?

PTP로 두 시계를 맞추거나, 적어도 노출 종료 이벤트의 카메라 타임스탬프와 PC 수신 시각을 같은 기록에 남겨 둘의 차이를 따로 관리합니다. 시계가 맞지 않으면 전송 구간의 길이를 잴 수 없습니다.

용어 풀이

• [1] 대역폭 bandwidth, MB/s
  링크가 1초에 실어 나를 수 있는 데이터 양입니다. 영상 한 장의 크기를 이 값으로 나누면 전송 시간이 나옵니다. ↩
• [2] GenICam SFNC Standard Features Naming Convention
  머신비전 카메라의 기능 이름과 동작을 통일한 규약입니다. 노출 종료 이벤트, 타임스탬프 같은 항목을 제조사와 상관없이 같은 이름으로 찾을 수 있습니다. ↩
• [3] p99 지연 99th percentile latency
  지연 시간을 짧은 순서로 늘어놓았을 때 99%째에 해당하는 값입니다. 100번 중 1번 늦는 꼬리를 드러냅니다. ↩
• [4] 디지털 출력 digital output, DO
  켜짐과 꺼짐 두 상태로 신호를 내보내는 전기 출력입니다. 결과가 정해지는 순간 바로 바뀌어 대기가 거의 없습니다. ↩
• [5] RPI Requested Packet Interval
  EtherNet/IP의 주기형 연결에서 데이터를 주고받는 간격입니다. 버스 정류장의 배차 간격처럼, 결과가 준비돼도 다음 차례까지 기다립니다. ↩
• [6] IEC 61131 PLC standard series
  PLC에 관한 국제 표준 묶음입니다. 3부는 프로그래밍 언어, 5부는 통신을 다룹니다. ↩
• [7] PTP Precision Time Protocol, IEEE 1588
  네트워크로 연결된 장치들의 시계를 정밀하게 맞추는 규약입니다. 시계가 맞아야 장치마다 찍은 타임스탬프를 같은 시간축에서 비교할 수 있습니다. ↩
• [8] 비닝 binning
  이웃한 화소 여러 개를 하나로 묶어 읽는 방식입니다. 2×2 비닝은 데이터를 4분의 1로 줄이지만 화소 하나가 맡는 길이가 두 배가 됩니다. ↩

참고 자료

• ODVA, Quick Start for Vendors Handbook: A Guide for EtherNet/IP Developers (PUB213R0): RPI 정의(용어집), Cyclic·Change of State 트리거
• EMVA, GenICam SFNC v2.7: Timestamp(3.66), Exposure End Event(15.5, 타임스탬프와 프레임 ID 항목 포함)
• LUCID, Multi Camera Synchronization using PTP and Scheduled Action Commands: PTP(IEEE 1588)의 GigE Vision 2.0 통합, 이더넷 동시 트리거
• IEC 61131 (Wikipedia): Part 3 Programming languages, Part 5 Communications
• 계산식: 전송 시간 = 영상 크기 ÷ 실효 대역폭, 처리·출력 예산 = 트리거 간격 − 노출 − 전송, 늦은 결과 수 ≥ 부품 수 × (1 − 0.99). 계산 가정: 4,096 × 3,000 px 8비트, 1GigE 실효 115 MB/s, 노출 0.2 ms, 처리 평소 25 ms·p99 60 ms, 트리거 간격 150 ms, RPI 10 ms

함께 읽으면 좋은 글 — 평균 지연이 마감 안에 있어도 안전하지 않은 이유 · 카메라 인터페이스 대역폭이 분해능을 결정한다 · 엣지 AI 추론 지연은 NPU보다 카메라 인터페이스가 먼저 정한다