PLC가 HMI에 연결되지 않는 이유는 무엇인가요?

PLC가 HMI에 연결되지 않으면 화면에 일반적으로 세 가지 중 하나가 표시됩니다. 타임아웃 오류, 깜박이는 "연결 없음" 배너 또는 10분 전에 업데이트가 중단된 채로 멈춘 데이터입니다. 기계는 여전히 작동 중이거나 작동했었지만, 운영자는 가시성이 없습니다. 이러한 격차는 실제 비용을 발생시키며, 대부분의 프로젝트 문서에서 인정하는 것보다 더 자주 발생합니다.

저는 수처리 시설, 자동차 조립 라인, 식품 포장 셀에서 이러한 고장 모드를 보았습니다. 좌절스러운 부분은 문제가 아니라 문제 자체입니다. 수정은 보통 간단하지만, 그것을 찾아가는 과정은 그렇지 않다는 것입니다.

HMI와 PLC 통신은 실제로 어떻게 작동하나요?

수정을 시작하기 전에, 무엇이 일어나야 하는지 이해하는 것이 도움이 됩니다. PLC는 서버 역할을 합니다. 메모리 레지스터(코일, 홀딩 레지스터, 데이터 블록)를 보유하고 기다립니다. HMI는 클라이언트 역할을 합니다. 일반적으로 100~500밀리초의 예약된 폴링 주기로 특정 주소에 대한 읽기 요청을 보냅니다.

그 통신은 물리적 매체를 통해 이동합니다. 대부분의 경우 이더넷 케이블, 이전 설치의 경우 RS-485 직렬, 때로는 무선입니다. 이 물리적 계층 위에는 프로토콜이 있습니다. Modbus TCP/IP, OPC UA, Siemens S7, PROFINET 또는 EtherNet/IP는 어떤 하드웨어를 사용하느냐에 따라 달라집니다.

해당 스택 내 물리 계층, 네트워크 계층 또는 애플리케이션 계층 중 하나라도 오류가 발생하면 HMI에 "PLC에 연결할 수 없습니다."라는 메시지가 표시됩니다. 동일한 오류 메시지입니다. 근본 원인은 완전히 다릅니다. 이것이 바로 방법론 없이는 이 문제를 진단하는 것이 낭비되는 이유입니다.

아무도 언급하지 않는 오진 연쇄

매뉴얼에 기록되지 않는 점이 있습니다. 경험이 많은 엔지니어를 포함한 대부분의 엔지니어는 잘못된 계층을 진단하는 데 40~90분을 소비합니다.

일반적인 연쇄는 다음과 같습니다. HMI에 시간 초과가 표시됩니다. 엔지니어는 HMI 구성 소프트웨어를 열고 태그 매핑이 잘못되었다고 가정하고 주소를 검토하는 데 20분을 보냅니다. 아무것도 변경되지 않습니다. 그런 다음 HMI를 다시 시작합니다. 여전히 연결되지 않습니다. HMI 프로젝트를 업데이트하고 다시 다운로드합니다. 여전히 아무것도 아닙니다. 마지막으로 누군가 물리적 케이블을 확인하고 스위치 포트에서 반쯤 빠져 있는 것을 발견합니다. 수정하는 데 5초. 90분 손실.

오진 패턴이 발생하는 이유는 소프트웨어 문제가 더 제어하기 쉬운 것처럼 느껴지고 대부분의 엔지니어는 가장 잘 알고 있는 도구를 사용하기 때문입니다. 물리적 계층은 너무 명백하게 느껴집니다. 건너뜁니다.

물리 계층부터 시작하십시오. 항상.

PLC가 HMI에 연결되지 않는 이유: 실제 원인

물리적 연결 문제 가장 큰 원인이자 가장 과소평가되는 부분입니다. 제대로 연결된 것처럼 보이는 케이블도 여전히 부분적인 접촉 불량을 일으킬 수 있습니다. 산업 환경은 진동, 온도 변화, 케이블 유연성을 더하며, 이는 몇 달에 걸쳐 커넥터를 느슨하게 만듭니다. 저는 식품 공장에서 스위치 포트의 RJ45 잭을 교체한 적이 있습니다. 해당 포트는 간헐적으로 트래픽을 통과시켰으며, 패널이 데워지는 생산량 최대치에서만 실패했습니다. 아무도 스위치를 의심하지 않았습니다.

IP 주소 구성 오류 물리적 문제 다음으로 두 번째로 흔한 원인이며, 초기 설정 시가 아니라 거의 항상 네트워크 변경 중에 발생합니다. 누군가 플랜트 네트워크를 192.168.1.x에서 10.10.5.x로 업데이트하면서 PLC에 이더넷 모듈 구성에 정적 IP가 기록되어 있음을 잊어버립니다. HMI는 이제 다른 서브넷에 있게 됩니다. 통신은 즉시 실패합니다.

프로토콜 또는 드라이버 불일치 하나의 특정 시나리오에서 나타나는 경향이 있습니다. 다른 공급업체의 PLC 또는 HMI를 교체하고 프로토콜 설정이 그대로 유지될 것이라고 가정합니다. 그러나 그렇지 않습니다. 전송 속도, 패리티, 중지 비트, 스테이션 번호는 모두 양쪽에서 정확히 일치해야 합니다. 슬레이브 ID 설정에서 한 자리만 잘못되어도 끊어진 케이블과 같은 '연결되지 않음' 오류가 발생합니다.

HMI 구성 오류 잘못된 태그 주소, 잘못된 데이터 유형 매핑, 이전 레지스터 위치를 계속 가리키는 오래된 프로젝트 파일은 더욱 미묘한 실패를 야기합니다. 연결은 설정되지만 끊어지거나 데이터가 모두 0으로 읽힙니다. 엔지니어들은 때때로 이것이 잘못된 주소 블록 때문임을 추적하기 전에 몇 주 동안 '거의 작동'하는 것으로 받아들입니다.

펌웨어 비호환성 은 경험이 풍부한 엔지니어조차 당황하게 만드는 문제입니다. PLC 펌웨어 업데이트가 마이너 버전으로 출시되었습니다. HMI 드라이버는 이전 버전을 기반으로 작성되었습니다. 프로토콜 핸드셰이크가 조용히 실패하고 오류 로그에는 유용한 정보가 표시되지 않습니다. 이는 대부분의 공급업체가 공개적으로 인정하는 것보다 Siemens S7 연결에서 더 자주 발생합니다.

PLC가 HMI에 연결되지 않는 문제 해결 방법 — 단계별 안내

이 순서가 중요합니다. 순서대로 따르십시오.

물리적 계층부터 시작하십시오. 이더넷 케이블이 양쪽 끝에 단단히 고정되었는지 확인하십시오. 스위치 포트와 PLC의 이더넷 모듈에 있는 링크 표시등 LED를 살펴보십시오. 둘 다 녹색으로 켜져 있어야 합니다. 둘 중 하나라도 꺼져 있거나 주황색으로 깜박이면 다른 조치를 취하기 전에 케이블을 교체하십시오. 다른 장치에서 작동이 확인된 케이블을 사용하십시오.

동일한 네트워크 세그먼트의 PC에서 명령 프롬프트를 열고 PLC의 IP 주소로 ping을 보내십시오. 응답을 받으면 물리적 및 네트워크 계층이 작동하는 것입니다. "요청 시간 초과"라는 메시지가 표시되면 문제는 애플리케이션 계층 아래에 있습니다. IP 설정, 서브넷 또는 하드웨어 문제입니다. HMI 구성을 아직 건드리지 마십시오.

두 장치의 IP 설정을 확인하십시오. HMI와 PLC는 동일한 서브넷 마스크와 네트워크 접두사를 공유해야 합니다. PLC가 255.255.255.0 마스크를 가진 192.168.1.111에 있고 HMI는 192.168.1.x 범위에 있어야 합니다. HMI 소프트웨어뿐만 아니라 PLC의 이더넷 구성을 열고 거기에 기록된 주소를 확인하십시오. 기억하고 있는 주소가 아닙니다.

네트워크 계층에서 양호한 상태를 확인한 후 HMI 구성 소프트웨어를 열고 PLC 설명서와 나란히 비교하여 모든 프로토콜 설정을 확인하십시오. Modbus RTU의 경우 전송 속도, 데이터 비트, 패리티, 중지 비트 및 슬레이브 주소입니다. Modbus TCP의 경우 포트 번호(기본값 502) 및 장치 ID를 확인하십시오. S7 연결의 경우 랙 및 슬롯 번호가 물리적 하드웨어와 일치하는지 확인하십시오.

순서대로 두 장치를 다시 시작하십시오. 먼저 PLC를 시작하고 실행 모드에 도달할 때까지 기다린 다음 HMI를 다시 시작하십시오. 이렇게 하면 양쪽의 통신 스택이 재설정되고 구성 오류와 동일하게 보이는 일시적인 실패 클래스를 처리할 수 있습니다.

이 모든 과정을 거쳐도 연결이 계속 실패하면 네트워크에 브리지된 PC에서 Wireshark를 실행하십시오. 연결 시도 중에 트래픽을 캡처하고 HMI가 올바른 IP 및 포트로 패킷을 전송하고 있는지, PLC가 전혀 응답하는지 확인하십시오. 패킷 캡처는 어느 장치가 예상대로 작동하지 않는지 알려줄 것입니다.

계층	확인	도구
물리	케이블 연결됨, LED 녹색	육안 검사, 케이블 테스터
네트워크	동일 서브넷에서 PC로 PLC Ping	명령 프롬프트 / 터미널
IP 구성	두 장치 모두 일치하는 서브넷	PLC 구성 소프트웨어, HMI 소프트웨어
프로토콜	전송 속도, 패리티, 슬레이브 ID 일치	HMI 드라이버 설정 대 PLC 문서
애플리케이션	태그 주소, 데이터 유형 올바름	HMI 태그 편집기
펌웨어	버전 호환성 확인됨	공급업체 릴리스 노트

---

상세히 알아둘 만한 두 가지 사례

사례 1: 팬텀 서브넷 변경. 중견 시설의 한 패키징 라인은 3년간 안정적으로 운영되었습니다. 어느 월요일 아침, HMI가 8개 스테이션 중 5개에서 PLC 연결 실패를 보고했습니다. 해당 시설의 IT 팀은 주말 동안 네트워크 분할을 위해 플랜트 네트워크를 192.168.10.x 체계에서 10.0.10.x 체계로 이전했습니다. 관리형 스위치, SCADA 서버 및 운영자 PC를 업데이트했습니다. IT 자산 목록에 포함되지 않은 PLC 이더넷 모듈의 고정 IP 주소는 업데이트해야 한다는 생각을 아무도 하지 못했습니다. 해당 IP 주소는 OT 엔지니어링 측에 속해 있었기 때문입니다. 5개의 PLC는 더 이상 해당 네트워크 세그먼트에 존재하지 않는 IP 주소를 가지고 있었습니다. 근본 원인이 명확해지자 해결에는 8분이 걸렸습니다. IT와 OT가 처음 3시간 동안 서로의 구성을 탓했기 때문에 진단에는 4시간이 걸렸습니다.

교훈: 네트워크 인프라 변경 시 해당 세그먼트의 모든 PLC 및 HMI에 있는 모든 고정 IP에 대한 의무적인 검토가 트리거되어야 합니다. 이는 거의 누구의 변경 관리 체크리스트에도 포함되지 않으며, 포함되어야 합니다.

사례 2: 조용한 펌웨어 오류. 빌딩 자동화 통합 업체는 펌웨어 4.2용으로 작성된 드라이버 버전의 HMI 패널과 함께 펌웨어 4.5를 실행하는 새로운 Siemens S7-1200 PLC 배치를 배포했습니다. 초기 시운전은 성공적으로 이루어졌습니다. 6주 후, 사이트의 자산 관리 시스템에서 자동으로 푸시된 PLC 펌웨어 업데이트 이후, 3개의 패널이 영구적으로 연결이 끊겼습니다. HMI 로그에는 추가 세부 정보 없이 "연결 거부"라고 표시되었습니다. PLC 진단 버퍼에는 특이 사항이 없었습니다. 통합 업체는 누군가가 Siemens 지원 포털에서 드라이버 버전 호환성 매트릭스를 확인하기 전까지 2일 동안 물리적 및 IP 관련 원인을 배제했습니다. HMI 공급업체는 펌웨어 4.5 지원을 추가하는 드라이버 업데이트를 보유하고 있었습니다. 15분 동안 다운로드 및 설치 후 연결이 복원되었습니다.

고통스러운 교훈: 운영 환경의 PLC에 대한 자동 업데이트 정책은 위험합니다. 모든 장치와의 드라이버 호환성을 확인하기 전까지는 펌웨어를 버전 고정하십시오.

이것을 실제로 방지하는 모범 사례

모든 IP 주소, 서브넷 마스크 및 게이트웨이를 살아있는 스프레드시트에 문서화하십시오. 개인의 기억 속에 저장하거나, 보관함에 넣어둔 시운전 보고서에 저장하지 마십시오. 네트워크 변경이 발생할 때마다 업데이트하십시오. IP와 함께 PLC 모델, 펌웨어 버전 및 HMI 드라이버 버전을 포함하십시오. 이 단일 문서만으로도 제가 사용한 어떤 진단 도구보다 문제 해결 시간을 더 많이 절약할 수 있었습니다.

IT 캐비닛에서 꺼낸 소비자용 TP-Link가 아닌 산업용 이더넷 스위치를 사용하십시오. 소비자용 스위치는 드라이브가 많은 환경에서 흔히 발생하는 전기적 노이즈를 처리하지 못합니다. 스위치 레벨에서의 간헐적인 패킷 손실은 소프트웨어 문제처럼 보이고 시간을 소모하는 무작위 통신 끊김 현상을 정확히 발생시킵니다.

중요 라인에 이중화된 통신 경로를 구축하십시오. 듀얼 이더넷 포트는 설정 시 더 많은 비용이 들지만, 생산 중 단일 케이블 장애라는 전체 범주를 제거합니다.

높은 진동 영역의 패널 연결에 대해 분기별 케이블 검사를 예약하십시오. 설정 시 페인트 마커로 케이블 삽입 깊이를 표시하십시오. 마크가 움직였다면 커넥터가 이동한 것입니다.

HMI/PLC 네트워크와 플랜트 IT 네트워크 간에 VLAN 세분화를 설정하십시오. IT 측의 비인가 트래픽 또는 브로드캐스트 스톰은 여러 시설에서 HMI 통신을 중단시켰습니다. Stone HMI의 펌웨어 팀은 양산 준비가 완료되고 현장 테스트된 빌드를 출시합니다. 네트워크 격리는 해당 배포가 안정적으로 유지되는 이유 중 하나입니다.

대부분의 가이드에서 건너뛰는 추가 사항

여러 HMI가 동일한 PLC를 폴링하는 시스템에만 나타나는 고장 모드가 있습니다: 연결 기아(connection starvation). 각 HMI는 200밀리초마다 폴링 요청을 보냅니다. 동일한 PLC에 4개의 HMI가 있으면 초당 20개의 요청이 발생합니다. SCADA 서버와 OPC UA 클라이언트를 추가하면 PLC의 연결 제한을 초과하거나 통신 프로세서를 포화 상태로 만들 수 있습니다.

증상은 네트워크 문제와 동일하게 보입니다: 시간 초과, 연결 끊김, 간헐적인 데이터. 그러나 핑은 성공하고 IP 설정은 올바르며, 단일 HMI 연결은 정상적으로 작동합니다. 해결 방법은 폴링 속도를 줄이거나, PLC의 연결 제한을 설정에서 늘리거나(하드웨어가 지원하는 경우), OPC DA/UA 서버를 통해 읽기 트래픽을 오프로드하여 요청을 집계하는 것입니다.

이는 검색 결과의 첫 페이지에 나타나지 않습니다. 이를 이해하는 데 부끄러울 정도로 오랜 시간 Mitsubishi Q 시리즈 시스템과 씨름해야 했으며, 이후 두 명의 다른 엔지니어도 같은 문제에 직면하는 것을 보았습니다.

여전히 해결되지 않았습니까?

위의 모든 단계를 진행했는데도 연결이 계속 실패하면 다음 단계는 귀하의 위치에 따라 달라집니다.

아직 진단 중인 엔지니어의 경우: Wireshark 캡처를 실행하고, 캡처된 트래픽을 PLC 모델의 프로토콜 사양과 비교하고, 프로그래밍 소프트웨어를 통해 PLC의 연결 진단 버퍼를 직접 확인하십시오. 답은 그 두 곳 중 한 곳에 있습니다.

배송 압박을 받는 프로젝트 관리자 또는 기술 리드의 경우: 팀이 명확한 근본 원인 없이 이 문제에 하루 이상을 소비했다면, 문제는 펌웨어 수준 호환성 또는 하드웨어 결함에 있을 가능성이 높습니다. 이 두 가지 모두 신속한 진단을 위해 더 깊은 프로토콜 계층 전문 지식이 필요합니다. 해당 시점에서 외부 임베디드 개발 엔지니어링 지원을 받는 것이 반복하는 것보다 더 빠르고 저렴합니다. 임베디드 개발 50개 이상의 산업 제품을 출시하고 현장에서 100,000개 이상의 장치를 실행한 팀은 일반적으로 하루가 아닌 몇 시간 안에 이 범주의 문제를 분리할 수 있습니다.

PLC와 HMI 간의 연결 실패는 해결 가능합니다. 가장 오래 걸리는 실패는 거의 항상 잘못된 계층에서 진단이 시작된 경우입니다.