MODBUS 데이터 해석
통신은 성공했는데 측정값이 잘못될 수 있는 이유는 무엇일까요?
데이터 교환에 성공하면 레지스터 내용은 전달되지만, 애플리케이션이 이를 어떻게 해석해야 하는지까지 입증되는 것은 아닙니다. 32비트 값을 해석하려면 올바른 워드 단위 배열, 데이터 유형, 스케일링 및 단위가 필요합니다. 또한 일관된 업데이트 시점도 필요합니다. 장치 레지스터 맵부터 확인하고 원시 응답을 보관하십시오. 이는 일반적인 개념이며, 특정 계측기의 구성이나 원자적 스냅샷을 보장하는 내용이 아닙니다.
바이트
표준 16비트 레지스터는 순서가 정해진 두 바이트로 전송됩니다.
워드
장치 맵과 올바른 데이터 유형을 사용하여 워드 단위로 값을 재구성합니다.
시점
두 워드가 하나의 일관된 업데이트에 속하는지 확인합니다.
주소 표기법, 레지스터 수, 유형, 스케일 및 단위를 확인합니다.
권한이 있는 읽기 요청 하나와 이에 대응하는 응답을 저장합니다.
업데이트 동작과 게이트웨이 캐시의 타임스탬프가 있다면 이를 확인합니다.
선정 및 검증 체크리스트 — 펼치기
| 점검 항목 | 확인할 사항 | 검증 방법 |
|---|---|---|
| 인코딩 | 바이트 및 워드 단위 순서 | 원시 바이트를 공식 맵과 비교 |
| 의미 | 데이터 유형, 스케일 및 단위 | 알려진 값 여러 개로 확인 |
| 최신성 | 일관된 업데이트 및 캐시 경과 시간 | 구현 문서와 타임스탬프 근거 확인 |
계측기는 25을 표시하는데 컴퓨터에는 비현실적인 소수 값이 나타나고 통신 로그에는 성공으로 기록됩니다. 반드시 케이블이나 광섬유에 결함이 있는 것은 아닙니다. 데이터가 온전하게 도착한 뒤 잘못 해석되었을 수 있습니다. Modbus 워드 순서를 이해하는 데 한 페이지 분량의 수식은 필요하지 않습니다. 레지스터에 무엇이 들어 있는지, 메시지가 이를 어떻게 전달하는지, 소프트웨어가 값을 어떻게 재구성하는지 따라가 보면 전송 성공과 올바른 측정값을 구분할 수 있습니다.
번호가 붙은 데이터 칸부터 이해하기
Modbus는 산업용 장치 데이터를 교환하는 규칙을 정의합니다. 홀딩 레지스터나 입력 레지스터를 읽을 때는 장치의 데이터 영역을 번호가 붙은 칸들이 한 줄로 나열된 것으로 생각해 보십시오. 각 레지스터에는 16비트, 즉 두 바이트가 들어가며 각 바이트는 8비트로 구성됩니다. 이는 논리적인 데이터 단위이며, 계측기 내부에 개별 칩이 물리적으로 한 줄로 배치되어 있다는 뜻은 아닙니다.
번호는 소프트웨어에 어디를 확인해야 하는지 알려 주지만, 그곳에 무엇이 저장되어 있는지까지 완전히 설명하지는 않습니다. 동일한 두 바이트가 부호 없는 정수일 수도 있고 상태 플래그 모음일 수도 있습니다. 장치 레지스터 맵은 해당 데이터가 온도, 압력, 에너지 또는 다른 무엇을 의미하는지 설명합니다. 맵을 포장 명세서처럼 생각하십시오. 주소, 데이터 유형, 단위, 스케일링 및 유효 조건은 함께 확인해야 합니다. 주소만 복사하는 것으로는 충분하지 않습니다.
주소 표기법도 확인하십시오. 설명서에는 40001 같은 홀딩 레지스터 참조 번호가 사용되지만 메시지에는 시작 오프셋이 사용될 수 있으며, 일부 소프트웨어는 사용자를 대신해 이를 변환합니다. 같은 문서의 요청 예시와 비교하여 인터페이스가 참조 번호를 요구하는지 오프셋을 요구하는지 확인하십시오. 이렇게 하면 읽기 위치 전체가 한 칸씩 어긋나는 것을 방지할 수 있습니다. 주소 오류를 보정하려고 워드를 반복해서 맞바꾸면 진단만 더 어려워집니다.
레지스터에서 어느 바이트가 먼저 전송될까요?
예시 레지스터 값 0x1234은 바이트 12와 34으로 나눌 수 있습니다. 16진수 표기는 원시 데이터를 간결하게 기록하는 방법일 뿐, 현장에서 필요한 고급 계산이 아닙니다. 표준 Modbus 레지스터 인코딩은 상위 바이트 12를 하위 바이트 34보다 앞에 배치합니다. 수신 소프트웨어는 이 순서를 사용하여 동일한 16비트 내용을 복원합니다.
이는 메시지 내의 바이트 순서를 설명하는 것으로, 바이트 안에서 개별 직렬 비트가 전송되는 순서와 혼동해서는 안 됩니다. 컴퓨터 메모리 배치도 별개의 문제입니다. 프로세서의 기본 저장 방식이 애플리케이션에 프로토콜의 메시지 인코딩을 바꿀 권한을 부여하지는 않습니다. 캡처에는 메시지 바이트가 표시되지만, 디버거에는 이미 변환된 메모리 값이 표시될 수 있습니다. 둘을 비교하기 전에 관찰 지점을 확인하십시오.
레지스터가 두 개이면 워드 순서가 중요해집니다
32비트 값은 하나의 16비트 레지스터에 들어갈 수 없으며, 일반적으로 인접한 두 레지스터를 차지합니다. 각 레지스터 안의 바이트 순서 외에도 또 다른 질문이 생깁니다. 앞쪽 레지스터가 전체 값의 상위 16비트를 담는지, 아니면 하위 16비트를 담는지입니다. 이것이 여기서 다루는 워드 순서입니다. 장치와 구성에 따라 다를 수 있으므로 Modbus 지원만으로 공통된 배열 방식이 정해지는 것은 아닙니다.
예를 들어 IEEE 754 단정밀도 부동소수점 형식의 25.0은 네 바이트 41 C8 00 00로 구성됩니다. 설명용 레지스터 맵의 한 예에서는 레지스터 N에 41C8을, N+1에 0000를 배치하고, 다른 예에서는 두 워드의 순서를 반대로 배치합니다. 각각의 맵에 따라 읽고 재구성하면 둘 다 25.0이 됩니다. 두 번째 맵에 첫 번째 해석 방식을 적용하면 데이터 교환에 성공했어도 완전히 잘못된 값이 나올 수 있습니다. 이는 학습용 예시이며 실제 계측기 주소나 설정이 아닙니다.
워드 교환과 워드 내부의 바이트 교환은 다릅니다
각각 위쪽과 아래쪽 페이지가 있는 두 권의 책이 네 데이터 바이트를 나타낸다고 생각해 보십시오. 책의 위치를 서로 바꾸는 것은 두 16비트 워드를 맞바꾸는 것과 비슷하고, 각 책 안의 페이지를 서로 바꾸는 것은 워드 내부의 바이트를 맞바꾸는 것과 비슷합니다. 두 작업이 영향을 미치는 경계는 서로 다릅니다. 빅엔디언, 리틀엔디언 또는 스왑 같은 소프트웨어 표시는 서로 다른 수준을 가리킬 수 있으므로 메뉴 이름만으로는 어떤 변환인지 판단할 수 없습니다.
수신된 순서대로 네 원시 바이트를 기록하고 그 옆에 소프트웨어의 재구성 순서를 적으십시오. 명확하게 식별된 해석 설정을 한 번에 하나씩 변경하며 공식 레지스터 맵과 비교하십시오. 모든 포인트에 같은 스왑을 무작정 적용하거나 그럴듯한 숫자 하나를 전체 맵이 올바르다는 증거로 삼지 마십시오. 0에 가까운 값은 순서 오류를 감출 수 있으므로, 알려져 있고 서로 구별되는 여러 값으로 확인하십시오.
Modbus RTU 프레임 끝의 CRC는 전송된 내용이 변경되었는지 확인하는 데 도움이 되는 오류 검출 코드입니다. 장치가 의도적으로 하위 워드 우선 데이터를 반환한다면 해당 CRC는 유효할 수 있습니다. 이후 소프트웨어가 이를 상위 워드 우선으로 해석하더라도 CRC가 그 해석 오류를 보고하지는 않습니다. 다른 유효한 주소를 읽은 경우에도 검사를 통과할 수 있습니다. 도착한 데이터와 그 해석 방식에 대한 근거를 별도로 보관하십시오.
같은 바이트라도 다른 해석이 필요할 수 있습니다
올바른 순서는 여러 요건 중 하나일 뿐입니다. 32비트 정수와 32비트 부동소수점 값은 서로 다른 방식으로 해석합니다. 부동소수점 형식은 소수 값을 표현할 수 있지만, 모든 4바이트 항목을 부동소수점으로 디코딩해야 한다는 뜻은 아닙니다. 부호 있는 정수는 음수를 허용하는 반면, 부호 없는 정수는 값의 범위를 다르게 해석합니다. 화면의 값이 얼마나 그럴듯한지를 보고 추측하지 말고 장치 문서에서 이러한 선택 사항을 확인하십시오.
스케일링과 단위 역시 해석 과정의 일부입니다. 레지스터 맵에 원시 정수 253이 섭씨 25.3도를 뜻한다고 명시되어 있다면, 소프트웨어는 섭씨 253도로 표시하지 말고 해당 규칙을 적용해야 합니다. 이는 위의 부동소수점 값 25.0과는 별개의 예시입니다. 무효 값 인코딩, 오프라인 표시 및 예약 비트도 확인하십시오. 사용 불가를 뜻하는 특수 코드를 정상 측정값으로 그래프에 표시하면 그럴듯하지만 실제로는 없는 공정 이상이 나타날 수 있습니다.
순서가 올바르더라도 일관된 샘플링 시점이 필요합니다
두 레지스터를 별도의 요청으로 읽으면 읽기 사이에 장치가 업데이트될 수 있습니다. 설명을 위해 32비트 부호 없는 카운터가 0000 FFFF에서 0001 0000으로 바뀌는 경우를 생각해 보십시오. 이전 상위 워드 0000를 읽은 다음 새로운 하위 워드 0000를 읽으면 0000 0000이 됩니다. 이 결과는 완전한 이전 값도, 완전한 새로운 값도 아닙니다. 문제는 샘플링 일관성입니다.
하나의 요청으로 연속된 두 레지스터를 읽으면 일반적으로 별도 요청으로 인해 생기는 시간 간격을 줄일 수 있지만, 모든 장치가 원자적 스냅샷을 제공한다는 증거는 아닙니다. 구현 문서에서 래칭, 갱신 동작, 일관된 업데이트를 식별하는 시퀀스 번호 또는 타임스탬프를 확인하십시오. 게이트웨이가 데이터를 캐싱한다면 캐시 업데이트 시간도 기록하십시오. 새로 반환된 메시지에 반드시 새로 측정된 값이 들어 있는 것은 아니며, 폴링 속도를 높이는 것으로 일관성 메커니즘을 대체할 수는 없습니다.
통신 경로별 역할 구분
FCTELE 웹사이트에는 광섬유를 통해 Modbus 직렬 통신을 지점 간 전송하는 FCP-D8G 산업용 DIN 레일 Modbus 광 모뎀이 소개되어 있습니다. 이는 유용한 역할 구분을 보여 줍니다. 광 링크는 통신 데이터를 전송하고, 계측기 레지스터 맵은 그 의미를 정의합니다. Modbus 광 모뎀을 사용한다고 해서 모든 계측기의 부동소수점 워드 순서를 자동으로 인식하거나, 단위를 변환하거나, 동기화된 측정 스냅샷을 제공한다는 뜻은 아닙니다. 실제 기능은 해당 제품 버전의 문서와 대조하여 확인하십시오.
장치 하나와 읽기 권한이 있는 읽기 전용 포인트 하나로 검증을 시작하십시오. 동일한 트랜잭션의 요청과 응답을 저장하고 대상, 기능 코드, 시작 주소 표기 규칙 및 레지스터 수를 확인한 다음 원시 레지스터, 워드 순서, 데이터 유형, 스케일링, 단위 및 업데이트 시간을 점검하십시오. 무결성 검사에 성공하는 것은 하나의 단계일 뿐, 업무상 해석이 올바르다는 증거는 아닙니다. 다른 포인트로 작업을 확대하기 전에 이 전체 읽기 과정을 설명하고 문서화하십시오. 이 기록은 이후 계측기나 소프트웨어 패키지가 변경될 때 체계적인 점검의 근거가 됩니다.
로컬 도구에서는 포인트가 올바르게 읽히지만 광 링크를 경유하면 잘못 읽힌다면, 동일한 구성에서 동일한 장치의 원시 응답을 비교한 다음 채널 선택, 직렬 통신 설정 및 로그를 점검하십시오. 원시 바이트가 같은데 표시 값이 다르다면 디코더 설정을 살펴봐야 합니다. 바이트가 다르거나 트랜잭션이 일치하지 않는다면 통신 경로를 따라 추가로 조사해야 합니다. 이러한 순서는 실제 전송 장애를 워드 순서 문제로 치부하지 않으면서도 불필요한 하드웨어 교체를 줄여 줍니다.
참고 자료 및 범위
Modbus Organization: 레지스터 및 데이터 형식; 애플리케이션 프로토콜 V1.1b3, 4.2절: 바이트 인코딩; Schneider Electric: 레지스터 매핑 및 워드 순서 예시; Schneider Electric: 워드 순서가 바뀐 부동소수점 값 읽기; FCTELE FCP-D8G Modbus 광 모뎀 정보(중국어). 타사 설정은 FCTELE 제품의 기능을 입증하지 않습니다. 그림과 예시는 독자적으로 제작한 설명 자료이며, 측정 결과나 배선 지침이 아닙니다.
다음 중국어 기술 문서에서 번역: 중국어 원문 읽기.
자주 묻는 질문
Modbus 데이터 교환에 성공해도 잘못된 값이 표시될 수 있는 이유는 무엇인가요?
전송과 해석은 별개입니다. 대상, 주소 표기 규칙, 레지스터 수, 워드 순서, 데이터 유형, 스케일링, 단위 및 업데이트 시간을 확인하십시오. 유효한 CRC가 업무상 해석의 정확성을 입증하지는 않습니다.
두 레지스터를 맞바꾸는 것은 바이트를 맞바꾸는 것과 같은가요?
아닙니다. 하나는 완전한 16비트 워드의 위치를 바꾸는 것이고, 다른 하나는 워드 내부의 바이트 위치를 바꾸는 것일 수 있습니다. 메뉴 표시만 보지 말고 장치 맵과 실제 재구성 방식을 확인하십시오.
한 번의 요청으로 두 레지스터를 읽으면 동일한 샘플링 시점이 보장되나요?
아닙니다. 블록 읽기는 별도 요청으로 인해 생기는 시간 간격을 줄일 수 있지만, 원자적 스냅샷, 래칭 및 갱신 동작은 구현에 따라 달라집니다. 게이트웨이에 캐싱된 데이터도 업데이트 시간을 확인해야 합니다.
