PLC 시리얼 통신에서 배선과 파라미터를 모두 맞췄는데도 데이터가 정상적으로 들어오지 않는 경우가 있습니다. 이때부터는 통신 모듈 안에 들어온 데이터를 PLC CPU가 어떻게 읽고, 어디에 저장하고, 언제 처리하는지를 확인해야 합니다. 통신 LED가 깜빡이는 것과 PLC 로직에서 데이터를 정상적으로 사용하는 것은 별개의 문제입니다.
배선과 설정 다음은 데이터 처리다
시리얼 통신 문제는 보통 배선, 파라미터, 데이터 처리 순서로 확인합니다.
배선이 틀리면 신호가 오가지 않습니다. 파라미터가 틀리면 신호가 있어도 서로 해석하지 못합니다. 배선과 파라미터가 맞는데도 데이터가 이상하다면, 그다음은 수신 완료 조건, 버퍼 메모리, 데이터 이동 명령, 초기화 타이밍을 확인해야 합니다.
통신 점검 순서를 간단히 정리하면 다음과 같습니다.
| 구분 | 핵심 확인 | 주요 증상 |
|---|---|---|
| 배선 | Tx/Rx, A/B, SG, 종단저항 | LED 무반응, 응답 없음 |
| 파라미터 | Baud Rate, Parity, Data Bit, Stop Bit | LED는 움직이나 값 깨짐 |
| 프로토콜 | MC, Modbus, Non-procedure, 국번 | 응답 없음, 의미 없는 데이터 |
| 데이터 처리 | 수신 완료, 버퍼 읽기, 초기화 | 일부 데이터만 수신, 이전 데이터 잔류 |
| 로직 타이밍 | 송신 후 수신 대기, 완료 후 리셋 | 간헐적 통신, 데이터 누락 |
본 글은 미쓰비시 PLC와 GX Works 환경에서 시리얼 통신 데이터를 처리할 때 자주 확인하는 항목을 실무 기준으로 정리한 내용입니다. 실제 명령어 이름, 버퍼 메모리 주소, 완료 비트, 에러 비트는 사용하는 CPU와 통신 모듈에 따라 달라질 수 있으므로 적용 전 해당 모듈 매뉴얼을 확인해야 합니다.
버퍼 메모리는 통신 데이터가 머무는 영역이다
통신 모듈은 외부 장비와 데이터를 주고받습니다. 하지만 외부에서 들어온 데이터가 곧바로 PLC의 D 영역에 자동으로 들어오는 것은 아닙니다.
통신 모듈 내부에는 수신 데이터, 송신 데이터, 상태 정보, 에러 코드 등을 저장하는 영역이 있습니다. 이를 버퍼 메모리로 볼 수 있습니다.
PLC CPU는 이 버퍼 메모리에 접근해 필요한 데이터를 가져오거나, 보낼 데이터를 넣어 통신 모듈이 송신하도록 만들어야 합니다.
개념은 다음과 같습니다.
| 구분 | 의미 |
|---|---|
| 수신 버퍼 | 외부 장비에서 들어온 데이터가 임시로 저장되는 영역 |
| 송신 버퍼 | 외부 장비로 보낼 데이터가 준비되는 영역 |
| 상태 버퍼 | 수신 완료, 송신 완료, 에러 상태 등을 확인하는 영역 |
| CPU D 영역 | PLC 로직에서 실제로 사용하는 데이터 영역 |
통신이 붙었다는 것은 신호가 오간다는 뜻이고, 데이터를 제대로 쓴다는 것은 버퍼와 D 영역 사이의 이동이 정확하다는 뜻입니다.
FROM과 TO의 기본 개념
미쓰비시 PLC에서 지능형 기능 모듈이나 통신 모듈의 버퍼 메모리에 접근할 때는 FROM, TO 계열 명령을 사용하는 경우가 있습니다.
FROM은 모듈의 버퍼 메모리에서 데이터를 읽어 PLC CPU 쪽 디바이스로 가져오는 역할을 합니다. TO는 PLC CPU 쪽 데이터를 모듈의 버퍼 메모리로 쓰는 역할을 합니다.
| 명령 개념 | 역할 |
|---|---|
| FROM | 통신 모듈 버퍼에서 PLC D 영역으로 데이터 읽기 |
| TO | PLC D 영역에서 통신 모듈 버퍼로 데이터 쓰기 |
| 읽기 대상 | 수신 데이터, 상태 정보, 에러 코드 |
| 쓰기 대상 | 송신 데이터, 명령 데이터, 제어 정보 |
다만 모든 프로젝트에서 FROM/TO를 직접 다루는 것은 아닙니다. 사용하는 모듈, 라이브러리, 프로그램 방식에 따라 전용 명령어나 전용 펑션을 사용할 수도 있습니다.
G.INPUT과 G.OUTPUT을 사용하는 경우
프로젝트나 모듈 구성에 따라 G.INPUT, G.OUTPUT 같은 전용 명령어 또는 전용 펑션을 사용해 데이터를 처리하는 경우가 있습니다.
일반적으로 G.OUTPUT은 송신 데이터를 외부 장비로 보내는 동작에 사용하고, G.INPUT은 수신된 데이터를 PLC 내부 디바이스로 가져오는 동작에 사용합니다.
예를 들어 G.OUTPUT U0 D100 M10은 U0 모듈을 대상으로 D100부터 준비된 데이터를 송신하는 형태로 볼 수 있습니다. G.INPUT U0 D200 M20은 U0 모듈에서 수신된 데이터를 D200부터 저장하는 형태로 볼 수 있습니다.
이 표현은 프로젝트 구성과 명령어 형식에 따라 달라질 수 있으므로, 실제 사용 시에는 해당 모듈의 명령어 형식과 인수 의미를 확인해야 합니다.
송신과 수신은 조건을 나누어야 한다
통신 로직에서 자주 발생하는 문제는 송신과 수신을 무조건 상시 실행하는 구조입니다.
상대 장비에 요청을 보내고, 상대 장비가 응답할 시간을 기다린 뒤, 수신 완료 신호가 들어왔을 때 데이터를 읽어야 합니다. 송신과 수신의 타이밍이 정리되지 않으면 아직 데이터가 다 들어오기 전에 읽거나, 이전 데이터를 다시 읽는 문제가 생길 수 있습니다.
기본 흐름은 다음과 같습니다.
| 단계 | 처리 내용 |
|---|---|
| 1 | 송신 조건 발생 |
| 2 | 송신 데이터 준비 |
| 3 | G.OUTPUT 또는 송신 명령 실행 |
| 4 | 송신 완료 확인 |
| 5 | 상대 장비 응답 대기 |
| 6 | 수신 완료 신호 확인 |
| 7 | G.INPUT 또는 수신 명령 실행 |
| 8 | 수신 데이터 처리 |
| 9 | 완료 비트와 임시 데이터 정리 |
이 흐름이 없으면 통신은 되는 것처럼 보여도 데이터가 깨지거나 누락될 수 있습니다.
수신 완료 신호 기준으로 데이터를 읽어야 한다
시리얼 통신은 데이터가 순차적으로 들어옵니다. 문자열 장비나 바코드 리더기처럼 여러 문자로 구성된 데이터를 받는 경우, 데이터가 한 번에 완성되어 들어오는 것이 아니라 문자 단위로 차례대로 들어옵니다.
따라서 수신 도중에 데이터를 읽으면 절반만 들어온 문자열이나 이전 데이터가 섞인 값을 읽을 수 있습니다.
수신 데이터는 반드시 수신 완료 신호를 기준으로 읽어야 합니다.
| 상태 | 처리 기준 |
|---|---|
| 수신 대기 | 수신 완료 비트가 ON될 때까지 대기 |
| 수신 완료 | 완료 비트 ON 시 데이터 읽기 실행 |
| 데이터 처리 | D 영역으로 이동된 데이터 검사 또는 변환 |
| 처리 완료 | 완료 플래그 정리, 다음 수신 준비 |
| 초기화 | 필요 시 수신 버퍼 또는 임시 영역 정리 |
수신 완료 조건 없이 SM400 같은 상시 ON 조건으로 계속 데이터를 읽으면, 아직 완성되지 않은 데이터를 가져올 가능성이 있습니다.
데이터가 깨지는 원인
통신 데이터가 깨지는 원인은 배선이나 파라미터만이 아닙니다. 데이터 처리 타이밍이 맞지 않아도 값이 깨질 수 있습니다.
대표적인 원인은 다음과 같습니다.
| 원인 | 설명 |
|---|---|
| 수신 중간에 읽음 | 전체 데이터가 들어오기 전에 D 영역으로 이동 |
| 수신 완료 비트 미확인 | 완료 조건 없이 상시 읽기 실행 |
| 이전 데이터 미초기화 | 새 데이터와 이전 데이터가 섞임 |
| 수신 길이 계산 오류 | 실제 데이터 길이보다 짧거나 길게 읽음 |
| 종료 문자 처리 오류 | CR, LF 등 종료 조건을 잘못 해석 |
| 송수신 중복 실행 | 응답 대기 중 다시 송신이 발생 |
| 버퍼 오버런 | 수신 데이터를 처리하기 전에 다음 데이터가 들어옴 |
데이터가 깨질 때는 통신선이나 파라미터만 보지 말고, 수신 완료 비트와 데이터 읽기 타이밍을 반드시 확인해야 합니다.
바코드 수신 로직의 기본 흐름
바코드 리더기나 문자열 장비와 통신할 때는 수신 완료 기준의 흐름이 중요합니다.
기본적인 수신 처리 흐름은 다음과 같이 구성할 수 있습니다.
| 단계 | 내용 |
|---|---|
| 대기 | 바코드 리딩 완료 또는 수신 완료 비트 대기 |
| 수신 | 완료 신호가 들어왔을 때 수신 데이터를 D 영역으로 이동 |
| 검사 | 수신 길이, 시작 문자, 종료 문자, 데이터 형식 확인 |
| 변환 | ASCII 문자열을 숫자 또는 내부 코드로 변환 |
| 판정 | 기준 데이터와 비교해 OK/NG 판단 |
| 초기화 | 수신 완료 비트, 임시 버퍼, 요청 플래그 정리 |
| 재대기 | 다음 바코드 수신 준비 |
이 구조에서 가장 중요한 것은 완료 신호가 들어온 한 번의 타이밍에 데이터를 읽고, 처리 후 다음 수신을 위해 상태를 정리하는 것입니다.
상시 읽기보다 이벤트 기준 읽기가 안전하다
수신 데이터를 상시로 읽는 구조는 단순해 보이지만, 실제로는 데이터 깨짐과 이전 값 잔류 문제를 만들 수 있습니다.
반대로 수신 완료 신호, 송신 완료 신호, 에러 신호 같은 이벤트를 기준으로 처리하면 로직 흐름이 명확해집니다.
| 방식 | 특징 |
|---|---|
| 상시 읽기 | 구현은 단순하지만 수신 중간 데이터까지 읽을 수 있음 |
| 완료 신호 기준 읽기 | 데이터 완성 후 처리하므로 안정적 |
| 타이머 지연 읽기 | 보조적으로 사용할 수 있으나 완료 신호보다 불확실 |
| 고정 길이 읽기 | 데이터 길이가 항상 일정할 때 사용 가능 |
| 종료 문자 기준 읽기 | CR, LF 등 종료 문자가 있는 문자열 통신에 적합 |
시리얼 통신에서는 상대 장비가 데이터를 다 보냈다는 기준을 어떻게 잡을지가 중요합니다. 완료 비트, 수신 바이트 수, 종료 문자 조건 중 어떤 방식을 사용할지 정해야 합니다.
수신 데이터 저장 영역을 분리한다
통신 데이터를 처리할 때는 수신 원본 영역, 변환 영역, 판정 영역을 분리하는 것이 좋습니다.
예를 들어 D200부터는 수신 원본 데이터, D300부터는 변환 후 숫자 데이터, D400부터는 판정 결과나 상위 전송 데이터처럼 나누어 관리할 수 있습니다.
| 영역 | 사용 목적 |
|---|---|
| 수신 원본 영역 | 통신 모듈에서 가져온 원본 데이터 저장 |
| 임시 처리 영역 | 문자 변환, 길이 계산, 비교 작업 |
| 결과 영역 | OK/NG, 품번, 수량, 판정 코드 저장 |
| 송신 영역 | 상대 장비 또는 상위 장비로 보낼 데이터 |
| 상태 영역 | 수신 완료, 송신 완료, 에러 코드 관리 |
한 D 영역을 수신, 변환, 표시, 송신에 모두 섞어 사용하면 데이터가 언제 바뀌었는지 추적하기 어렵습니다.
송신 데이터도 완료 조건을 봐야 한다
수신만 중요한 것이 아닙니다. 송신도 완료 조건을 확인해야 합니다.
송신 명령을 실행한 뒤에는 송신 완료 비트나 에러 비트를 확인하고 다음 단계로 넘어가야 합니다. 송신 완료를 확인하지 않고 계속 송신 명령을 반복하면 상대 장비가 중복 명령을 받거나 통신 버퍼가 꼬일 수 있습니다.
송신 로직에서 확인할 항목은 다음과 같습니다.
| 확인 항목 | 설명 |
|---|---|
| 송신 요청 | 어떤 조건에서 송신을 시작하는지 확인 |
| 송신 데이터 준비 | 보내기 전 데이터 영역이 완성되었는지 확인 |
| 송신 실행 | 상승엣지 또는 1회성 조건으로 실행되는지 확인 |
| 송신 완료 | 완료 비트가 들어왔는지 확인 |
| 송신 에러 | 타임아웃, 프레임 오류 등 확인 |
| 다음 단계 | 완료 후 수신 대기로 넘어가는지 확인 |
통신 명령은 매 스캔 반복 실행하는 구조보다 요청, 실행, 완료, 정리 순서가 있는 상태 흐름으로 만드는 것이 안정적입니다.
통신 로직에서 자주 발생하는 실수
통신 데이터 처리 단계에서 자주 발생하는 실수는 다음과 같습니다.
| 실수 | 결과 |
|---|---|
| 완료 신호 없이 G.INPUT 실행 | 데이터 일부만 읽거나 이전 데이터와 섞임 |
| 송신 명령을 매 스캔 실행 | 중복 송신 또는 상대 장비 응답 혼선 |
| 수신 버퍼 초기화 누락 | 이전 데이터가 남아 새 데이터와 혼동 |
| 수신 길이 확인 누락 | 짧은 데이터나 비정상 데이터도 정상 처리 |
| 에러 비트 확인 안 함 | 통신 실패 상태를 정상으로 판단 |
| 채널 또는 모듈 번호 착오 | 다른 포트의 데이터만 확인 |
| D 영역 중복 사용 | 수신값이 다른 로직에서 덮어써짐 |
통신은 신호가 보이는 것만으로 정상이라고 판단하면 안 됩니다. 요청과 응답, 완료와 초기화가 순서대로 맞아야 합니다.
통신 데이터 처리 체크리스트
배선과 파라미터가 맞는데도 데이터가 정상적으로 처리되지 않을 때는 다음 항목을 확인합니다.
| 점검 항목 | 확인 내용 |
|---|---|
| 모듈 번호 | G.INPUT/G.OUTPUT 또는 FROM/TO 대상 모듈이 맞는지 |
| 채널 | 실제 통신 채널과 로직에서 사용하는 채널이 일치하는지 |
| 수신 완료 | 완료 비트를 기준으로 데이터를 읽는지 |
| 송신 완료 | 송신 완료 후 다음 단계로 넘어가는지 |
| 수신 길이 | 실제 데이터 길이와 읽는 길이가 맞는지 |
| 종료 조건 | CR, LF 또는 고정 길이 조건이 맞는지 |
| 초기화 | 처리 후 완료 비트와 임시 영역을 정리하는지 |
| 에러 코드 | 통신 에러 상태를 확인하고 분기하는지 |
| D 영역 | 수신, 변환, 결과, 송신 영역이 분리되어 있는지 |
| 실행 조건 | 통신 명령이 매 스캔 중복 실행되지 않는지 |
이 항목을 확인하면 통신이 붙었는데 데이터가 이상한 경우의 원인을 좁힐 수 있습니다.
통신 데이터 처리 단계 정리
RS232/RS485 통신은 배선과 파라미터를 맞추는 것에서 끝나지 않습니다. 통신 모듈 안에 들어온 데이터를 PLC CPU가 언제 읽고, 어디에 저장하고, 어떤 조건에서 처리하는지가 중요합니다.
통신 모듈의 버퍼 메모리는 외부 장비와 CPU 사이에서 데이터를 임시로 보관하는 영역입니다. PLC는 FROM/TO 또는 G.INPUT/G.OUTPUT 같은 명령을 이용해 데이터를 읽고 써야 합니다. 실제 명령어와 버퍼 주소는 사용하는 모듈과 프로젝트 구성에 따라 달라질 수 있으므로 매뉴얼 기준으로 확인해야 합니다.
데이터가 깨지는 가장 흔한 원인 중 하나는 수신 완료 전에 데이터를 읽는 것입니다. 시리얼 통신은 데이터가 순차적으로 들어오기 때문에 완료 비트, 수신 길이, 종료 문자 조건을 기준으로 데이터를 읽어야 합니다.
송신 역시 요청, 실행, 완료, 에러 확인, 정리 순서로 구성해야 합니다. 통신 명령을 상시 실행하거나 수신 버퍼를 정리하지 않으면 중복 송신, 이전 데이터 잔류, 부분 수신 문제가 생길 수 있습니다.
통신 LED가 깜빡인다면 이제부터는 로직 안에서 데이터가 어떻게 이동하는지를 봐야 합니다. 배선, 파라미터, 프로토콜을 확인한 뒤에는 버퍼 메모리와 수신 완료 신호 기준의 데이터 처리 구조를 점검하는 것이 다음 단계입니다.