2026 머신비전 프레임 드롭 원인과 해결법 총정리

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

검사 화면이 순간적으로 멈추거나 저장된 이미지의 번호가 건너뛴다면 카메라 고장부터 의심하기 쉽습니다. 그러나 산업 현장에서 발생하는 머신비전 프레임 드롭은 카메라 자체보다 노출 시간, 트리거 신호, 전송 대역폭, 버퍼 설정, 저장 장치가 서로 맞지 않아 생기는 경우가 더 많습니다.

특히 생산 속도를 높인 직후 불량 검출률이 흔들린다면 단순한 화면 끊김으로 넘겨서는 안 됩니다. 누락된 한 프레임이 미검사 제품 한 개를 의미할 수 있기 때문입니다. 아래 순서대로 원인을 분리하면 장비를 무작정 교체하지 않고도 병목 구간을 빠르게 찾을 수 있습니다.

프레임 드롭인지 먼저 정확히 판별하는 법

화면 지연과 실제 이미지 누락을 구분합니다

모니터에 보이는 영상이 끊긴다고 해서 반드시 카메라 프레임이 손실된 것은 아닙니다. 검사 프로그램은 영상을 정상적으로 수신하면서도 화면 표시 주기를 낮추거나, 그래픽 처리 부하 때문에 미리보기만 늦게 갱신할 수 있습니다. 반대로 화면은 부드러워 보여도 검사 큐에서 오래된 이미지를 폐기하는 설정 때문에 실제 판정용 프레임이 빠질 수 있습니다.

가장 먼저 카메라의 Frame ID, Block ID 또는 타임스탬프를 로그에 남겨 연속성을 확인하세요. 예를 들어 10521 다음 값이 10523이라면 전송 또는 수집 단계에서 한 장이 누락된 것입니다. 번호는 연속인데 제품 위치와 이미지가 어긋난다면 프레임 손실보다 트리거 지연, PLC 신호 순서 또는 처리 큐 정체를 살펴야 합니다.

• 카메라 획득 수: 센서가 실제로 생성한 프레임 수를 확인합니다.
• 수신 완료 수: PC 또는 비전 컨트롤러가 정상 수신한 이미지 수를 비교합니다.
• 검사 완료 수: 알고리즘이 판정을 끝낸 수량을 별도로 기록합니다.
• 저장 완료 수: 디스크에 기록된 파일 수를 생산 카운터와 대조합니다.
• 타임스탬프 간격: 목표 주기보다 갑자기 길어진 구간이 있는지 확인합니다.

사람의 시각과 산업용 비전은 모두 대상을 받아들이고 해석한다는 공통점이 있지만, 머신비전은 신호의 연속성을 숫자로 검증할 수 있다는 차이가 있습니다. 개념적 배경은 vision 용어 설명을 참고하고, 현장에서는 반드시 장비 카운터와 로그를 근거로 판단해야 합니다.

현장 팁: 증상이 발생한 시각, 제품 번호, Frame ID, 처리 시간, CPU 사용률을 같은 로그 행에 남기면 재현이 어려운 간헐 장애도 추적하기 쉬워집니다.

노출 시간과 트리거 충돌부터 점검하세요

생산 주기보다 촬영 시간이 긴지 계산합니다

라인 속도를 높였는데 기존 노출 시간을 그대로 유지하면 다음 트리거가 들어올 때 카메라가 아직 이전 프레임을 촬영하거나 읽는 중일 수 있습니다. 예를 들어 제품이 10ms마다 통과하는데 노출 8ms, 센서 리드아웃과 전송 준비에 추가 시간이 필요하다면 안전 여유가 거의 없습니다. 이때 카메라는 새 트리거를 무시하거나 지연시켜 제품과 이미지의 대응 관계를 깨뜨릴 수 있습니다.

먼저 카메라 설정 화면에서 Trigger Overrun, Frame Trigger Wait, Exposure Active 같은 상태 신호와 오류 카운터를 확인하세요. 노출 시간을 짧게 했더니 영상이 어두워진다면 게인만 크게 올리기보다 조명의 밝기, 조사 거리, 렌즈 조리개와 스트로브 동기화를 함께 조절하는 편이 좋습니다. 과도한 게인은 노이즈를 키워 검사 임계값까지 흔들 수 있습니다.

1. 라인의 최소 제품 간격을 밀리초 단위로 측정합니다.
2. 노출 시간과 센서 리드아웃 시간을 카메라 사양에서 확인합니다.
3. 트리거 지연과 PLC 출력 펄스 폭을 측정합니다.
4. 현재보다 낮은 프레임레이트로 시험해 누락이 사라지는지 확인합니다.
5. 조명 밝기를 높이고 노출을 줄인 뒤 밝기와 블러를 다시 비교합니다.

전기적 트리거 품질도 놓치지 마세요

센서 출력과 카메라 입력의 전압 규격이 맞지 않거나 케이블이 인버터 및 모터 전원선과 나란히 배치되면 노이즈가 트리거로 오인될 수 있습니다. 펄스 폭이 카메라가 요구하는 최소 입력 시간보다 짧은 경우에도 신호가 간헐적으로 무시됩니다. 소프트웨어 로그만으로 확신하기 어렵다면 오실로스코프나 로직 분석기로 카메라 단자에서 실제 파형을 측정해야 합니다.

• PLC 출력 방식이 NPN인지 PNP인지 카메라 입력과 대조합니다.
• 입력 지연 필터가 너무 길어 정상 펄스를 제거하지 않는지 확인합니다.
• 차폐 케이블의 접지 방식과 커넥터 체결 상태를 점검합니다.
• 여러 카메라를 동기화할 때 공통 접지와 기준 클록 구성을 확인합니다.

트리거 없이 연속 촬영에서는 정상인데 외부 트리거에서만 누락된다면 네트워크보다 신호 품질과 촬영 타이밍을 먼저 조사하는 것이 효율적입니다. 반대로 연속 촬영에서도 동일한 주기로 손실된다면 다음 단계인 인터페이스 대역폭 점검으로 넘어가세요.

GigE·USB3 전송 병목을 단계별로 해결하는 법

필요 대역폭을 감으로 판단하지 않습니다

카메라의 전송량은 대략 가로 픽셀 × 세로 픽셀 × 픽셀당 바이트 × 초당 프레임으로 계산할 수 있습니다. 2448×2048 해상도의 8비트 영상을 초당 30장 전송하면 헤더를 제외해도 약 150MB/s가 필요합니다. 이 수치는 일반적인 1GbE 링크의 실효 처리량을 넘으므로 해상도, 프레임레이트, 픽셀 형식 또는 인터페이스 구성을 바꿔야 합니다.

12비트 센서라고 해서 항상 정확히 1.5바이트로 전송되는 것은 아닙니다. 카메라의 픽셀 포맷에 따라 16비트 컨테이너를 사용하거나 패킹 형식을 적용하므로 실제 페이로드 크기를 SDK 통계에서 확인해야 합니다. 여러 대의 GigE 카메라가 하나의 스위치 업링크나 동일한 네트워크 어댑터를 공유한다면 각 카메라는 정상이어도 합산 구간에서 병목이 생깁니다.

인터페이스별 조정 순서가 다릅니다

GigE Vision 환경에서는 카메라와 네트워크 카드가 지원한다면 점보 프레임을 같은 값으로 설정하고, 패킷 크기와 패킷 간 지연을 조정합니다. 단, 중간 스위치 한 곳이라도 큰 패킷을 지원하지 않으면 오히려 통신 장애가 생길 수 있습니다. 전용 NIC 사용, 에너지 절약 기능 해제, 수신 버퍼 확대도 효과가 있지만 회사 네트워크 정책과 드라이버 권장값을 먼저 확인하세요.

USB3 Vision에서는 짧고 품질이 검증된 케이블을 사용하고, 여러 카메라가 동일한 USB 호스트 컨트롤러를 공유하는지 장치 트리로 확인합니다. 케이블 길이만 보고 판단하지 말고 커넥터 잠금, 허브 전원, 포트별 전력 공급도 검사하세요. 장비 진동으로 커넥터가 아주 조금씩 움직여도 간헐적인 재전송이나 장치 재연결이 발생할 수 있습니다.

• ROI를 줄여 전송량이 감소할 때 증상이 사라지는지 시험합니다.
• 픽셀 포맷을 Mono8 등 낮은 데이터량으로 바꿔 비교합니다.
• 카메라 두 대의 촬영 시점을 수백 마이크로초 이상 분산합니다.
• 패킷 손실, 재전송, 불완전 버퍼 카운터를 각각 기록합니다.
• 사무용 트래픽과 비전 카메라 트래픽을 물리적으로 분리합니다.

설정을 한꺼번에 바꾸면 어떤 조치가 효과를 냈는지 알 수 없습니다. ROI, 프레임레이트, 패킷 크기, 버퍼를 한 항목씩 변경하고 동일한 제품 수로 반복 시험하세요.

PC 처리 지연과 이미지 버퍼 문제를 고치는 법

평균 처리 시간보다 최악의 지연을 봅니다

검사 알고리즘의 평균 실행 시간이 촬영 주기보다 짧더라도 프레임 드롭은 발생할 수 있습니다. 가비지 컬렉션, 운영체제 업데이트, 백신 검사, 로그 압축 또는 다른 프로그램의 순간적인 부하가 처리 시간을 급격히 늘릴 수 있기 때문입니다. 평균 12ms라는 숫자만 보지 말고 95·99백분위 처리 시간과 최대값을 함께 확인해야 합니다.

촬영 스레드에서 이미지 분석과 파일 저장까지 모두 처리하면 디스크가 잠시 느려지는 순간 카메라 수신도 막힙니다. 일반적으로 획득, 검사, 표시, 저장을 분리하고 제한된 크기의 큐로 연결하는 구조가 안정적입니다. 다만 버퍼를 무작정 크게 만들면 손실이 지연으로 바뀔 뿐이며, 오래된 제품 이미지가 뒤늦게 판정되는 더 위험한 문제가 생길 수 있습니다.

1. 획득 단계: 프레임을 빠르게 받아 메모리 버퍼에 전달합니다.
2. 검사 단계: 필요한 ROI만 처리하고 실행 시간을 기록합니다.
3. 표시 단계: 모든 영상을 그리지 말고 화면 갱신률을 제한합니다.
4. 저장 단계: 비동기 저장을 사용하되 큐 초과 정책을 명시합니다.
5. 경보 단계: 큐 사용률이 기준을 넘으면 생산 장비에 즉시 알립니다.

저장 장치와 메모리 복사 비용을 확인합니다

NG 이미지를 원본 그대로 저장하거나 모든 프레임을 무손실 압축하면 순간 쓰기량이 크게 증가합니다. SSD의 표시 속도는 연속 쓰기 기준인 경우가 많으며, 용량이 차거나 캐시가 소진된 뒤에는 성능이 떨어질 수 있습니다. 남은 공간, 쓰기 지연, 디스크 상태를 모니터링하고 장기 보관은 생산 중인 저장 경로와 분리하세요.

컬러 변환, 이미지 회전, 포맷 변환을 여러 단계에서 반복하면 메모리 대역폭과 CPU를 불필요하게 사용합니다. 카메라가 제공하는 원본 포맷을 검사 알고리즘이 직접 처리할 수 있는지 확인하고, 가능하다면 불필요한 복사를 줄이세요. 산업 비전이 인간의 시각 정보 처리와 다른 핵심은 처리 경로를 계측하고 재현 가능한 기준으로 최적화할 수 있다는 점입니다.

• CPU 전체 사용률뿐 아니라 코어별 사용률을 확인합니다.
• 메모리 증가와 페이지 파일 사용 여부를 장시간 기록합니다.
• GPU 추론 시 전처리와 메모리 전송 시간을 따로 측정합니다.
• 화면 표시를 끈 상태와 켠 상태의 손실률을 비교합니다.
• 이미지 저장을 중지한 시험으로 디스크 병목을 분리합니다.

재발을 막는 현장 검증 절차와 유지관리 기준

부품 교체 전에 원인 분리 시험을 진행합니다

프레임 드롭은 조건이 여러 개 겹칠 때만 나타나는 경우가 많아 1~2분 시험으로는 해결 여부를 판단하기 어렵습니다. 정상 생산 속도보다 높은 부하, 최대 해상도, 여러 카메라의 동시 트리거, 이미지 저장 활성화 등 실제 최악 조건을 만들어 충분한 시간 동안 검증해야 합니다. 검사 수량이 적은 시험이라면 드문 손실을 놓칠 수 있습니다.

권장 순서는 저속 촬영에서 기준값을 확보한 뒤 프레임레이트를 단계적으로 높이는 방식입니다. 이후 저장 기능, 화면 표시, 추가 카메라를 하나씩 켜며 어느 시점부터 카운터가 어긋나는지 찾습니다. 케이블이나 NIC를 교체할 때도 이전 조건과 같은 시험 시나리오를 사용해야 교체 효과를 객관적으로 비교할 수 있습니다.

1. 프레임 번호가 연속인지 최소 수만 장 이상 확인합니다.
2. 트리거 입력 수와 카메라 획득 수의 차이를 계산합니다.
3. 불완전 이미지와 패킷 재전송 카운터를 기록합니다.
4. 처리 큐 최대 깊이와 최악의 검사 시간을 저장합니다.
5. CPU·메모리·네트워크·디스크 사용량의 최고값을 남깁니다.
6. 재부팅 및 장시간 가동 후에도 같은 결과인지 재검증합니다.

예산은 병목이 확인된 항목에만 투입합니다

단순한 설정 문제라면 ROI 조정, 패킷 간 지연 설정, 표시 주기 제한만으로 해결할 수 있어 추가 비용이 거의 들지 않습니다. 반면 케이블·NIC·산업용 스위치 교체는 구성에 따라 수만 원에서 수십만 원 이상, 고속 인터페이스 카메라와 프레임그래버 도입은 채널과 해상도에 따라 수백만 원 이상이 될 수 있습니다. 가격은 제조사, 인증, 케이블 길이, 환경 등급에 따라 크게 달라지므로 정확한 견적 전에 측정 자료를 준비하세요.

프레임 손실이 없더라도 월 1회 정도 커넥터 풀림, 케이블 손상, 저장 공간, 오류 카운터를 확인하는 것이 좋습니다. 라인 속도나 카메라 설정을 변경할 때는 계산된 대역폭과 검증 결과를 설비 이력에 남기세요. 기술적 시야를 확장하고 시스템 목표를 설계하는 관점은 VISION 관련 서적처럼 비전의 확장된 의미를 다루는 자료에서도 아이디어를 얻을 수 있습니다.

• 매일: 획득 수, 검사 수, 생산 수량의 차이를 자동 확인합니다.
• 매주: 최대 처리 시간과 버퍼 최고 사용률의 변화를 비교합니다.
• 매월: 케이블, 전원, 접지, 냉각 상태를 점검합니다.
• 변경 시: 해상도·노출·프레임레이트별 대역폭을 다시 계산합니다.
• 장애 시: 설정을 초기화하기 전에 로그와 구성 파일을 보존합니다.

증상별로 바로 확인하는 실무 Q&A

현장에서 자주 만나는 네 가지 상황

Q. 생산 속도를 올릴 때만 프레임이 빠집니다.
노출과 센서 리드아웃 시간이 새 제품 주기 안에 들어가는지 먼저 계산하세요. 이후 ROI를 줄여도 같은 현상이 발생하는지 시험하면 트리거 한계와 전송 대역폭 문제를 구분할 수 있습니다. ROI 축소로 증상이 사라지면 네트워크나 USB 전송량이 병목일 가능성이 큽니다.

Q. 카메라 두 대를 동시에 켜면 한쪽만 불안정합니다.
동일 NIC, 스위치 업링크 또는 USB 호스트 컨트롤러를 공유하는지 확인하세요. 두 카메라의 트리거를 약간 분산하고 각각의 대역폭 제한을 설정한 뒤 비교합니다. 특정 카메라를 다른 포트로 옮겼을 때 문제가 따라가는지도 중요한 단서입니다.

Q. 검사 화면만 끊기고 생산 카운트는 정상입니다.
표시 스레드의 갱신률을 낮추고 Frame ID와 검사 완료 수를 대조하세요. 화면 렌더링만 느린 상황이라면 모든 프레임을 표시할 필요가 없습니다. 다만 생산 수량만 맞고 촬영 번호가 누락될 수도 있으므로 카운터 하나만 보고 정상으로 판정하면 안 됩니다.

Q. 몇 시간 가동한 뒤부터 손실이 늘어납니다.
메모리 누수, SSD 캐시 소진, 저장 공간 부족, 장비 온도 상승을 우선 의심하세요. 시작 직후와 장애 직전의 메모리 사용량, 디스크 지연, 카메라 및 PC 온도를 비교하면 원인 범위를 좁힐 수 있습니다.

• Frame ID가 연속인지 확인했습니까?
• 트리거 오버런 카운터가 증가합니까?
• 계산한 데이터량이 링크 실효 대역폭 안에 있습니까?
• 검사 최대 시간이 촬영 주기를 넘지 않습니까?
• 저장 기능을 끄면 증상이 사라집니까?
• 설정 변경 후 장시간 최악 조건 시험을 완료했습니까?

이 질문 가운데 하나라도 답을 확인하지 못했다면 장비 구매보다 계측이 먼저입니다. 트리거 입력부터 촬영, 전송, 검사, 저장까지 단계별 수량과 시간을 연결하면 프레임 드롭이 발생한 정확한 위치를 찾고 같은 장애의 재발도 예방할 수 있습니다.