Modbus 收到 83 02 是读数吗：怎样严格拆分正常与异常 PDU

83 02 是请求功能 03 对应的异常 PDU：83 表示功能码最高位置一，02 是 Illegal Data Address。它没有寄存器读数，必须在读取 byte count 和数据之前进入异常分支。

适用版本与输入范围

依据 Modbus Application Protocol V1.1b3（2012-04-26），按下方具体功能章节解释PDU。输入已经剥离RTU地址、CRC或TCP封装，不把封装检查与数据字段解析混为一体。 本文所有输入均为原创合成数据，未接真实设备。

先取功能码，再决定后续结构

同一请求可能得到正常响应，也可能得到异常响应。正常 03 02 00 2A 中的第二字节 02 是数据字节数，而异常 83 02 中的第二字节 02 是异常码；如果先把第二字节统一解释成长度，异常回包会被当成“还缺两个数据字节”。附件同时提供这两种结构，程序根据功能码最高位先分流，再使用该分支自己的字段规则，不靠总长度猜类型。

异常响应必须关联原请求

最高位置一后仍要用低七位核对原始功能码。附件中 request_fc=4 却收到 83 02，是明确的关联错误；不能因为异常码能查到名称，就把它挂到读输入寄存器请求上。异常 PDU 自身应恰好两字节，第三个多余字节不是可忽略的寄存器值。程序把这两种反例分别拒绝，方便调用层区分关联问题和报文形状问题。

未知异常码应保留原始数字

规范列出了常见异常类别，但真实日志中可能出现未识别编码、厂商扩展或受损数据。示例对 7F 保留数值并标注未知，不擅自把它归为地址错误。02 表示请求的地址组合不允许，例如起始地址和数量形成的访问范围不受支持；它本身不能证明一定发生了零基地址偏移。上层应结合设备映射与请求范围判断，不应由异常名直接生成一条现场修复结论。

解析器的正常分支明确限缩

为了让附件易于独立复跑，正常分支只支持本题用到的 03 寄存器读取响应，验证偶数字节数后输出十六位字；它并不是覆盖所有功能码的通用库。异常分支则按给定请求功能关联，并保留码值。报告的 kind 会区分 normal 和 exception，避免数据库把异常码当成有效温度。没有响应、CRC错误或链路中断不在这组PDU输入里，也不能简单归为同一个异常码。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。kind区分数据与异常；exception_code保留原数字，name只作为解释，不替代设备点表。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到Modbus 寄存器映射基础核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• §7 Exception Responses

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。