[MELSEC] Q Modbus RTU 무수순 통신 가이드-1 (이해편)

미츠비시 PLC Q 시리즈에서 시리얼통신 Modbus RTU 프로토콜을 사용하려면 가장 흔한 방법은 사전정의 프로토콜 (Predefined Protocol) 입니다.

 

사전정의 프로토콜에서는 기본적으로 모드버스 RTU 의 통신라이브러리를 지원하며, 디바이스만 지정하면 자동으로 교신하게 꾸밀수 있어 쉽게 구현할수 있기 때문이죠.

 

저는 이를 사용하지않고 기존의 시리얼통신 무수순 교신 방법으로 구현을 해보고자 합니다.

흔히들 안된다고 알고 계시지만, 당연하게도 안되는것은 없습니다. 단지 조금 어려울 뿐입니다.

무수순 교신 방식으로도 모드버스 RTU 프로토콜을 처리하는 방법은 아래 정리하는 내용대로 따라와 보시죠.

 

 

1. 모드버스 RTU 프로토콜의 구조

우리는 들어가기 앞서 이번 글에서 다룰려고 하는 모드버스 RTU 프로토콜에 대한 이해가 필요합니다.

 

모드버스RTU의 구조는 기본적으로 펑션코드와 데이터로 이루어집니다.

펑션코드에 따라 데이터를 쓸건지, 읽을건지가 결정되며, 그에 수반되는 데이터들이 뒤에 따라 붙는 형식입니다.

 

[슬레이브국번][펑션코드][데이터][CRC-16]

 

일반적인 모드버스 RTU 의 프로토콜 형식 입니다.

데이터는 일반적인 아스키 데이터가 아닌 바이너리 데이터로 서로 주고 받게 됩니다.

 

오토닉스의 온도 컨트롤러 통신 매뉴얼에는 굉장히 자세하게 Modbus RTU 프로토콜을 설명해주고 있습니다.

흔히 사용하는 데이터를 읽는 펑션 (04) 를 보더라도 [국번][펑션코드][시작번지][데이터갯수][CRC-16] 메시지 형식을 취하고 있는것을 알수있습니다.

 

해당 메시지 형식에 맞추어 바이너리값으로 데이터를 던지면, 그에 대한 리턴도 바이너리로 돌아온다는 예시까지 첨부되어있습니다.

 

일반적으로 모드버스 RTU를 처음 스터디할때는 오토닉스의 매뉴얼 자료들이 참 보기가 편하고 좋습니다.

 

 

2. 모드버스 RTU 프로토콜과 아스키 무수순교신의 특징

모드버스RTU와 아스키 무수순교신의 가장 큰 차이는 통신에 사용하는 데이터의 타입과 메시지 프레임의 종료를 판정하는 근거에 있다고 간략화 해서 말씀드릴수 있을것 같습니다.

 

동일한 모드버스이지만 아스키코드를 기반으로 교신하는 Modbus ASCII와 바이너리값을 기반으로 교신하는 Modbus RTU 의 차이를 보면 이를 극명하게 알수있을 것입니다.

	Modbus RTU	Modbus ASCII
데이터 기반	바이너리	아스키코드
종료 기준	무신호 시간 (3.5 문자)	특정 종료문자 (ETX, CR+LF 등)
데이터 검증방법	CRC-16	LRC

 

더 이해하기 쉽게 이 두 프로토콜의 통신 방식부터 다시 살펴보겠습니다.

 

모드버스 RTU 프로토콜의 메시지 프레임 형식

모드버스 ASCII 프로토콜의 메시지 프레임 형식

 

이 두 메시지 프레임 형식의 차이는 꽤 큰 차이를 불러옵니다.

종료코드가 있냐 없냐, 통신방식이 바이너리냐, 아스키코드냐

그리고 CRC-16 데이터검증이냐 LRC 데이터 검증이냐

차이이지만 이 차이로 인해 구현해야하는 방식 자체가 달라지기 때문입니다.

 

예를들어 설명하면 1번 국 슬레이브의 Holding Resister 0000 부터 10개의 데이터를 읽고 싶은 경우입니다.

이를 모드버스의 메시지 형식으로 만들면 다음과 같습니다.

 

예시) 1번국 슬레이브의 Holding Resister 0000 부터 10개의 데이터를 읽는다.
[국번][펑션][시작 어드레스][데이터 갯수]
01 03 0000 0010
(BINARY) 0x01 03 0000 000A
(ASCII) 0x3031 3033 30303030 30303041

 

이를 각각 모드버스 RTU와 모드버스 ASCII 로 표현해보겠습니다.

 

 

Modbus RTU : [슬레이브국][펑션][시작어드레스][데이터갯수][CRC-16]
(HEX 예시) 0x01 03 0000 000A C5CD

Modbus ASCII : [시작 ":"][슬레이브국][펑션][시작어드레스][데이터갯수][LRC][종료코드 "CR+LF"]
(HEX 예시) 0x3A 3031 3033 30303030 30303041 3731 0D0A

 

바이너리, 아스키 데이터의 차이, 그리고 시작코드, 종료코드의 유뮤가 메시지 프레임에도 아주 큰 영향을 주었음을 알수있습니다.

 

3. 모드버스 RTU 프로토콜과 아스키 무수순교신의 차이

앞서 살펴 보았듯이 교신 데이터가 바이너리인지 아스키 인지 에 따라서 차이를 알았습니다.

하지만 더 큰 차이는 바로 종료코드 라는점입니다.

 

모드버스 ASCII의 경우는 종료코드(CR+LF) 가 있기에 문자프레임 내에서 종료점을 확실히 찍을수 있죠.

하지만 모드버스 RTU는 다릅니다. 종료 코드없이 CRC-16 으로 문장이 끝나기 때문이죠.

여기서 큰 차이가 발생합니다.

종료코드가 없어 메시지 프레임 내에 확정적인 종료구분점이 존재 하지 않기 때문에 기존의 무수순방식의 종료코드 기반처리로는 수신된 데이터의 끝을 판단하기 어렵기 때문입니다.

심지어 리턴되어 돌아오는 데이터는 가변합니다. 이 말은 즉 CRC-16도 매번 바뀐다는 의미입니다. 고정이 되지 않죠.

 

그렇다면 모드버스 RTU의 프레임 종료는 어떻게 처리하는가?

오직 다음과 같습니다.

“3.5문자 시간 이상 무신호(Idle)가 발생하면 하나의 프레임 종료”

 

프레임의 문자와 문자 사이가 3.5 바이트 를 주고받을수 있는 시간보다 초과 한다면

그것을 메시지 프레임의 종료로 처리하는게 모드버스 RTU의 규약입니다.

다시 풀어 이야기하면 일정 시간 이상 데이터가 수신되지 않으면 끝난것으로 자동으로 처리 하라는 의미입니다.

 

Modbus RTU의 프레임 종료는 ‘특정 문자’가 아니라 통신 간격으로 판단합니다.

이 간격은 전송 속도(예: 9600bps)에 따라 달라지며, 일정 기간(3.5문자) 동안 데이터가 없으면 프레임 종료로 인정합니다.

 

9600bps 통신 속도를 기준으로 계산해보면 8비트에 1문자로 계산하면 9600 bps는 초당 1200자이며,

이를 밀리초(ms) 로 계산하면 문자 하나를 전송하는데에는 1000ms / 1200문자 = 0.8333ms 가 소요됩니다.

여기서 3.5문자가 소요되는 시간은 0.8333 * 3.5 니까 2.9166ms 정도가 흐르면 프레임이 완료되었다고 처리하는 것입니다.

 

그리고 한 프레임의 문자간의 간격은 1.5문자 이내여야 정상으로 처리합니다.

문자간의 간격이 랜덤하여 1.5 문자 이상 벌어진다면 그 프레임은 불완전 NG로 처리하라는 의미입니다.

물론 너무 디테일하게 이렇게 까지 구현하기에는 벅찬 감도 없진않기 때문에 지식으로 알고 있으면 될듯합니다.

 

ASCII는 텍스트 기반이고 종료 문자가 있기 때문에 무수순에서 처리하기 쉽습니다.

반면 RTU는 바이너리 + 종료문자 없음 + CRC만 존재해서 기존 무수순 종료문자 처리 방식으로는 판정이 곤란하죠.

이제 모드버스 RTU의 기존의 종료코드 방식의 무수순 아스키 기반 교신 방식의 차이가 이해가 되셨나요?

 

그럼 다음 글에서 미츠비시 Q PLC환경의 Gx Works2를 기준으로 어떻게 하면 수신종료코드 없이 Mobus RTU 프로토콜을 구현할수있는지에 대해 실제 래더 예제와 함께 다뤄보겠습니다.

 

2026.01.27 - [PLC 전기제어 기술자료/샘플 프로그램 & TIP] - [MELSEC] Q Modbus RTU 무수순 통신 구현 가이드 (구현편)

 

 

참조 자료 링크 : 

Modbus RTU : https://ozeki.hu/p_5854-modbus-rtu.html

Modbus ASCII : https://ozeki.hu/p_5855-modbus-ascii.html

오토닉스 온도컨트롤러 기술자료등