【통신 실무】 PLC 통신이 안 될 때 점검 순서 | IP, Ping, Port, Address, Heartbeat

PLC COMMUNICATION TROUBLESHOOTING PLC 통신이 안 될 때 Program부터 수정하지 말자

Power와 Link부터 IP, Ping, Port, Protocol, Address, Heartbeat까지 아래에서 위로 확인하면 원인 범위를 빠르게 줄일 수 있다.

PLC 통신이 갑자기 끊기면 가장 먼저 PLC Program이나 통신 Function Block을 열어보는 경우가 많다. 하지만 실제 원인은 Cable, Switch, IP 중복, Port 설정, Address Offset, 상대 Application 정지처럼 여러 단계에 있을 수 있다.

Ethernet 기반 PLC 통신이 안 될 때는 Power와 Wiring → Link → IP와 Subnet → Ping → Port와 Session → Protocol → Address와 Data → Heartbeat와 Application 순으로 확인하는 것이 좋다.

핵심 원칙 아래 단계가 정상인지 확인한 뒤 다음 단계로 올라간다. Ping도 안 되는데 PLC Register부터 수정하거나, Address가 틀렸는데 Switch를 교체하면 Troubleshooting 시간이 길어진다.

1. PLC 통신 장애 점검 순서

01POWER / WIRING

전원, Cable, Connector

02LINK

NIC와 Switch Link 상태

03IP / SUBNET

대역과 중복 여부

04PING

Network Reachability

05PORT

TCP Service와 Session

06PROTOCOL

Client, Server, Function

07DATA

Address, Length, Type

08APPLICATION

Heartbeat, Timeout, Interlock

2. 첫 번째는 전원과 Cable이다

통신 Error가 발생했을 때 Software부터 의심하기 전에 상대 장치가 실제로 정상적으로 켜져 있는지부터 확인한다. PLC CPU가 RUN 상태인지, Ethernet Module에 전원이 있는지, Connector가 완전히 체결되어 있는지 본다.

산업현장에서는 Cable 단선뿐 아니라 Connector 접촉불량, Cable 장력, 반복 굴곡, Switch 전원 불량도 통신 Error 원인이 될 수 있다.

1차 확인

• PLC와 상대 장치 전원이 정상인가?
• RJ45 Connector Lock이 정상인가?
• Switch Port에 Link LED가 들어오는가?
• 다른 정상 Cable로 교체했을 때 증상이 바뀌는가?
• 특정 위치나 Motion에서만 통신이 끊기지 않는가?

3. Link LED가 없으면 IP보다 먼저 Physical Layer를 본다

Ethernet Link 자체가 형성되지 않았다면 IP Address를 아무리 수정해도 Ping은 되지 않는다. PLC, Switch, PC의 Link LED를 먼저 확인한다.

한쪽 Port만 Link가 없으면 Cable과 Connector, Port 상태를 확인하고, 여러 Port가 동시에 내려갔다면 Switch 전원이나 상위 Network까지 범위를 넓혀볼 수 있다.

4. Link가 정상이라면 IP와 Subnet을 확인한다

Cable과 Link가 정상인데 통신이 되지 않는다면 IP Address와 Subnet Mask를 확인한다.

항목	확인 내용	대표적인 문제
IP Address	장치마다 고유한 주소인지 확인	IP 중복
Subnet Mask	서로 같은 Local Network인지 확인	다른 Subnet
Gateway	다른 Network와 통신할 때 경로 확인	잘못된 Gateway
PC NIC	여러 NIC 중 실제 통신 경로 확인	잘못된 Adapter 사용

PC에서 기본 Network 설정을 확인할 때는 다음 명령을 사용할 수 있다.

ipconfig

장치가 여러 Network Adapter를 가지고 있다면 어느 Adapter에 어떤 IP가 설정되어 있는지 반드시 확인한다.

5. Ping은 어디까지 확인해주는가?

다음 단계는 Ping이다.

ping 192.168.10.20

Ping Response가 온다면 일반적으로 해당 IP까지 Network Packet이 왕복할 수 있다는 중요한 단서를 얻을 수 있다. 하지만 Ping 성공이 PLC Application 통신 정상이라는 뜻은 아니다.

Ping은 통신 전체의 합격 판정이 아니다.
Ping이 정상이어도 Modbus Server가 Disable되어 있거나 TCP Port가 닫혀 있거나 Address가 잘못되면 PLC Data 통신은 실패한다. 반대로 일부 장치는 ICMP 응답 정책 때문에 Ping 결과만으로 모든 Network 상태를 단정하기 어렵다.

6. Ping은 되는데 PLC 통신이 안 된다면 Port를 본다

이 상황부터 Physical Network보다 Application 쪽으로 원인 범위가 좁아진다. Modbus TCP를 예로 들면 상대 장치에서 해당 Server 기능이 Enable되어 있는지, 사용하는 TCP Port가 맞는지 확인한다.

Windows PowerShell에서는 특정 TCP Port에 연결 가능한지 다음과 같이 점검할 수 있다.

Test-NetConnection 192.168.10.20 -Port 502

Port 연결이 실패한다면 PLC의 Server 설정, Firewall, Session 수, Port 설정을 확인한다. Port가 연결된다고 해서 Modbus Data까지 정상인 것은 아니지만 원인 범위를 한 단계 더 줄일 수 있다.

7. Client와 Server 역할이 맞는지 확인한다

통신 양쪽 모두 상대가 먼저 요청하기를 기다리고 있다면 Data는 오가지 않는다. Modbus TCP에서는 누가 Client로 Request를 시작하고 누가 Server로 Response하는지 확인해야 한다.

이때 현장에서 사용하는 "Master와 Slave", "Client와 Server", "상위와 하위장치"를 모두 같은 의미로 생각하지 않는 편이 좋다. 통신 역할과 설비 제어 권한은 별개의 개념이다.

8. 연결은 됐는데 값이 이상하다면 Address를 본다

TCP Connection까지 정상인데 값이 전혀 바뀌지 않거나 엉뚱한 Data가 들어오면 Address Map을 확인한다.

확인 항목	대표적인 오류
Address	0-based와 1-based Address 차이
Length	읽어야 할 Register 개수 불일치
Data Type	INT, UINT, DWORD, FLOAT 해석 차이
Byte Order	Word 또는 Byte 순서 불일치
Direction	양쪽 장치가 같은 Signal을 Write
Scale	Raw 값과 Engineering Unit 변환 누락

통신이 "된다, 안 된다"만 확인하지 말고 어떤 Address를 누가 Write하고 상대는 어디에서 Read하는지를 문서로 맞춰보는 것이 빠르다.

9. Heartbeat는 연결 상태와 다른 것을 확인한다

Network와 Protocol이 정상이어도 상대 Application이 정상이라고 단정할 수 없다. 프로그램이 Hang된 상태에서 마지막 통신값이 Memory에 남아 있을 수도 있다.

그래서 실제 PLC와 PC Interface에서는 Heartbeat를 별도로 두는 것이 유용하다.

좋지 않은 Heartbeat

Application이 정상일 때 HB = 1로 유지한다.

프로그램이 멈춰도 Memory에 마지막 값 1이 그대로 남을 수 있기 때문에 Application이 계속 실행 중인지 판단하기 어렵다.

확인하기 쉬운 Heartbeat

0 → 1 → 0 → 1 형태의 Toggle Bit 또는 계속 증가하는 Counter를 사용한다.

PLC는 일정 Timeout 안에 값이 실제로 변하는지 감시한다.

10. 실제로는 통신 문제가 아니었던 사례도 있다

사례 1. Data Read와 Write는 정상인데 Heartbeat Test만 실패

현상Command와 Status 통신은 정상인데 Communication Monitoring만 Fault가 발생했다. 원인Heartbeat로 사용하던 값이 고정되어 있어 상대 Application이 살아 있다는 것을 증명하지 못했다. 조치Heartbeat 조건을 실제 값 변화 기준으로 수정하고 재시험했다. 교훈Network 연결 상태와 Application Alive 상태를 분리해서 봐야 한다.

사례 2. Timeout이 발생했지만 Network Packet이 원인이 아니었던 경우

현상설비 Handshake 과정에서 Timeout이 반복되어 처음에는 통신 문제를 의심했다. 확인Network 자체는 정상적으로 Data를 주고받고 있었다. 원인상대 Sequence가 다음 단계로 넘어가기 위한 위치조건과 Interlock이 만족되지 않았다. 교훈Timeout은 통신 단선뿐 아니라 Application Sequence가 완료되지 않았을 때도 발생한다.

11. Version mismatch도 반드시 확인한다

현장 Troubleshooting에서 의외로 시간을 많이 쓰는 것이 Software Version 불일치다. 한쪽 PLC Program은 신규 Device Map을 사용하고 다른 Controller는 이전 Address Map을 사용하면 Network는 정상인데 Data 의미가 맞지 않을 수 있다.

그래서 Interface에는 Signal Map Version이나 Software Version을 확인할 수 있는 정보를 두는 것이 좋다. 특히 여러 장비를 동시에 운영할수록 Version 관리는 통신 설정만큼 중요해진다.

12. 최종 Troubleshooting Checklist

순서	확인	정상이라면 다음 단계
1	Power, Cable, Connector	Link 확인
2	Ethernet Link	IP 확인
3	IP, Subnet, 중복	Ping 확인
4	Network Reachability	Port 확인
5	TCP Port, Session	Protocol 확인
6	Client, Server, Function	Address 확인
7	Address, Length, Data Type	Heartbeat 확인
8	Heartbeat, Timeout	Interlock과 Sequence 확인

현장에서 기억할 한 줄 Link가 안 되면 Cable을 보고, Ping이 안 되면 Network를 보고, Ping은 되는데 통신이 안 되면 Port와 Protocol을 보고, 값이 이상하면 Address를 보고, 모두 정상인데 설비가 멈추면 Heartbeat와 Interlock을 본다.

마무리

PLC 통신 Troubleshooting은 통신 Protocol을 많이 외우는 것보다 어느 단계까지 정상인지 하나씩 경계를 좁히는 과정이다.

Power와 Cable부터 시작해 Link, IP, Ping, Port, Protocol, Data, Application 순서로 확인하면 원인과 관계없는 Program을 수정하는 일을 줄일 수 있다.

특히 Ping 성공, TCP 연결 성공, PLC Data 정상, Application 정상은 서로 다른 단계라는 점을 기억하면 현장에서 통신 문제를 훨씬 빠르게 분류할 수 있다.

PILLAR 03 Communication / PLC Interface 설계 가이드

통신 장애를 줄이려면 Troubleshooting보다 먼저 Device Map, Data Ownership, Heartbeat, Timeout과 Version Rule을 Interface 설계 단계에서 정의해야 한다.

Communication Guide 보기 →

TerryPack 참고글

NETWORK BASIC IP Address, Subnet Mask, Gateway 쉽게 이해하기

같은 Switch에 연결했는데 Ping이 안 되는 이유부터 IP와 Subnet의 역할까지 정리했다.

글 보기 →

MODBUS TCP Modbus TCP란? PLC와 PC 통신 구조부터 Port 502까지

Ping 이후 확인해야 할 Port, Client, Server, Address Map과 Heartbeat를 자세히 설명한다.

글 보기 →