설비나 전력 계측기에 Modbus로 붙이면 처음 며칠은 연결 자체와 싸우게 됩니다. 그 단계를 넘기면 응답은 정상으로 돌아오는데, 화면에 뜬 숫자가 설비 조작판의 숫자와 다릅니다. 온도가 25.3도인데 253으로 읽히거나, 압력 자리에 6553.5 같은 값이 들어옵니다.
이때 회의에서 나오는 말은 대개 둘입니다. 개발사는 장비가 값을 이상하게 준다고 하고, 설비 업체는 자기 계기판은 정상이라고 합니다. 둘 다 거짓말이 아니라서 논쟁이 길어집니다. 숫자가 틀리는 원인은 통신이 아니라 해석 규칙이고, 규칙이 갈리는 지점은 다섯 곳으로 정해져 있습니다.
응답이 정상으로 왔다면 배선과 통신 설정은 이미 통과한 것입니다
예외 응답 없이 요청한 개수만큼 레지스터가 돌아왔다면 선로, 통신 속도, 패리티, 슬레이브 주소는 맞은 것입니다. 이 중 하나라도 틀리면 값이 이상하게 오는 게 아니라 응답이 아예 오지 않습니다. 검사값이 깨진 프레임도 장비가 조용히 버립니다.
그래서 남은 문제는 하나뿐입니다. 받아온 16비트 덩어리를 무슨 뜻으로 읽을지입니다. 책임 소재도 여기서 갈립니다. 해석 규칙이 설비 업체 문서에 적혀 있는데 다르게 읽었으면 개발사 몫이고, 문서에 아예 없으면 설비 업체에 받아야 하는 정보입니다.
연결된 뒤에 틀리는 숫자는 장비 고장이 아니라 문서 문제입니다. 고칠 대상은 배선이 아니라 레지스터 맵입니다.
첫 번째로 레지스터 주소 1 차이를 의심하세요
Modbus 공식 규격(MODBUS Application Protocol Specification V1.1b3)은 레지스터 주소를 0부터 매깁니다. 규격 문장 그대로 1번부터 16번까지의 레지스터는 0부터 15로 주소가 붙습니다. 반면 설비 문서는 사람이 읽기 쉽게 40001번처럼 1부터 시작하는 번호로 적는 관행이 굳어져 있습니다.
증상이 특이해서 알아보기 쉽습니다. 전압 자리에 전류가 들어오는 것처럼 바로 옆 항목 값이 읽히고, 맵의 마지막 레지스터를 읽을 때만 예외 코드 02(잘못된 데이터 주소)가 돌아옵니다. 읽는 주소를 1 줄여서 값이 제자리로 오는지 먼저 확인하세요.
두 번째로 워드 순서를 확인하세요
Modbus 규격은 16비트 레지스터 하나를 보낼 때 상위 바이트를 먼저 보낸다는 것까지만 정합니다. 32비트 실수나 32비트 정수를 레지스터 두 개에 어떤 순서로 담을지는 규격에 없습니다. 그래서 기기마다 상위 워드가 먼저인 경우와 하위 워드가 먼저인 경우가 모두 실제로 존재합니다.
순서가 뒤바뀌면 오차가 아니라 완전히 다른 숫자가 나옵니다. 수억 단위 값이나 0.0000x 같은 값이 보이고, 설비 값이 조금 변할 때 화면 숫자가 엉뚱한 방향으로 튑니다. 32비트 항목만 이상하고 16비트 항목은 정상이라면 거의 이 문제입니다.
세 번째로 스케일 배율을 맞추세요
16비트 레지스터 하나에는 소수점을 담을 방법이 없습니다. 그래서 25.3도를 253으로, 역률 0.95를 95나 950으로 보내는 기기가 많습니다. 실무에서는 계기판 표시값과의 차이가 정확히 10배, 100배, 1000배로 떨어지면 스케일 배율을 안 나눈 것입니다.
주의할 점은 배율이 항목마다 다르다는 것입니다. 전압은 0.1 단위, 전력량은 1 단위, 온도는 0.01 단위인 기기가 흔합니다. 프로그램에 전역 배율을 하나만 두면 나중에 항목이 추가될 때마다 같은 사고가 반복됩니다.
네 번째로 부호 있는 값 해석을 확인하세요
16비트 레지스터에 담긴 -1은 그대로 읽으면 65535입니다. 부호 없는 값으로 읽고 0.1을 곱하면 영하 1도가 6553.5도로 표시됩니다. 앞에서 예로 든 6553.5가 정확히 이 경우입니다.
이 문제가 위험한 이유는 평소에 드러나지 않는다는 점입니다. 영하 온도, 역방향 유량, 음의 유효전력처럼 값이 음수가 되는 조건에서만 나타납니다. 여름에 검수를 끝내고 겨울에 사고가 나는 전형적인 항목이라, 검수 단계에서 음수가 나오는 상황을 일부러 만들어 확인해야 합니다.
다섯 번째로 함수 코드를 확인하세요
규격에는 읽기 함수 코드가 넷 있습니다. 코드 03은 읽고 쓸 수 있는 홀딩 레지스터를, 코드 04는 읽기 전용인 입력 레지스터를 읽습니다. 두 영역은 번호가 겹치지만 내용은 완전히 다른 표입니다. 문서의 40001번대는 코드 03, 30001번대는 코드 04를 가리키는 관행이 일반적입니다.
함수 코드를 잘못 고르면 전혀 무관한 값이 오거나 예외 코드 02가 돌아옵니다. 앞의 네 항목을 다 만져도 값이 맞지 않으면 대개 여기서 어긋나 있습니다. 설비 업체에 물을 때는 항목별로 어느 함수 코드로 읽어야 하는지를 명시해 달라고 하세요.
한 번에 한 항목만 바꿔야 원인을 찾습니다
주소와 워드 순서를 동시에 바꾸면 우연히 그럴싸한 값이 나올 때가 있습니다. 그렇게 맞춘 설정은 값이 커지거나 음수가 되는 순간 다시 깨집니다. 한 번 고칠 때 한 항목만 바꾸고, 바꾼 내용을 기록하세요.
기준 데이터도 미리 확보해야 합니다. 설비 조작판의 표시값과 그 순간 읽힌 원시 16진수 두 워드를 같은 시각에 적어 두면, 다섯 항목이 거의 계산으로 결정됩니다. 순서를 주소부터 시작하는 이유도 같습니다. 주소가 틀리면 나머지 네 개를 판단할 근거 자체가 없습니다.
레지스터 맵에 이 항목들이 적혀 있는지 확인하세요
설비 업체에서 받은 레지스터 맵을 펴고 아래 일곱 줄을 찾아보세요. 항목 이름과 주소 번호만 적힌 표는 절반만 온 문서입니다.
- 주소 표기 기준: 40001식 번호인지, 프레임에 실리는 0부터 시작하는 주소인지 한 줄로 밝혀 놓았는지
- 함수 코드: 항목마다 03과 04 중 무엇으로 읽는지
- 데이터 타입과 길이: 16비트 정수인지 32비트 정수·실수인지, 레지스터를 몇 개 차지하는지
- 부호 유무: 음수가 나올 수 있는 항목인지
- 워드 순서: 32비트 항목에서 상위 워드가 앞인지 뒤인지
- 배율과 단위: 항목별 배율, 그리고 W인지 kW인지
- 한 번에 읽을 수 있는 최대 개수
마지막 줄도 실무에서 자주 걸립니다. 규격상 홀딩 레지스터와 입력 레지스터는 한 요청에 최대 125개까지 읽을 수 있지만, 소형 기기는 이보다 훨씬 적게 제한하는 경우가 흔합니다. 이 숫자는 기기 문서에서만 확인할 수 있습니다.
맵에 항목이 없으면 검증 데이터 한 쌍을 요청하세요
문서에 일곱 줄이 다 있으면 문제는 개발사 구현 쪽입니다. 없으면 설비 업체에 요청할 차례이고, 이때 "자료 주세요"보다 항목을 짚는 편이 훨씬 빨리 옵니다. 데이터 타입, 부호, 워드 순서, 배율, 함수 코드를 레지스터 번호별로 달라고 적으세요.
더 확실한 요청은 검증 데이터 한 쌍입니다. 특정 시각의 계기판 표시값과 그때 그 레지스터의 원시 16진수를 함께 받으면, 문서가 부실해도 해석 규칙을 역산할 수 있습니다. 구형 기기나 OEM 납품 설비는 문서가 남아 있지 않은 경우도 실제로 많으므로, 역산한 규칙을 문서로 정리하는 작업은 견적에 포함시키는 편이 맞습니다. 비슷한 현장 점검 방식은 실무 가이드와 개발 노트에 이어서 정리하고 있고, 설비 연동 개발이 필요하면 Codeforest로 문의하세요. 함수 코드와 주소 체계의 원문은 Modbus 공식 규격 페이지에서 확인할 수 있습니다.
이 순서가 맞지 않는 경우도 있습니다
값이 간헐적으로만 튀고 타임아웃이나 프레임 오류가 섞여 있다면 해석 문제가 아닙니다. 그때는 종단 저항, 접지, 폴링 주기부터 보셔야 하고, 위 다섯 항목을 아무리 바꿔도 증상이 그대로 남습니다. 판단 기준은 단순합니다. 같은 조건에서 항상 같은 틀린 값이 나오면 해석 문제이고, 값이 매번 다르면 회선 문제입니다.
중간에 게이트웨이나 PLC를 거쳐 값을 받는 구조도 예외입니다. 변환 장비가 이미 워드 순서나 배율을 한 번 바꿔 놓았을 수 있어서, 설비 문서대로 맞췄는데도 틀립니다. 이때는 설비 문서보다 중간 장비의 매핑 설정을 먼저 확인하세요.
결론: 숫자가 틀리면 문서를 펴고 다섯 항목을 순서대로 확인하세요
통신이 연결된 뒤에 나오는 틀린 숫자는 주소 1 차이, 워드 순서, 스케일 배율, 부호 해석, 함수 코드 중 하나입니다. 이 순서로 하나씩, 한 번에 하나만 바꿔 보면 대개 반나절 안에 찾습니다. 기준값 한 쌍만 확보해도 추측 단계가 사라집니다.
누구 쪽 문제인지도 문서로 정리됩니다. 레지스터 맵에 일곱 항목이 적혀 있는데 값이 틀리면 개발사가 고칠 일이고, 적혀 있지 않으면 설비 업체가 채워야 할 정보입니다. 그래서 발주 단계에서 레지스터 맵에 이 항목들을 명시해 달라고 요구하는 것이, 나중에 원인을 찾느라 쓰는 시간보다 훨씬 쌉니다.
