Modbus RTU vs TCP — 무엇이 다르고 언제 무엇을 쓰나

같은 명령, 다른 포장

Modbus 는 1979년에 나온 아주 단순한 규약입니다. '몇 번 장비의 몇 번 레지스터를 몇 개 읽어라' 정도가 전부입니다. RTU 와 TCP 는 이 명령을 담는 봉투가 다를 뿐, 안에 들어가는 편지 내용은 똑같습니다.

그래서 기능 코드도 양쪽이 같습니다. 장비 매뉴얼에 '03 으로 읽고 16 으로 쓴다'고 적혀 있으면 RTU 든 TCP 든 그대로 통합니다.

전선과 연결 형태

RTU 는 보통 RS-485 두 가닥 위에서 돕니다. 장비를 한 줄로 이어 붙이면 되니 배선이 싸고, 거리도 9600bps 기준 1km 넘게 나옵니다. 대신 한 줄을 여러 대가 나눠 쓰기 때문에 마스터가 한 번에 한 대씩만 물어볼 수 있습니다.

• 양 끝 장비에 **120Ω 종단저항**을 답니다. 없으면 반사파로 간헐적 오류가 납니다 — 짧은 배선에서는 멀쩡하다가 길어지면 터지는 전형적 원인입니다.
• A/B (D+/D-) 극성을 맞춥니다. 제조사마다 표기가 반대인 경우가 있어, 안 되면 두 선을 바꿔 보는 것이 가장 빠른 확인입니다.
• 장비 간 **접지 전위차**가 크면 통신이 불안정합니다. 통신용 공통 그라운드를 같이 끌어 주세요.
• 슬레이브 주소는 1~247. 같은 주소를 두 대에 준 순간 응답이 충돌합니다.

TCP 는 장비마다 IP 를 받고 스위치에 꽂습니다. 이미 사내망이 깔려 있다면 추가 배선이 거의 없고, 여러 클라이언트가 동시에 접속할 수 있습니다. 대신 구간당 100m 제한이 있고, 스위치·IP 관리가 따라옵니다.

속도는 실제로 얼마나 차이 나나

체감 차이는 '전송 속도'보다 '한 번 주고받는 데 걸리는 시간'에서 옵니다. RTU 를 9600bps 로 쓰는 경우를 계산해 보면 감이 옵니다. 8N1 이면 1바이트에 10비트가 실리므로 1초에 960바이트, 1바이트에 약 1ms 입니다.

요청 8바이트 + 응답 9바이트 = 17바이트 ≈ 18ms
+ 프레임 구분용 침묵(3.5문자) ×2 ≈ 7ms
+ 장비 처리 시간 ≈ 5~20ms
────────────────────────────
1회 왕복 ≈ 30~45ms  →  초당 20~30회

슬레이브가 10대라면 한 대당 초당 2~3회 갱신이 한계입니다. 온도·유량처럼 느린 값은 충분하지만, 수십 ms 단위로 봐야 하는 값에는 부족합니다. 이더넷에서는 같은 왕복이 보통 1~5ms 이고 장비별로 동시에 물어볼 수 있어, 갱신 주기가 한 자리 수로 떨어집니다.

주소 표기의 함정

실무에서 가장 많이 막히는 지점은 프로토콜이 아니라 주소입니다. 장비 매뉴얼에 40001 이라고 적혀 있어도, 통신으로 보낼 때는 0 입니다. 40001~49999 는 홀딩 레지스터를 가리키는 옛날 표기이고, 실제 프레임에는 0부터 시작하는 오프셋이 들어갑니다.

파이썬에서는 두 줄만 다릅니다

명령이 같으니 코드도 거의 같습니다. pymodbus 기준으로 클라이언트를 만드는 줄만 바꾸면 나머지는 그대로 돌아갑니다.

# pip install pymodbus
from pymodbus.client import ModbusSerialClient, ModbusTcpClient

# RTU — 직렬 포트
client = ModbusSerialClient(port="COM3", baudrate=9600,
                            parity="N", stopbits=1, bytesize=8)

# TCP — IP 주소 (위 한 줄 대신 이 줄)
# client = ModbusTcpClient("192.168.0.50", port=502)

client.connect()
rr = client.read_holding_registers(address=0, count=2, slave=1)
print(rr.registers)          # 예: [258, 16000]
client.close()

실제 장비 없이 연습하려면 PC 에서 슬레이브(서버)를 띄워 같은 PC 의 클라이언트로 접속해 보면 됩니다. 로봇 통신 강의 트랙에서 이 구성을 단계별로 다룹니다.

어느 쪽을 고를까

게이트웨이를 쓸 때는 유닛 ID 가 열쇠입니다. TCP 쪽에서 보낸 유닛 ID 가 게이트웨이 뒤에 붙은 RS-485 슬레이브 주소로 그대로 전달되므로, 이 값을 장비 주소와 맞춰야 응답이 옵니다.

통신이 안 될 때 점검 순서

RTU

1. 1통신 파라미터가 장비와 같은지 확인합니다. 보레이트, 패리티, 정지 비트(예: 9600 8N1 vs 9600 8E1) 중 하나만 달라도 전혀 안 됩니다.
2. 2A/B 극성을 바꿔 봅니다. 표기가 제조사마다 달라 흔한 원인입니다.
3. 3슬레이브 주소 중복이 없는지, 매뉴얼의 주소가 0 기반인지 1 기반인지 확인합니다.
4. 4양 끝 종단저항 120Ω 과 공통 접지를 확인합니다. 간헐적 오류의 단골입니다.
5. 5그래도 안 되면 슬레이브 한 대만 남기고 직결해 봅니다. 한 대는 되는데 여러 대에서 깨지면 배선·종단 문제입니다.

TCP

1. 1ping 으로 IP 도달을 먼저 확인하고, 그다음 포트 502 가 열려 있는지 봅니다(방화벽이 자주 막습니다).
2. 2유닛 ID 를 확인합니다. 장비에 따라 1 이 아닌 값을 요구하거나, 게이트웨이 뒤 슬레이브 주소와 맞춰야 합니다.
3. 3동시 접속 수 제한을 확인합니다. 값싼 장비는 연결 1~2개만 받아, 다른 프로그램이 이미 잡고 있으면 거절합니다.
4. 4Wireshark 로 캡처해 요청은 나가는데 응답이 없는지, 예외 응답(기능 코드에 0x80 이 더해진 값)이 오는지 봅니다. 예외 코드 02 는 잘못된 주소, 03 은 잘못된 개수입니다.

자주 묻는 질문