行业背景：这个问题现在为什么被反复问到
把存量串口仪表接入采集系统时，开发者首先面对的往往不是业务接口，而是一份寄存器表。手册列出地址、数据类型和量程，程序却必须把这些说明转换成请求，再把响应还原成带单位的测量值。采集脚本的问题由此分成两层：能不能读到数据，以及读到的数据能不能被业务正确使用。
Modbus RTU 负责请求与响应的组织，并不替设备统一测点含义。同样读出一个寄存器，数值可能需要缩放，也可能代表状态而非测量结果；跨多个寄存器的数据还要核对组合顺序。因此，串口收到字节不能直接算作点位采集成功，映射和解码同样属于采集链路。
当读取从手动调试变成周期任务，失败也必须有明确含义。设备返回异常响应，与等待超时不是同一类问题；沿用上次的值，更不能表示本次读取正常。缺少时间和质量标记，下游就无法区分新数据、旧数据与无效数据。
本文只讨论单主站 Modbus RTU 的读取链路，不涉及设备写控制。后文从寄存器映射、异常分类和有限重试展开，用教学模拟验证脚本逻辑；模拟通过不等于真实串口联调通过，也不作为现场运行效果的证明。
痛点：现场到底卡在哪几步
现场排查最容易走偏的地方，是把所有失败都归结为“串口不通”。应先按层次缩小范围：核对接线与接口标识，再确认波特率、数据位、校验位和停止位是否一致，随后检查从站地址。没有响应时，这些条件都值得核查，但超时本身不能证明哪一项有错，更不能直接证明设备离线。
收到响应以后，要对照手册核实功能码、起始地址和读取数量。保持寄存器与输入寄存器不能只凭地址长得相似就混用；手册展示的寄存器编号，也未必就是请求中填写的协议地址。有的手册给展示编号，有的直接给偏移，必须结合地址说明或已知测点确认，不能统一“减一”。读取范围还要完整覆盖数据类型需要的寄存器，并避开未定义区域。
数值看似合理仍不代表解码正确。有符号数与无符号数、整数与浮点数的解释不同，跨寄存器数据还涉及字序；字节序须按协议和设备说明核实，不能为了贴近期望值随意交换。最后再应用缩放与单位，并识别手册规定的无效值，否则特殊标记也可能被换算成测量结果。
日志应把三类失败分开：无响应记录超时条件，异常响应保留异常码，解码错误记录类型或长度不符等原因。保留上次有效值可以服务展示，但必须连同原采集时间和陈旧标记输出，不能把旧值当成本次成功，也不能用零值掩盖失败。
方案：可落地的结构与取舍
采集链路可以拆成四步：读取映射配置、串行发出请求、解码并标记质量、输出结果与日志。把设备差异留在配置中，让采集逻辑只处理明确的读取任务。每个点位至少记录名称、从站地址、功能码、协议起始地址、寄存器数量、数据类型、字节序、字序、缩放、单位和无效值规则，并保留对应手册条目的依据与映射版本，便于复核配置变更。
同一条串口总线由一个调度入口顺序读取，一次请求结束后再处理下一次，避免多个任务争抢响应。不同总线可以独立调度，但都要有各自的超时和周期预算。先逐点验证映射，再把同一从站、相同功能码且地址连续的点位合并读取；合并范围不能跨越手册未定义区域，多寄存器数据也不能被拆断。
重试策略按失败类别配置。地址或功能码错误应先修正请求，不能靠反复发送解决；忙碌响应和超时可按条件退避重试，同时限定尝试次数与总耗时。总耗时必须覆盖请求等待及重试间隔，预算耗尽就结束本次读取，把机会留给后续点位，避免单台设备拖住整轮采集。
输出统一包含点位、采集时间、数值、单位、质量、错误类别和尝试次数。只有响应校验与解码均通过，才标记本次成功；失败输出明确状态，历史有效值另带原时间和陈旧标记。这样，后续接入存储或展示时仍能追溯一次读取究竟发生了什么。
技术实现：字段、接口与数据口径
先验证配置到结果的闭环，再接真实串口。以下示例仅使用 Python 3.9 标准库，无需安装采集依赖；它是可执行的逻辑模拟，不是能直接连接设备的 RTU 驱动。为避免把未验证的第三方接口写成教程，本节不提供串口库安装命令。后续选库时须固定版本，并另验串口参数、帧间隔、CRC、响应地址与功能码，不能拿模拟通过代替这些检查。
配置中的 address 是协议偏移，不是手册展示编号。本例只实现一个有符号十六位点位：一个寄存器，乘以 scale 后输出 unit；65535 被指定为教学无效值，并非协议统一规定。真实点表须按设备手册替换，同时保存映射版本；浮点数和跨寄存器字序不在本例实现范围内，不应直接套用此解码器。
传输接口 read(point, timeout) 接收点位配置与本次剩余等待时长，返回已校验的寄存器列表；收到异常响应则抛 DeviceError，超时则抛 TimeoutError。按《MODBUS Application Protocol Specification V1.1b3》第7节，异常码 01、02、03 分别表示非法功能、非法数据地址、非法数据值，06 表示设备忙。本例前三者立即结束，忙碌与超时有限重试，其余设备异常默认停止，避免无差别重发。
总预算用单调时钟计算，单次等待取剩余预算与请求超时的较小者；退避也计入预算。这里最多三次尝试，不是首次之外再重试三次。传输实现必须遵守传入的 timeout，否则外层预算不能强制中断阻塞调用；上线时还要核对库自身的重试设置，避免内外叠加。
联调前还应检查点表必填项、地址范围与功能码是否受支持，错误配置应在调度前拒绝。日志保留映射版本和错误类别即可，不输出现场连接信息。示例仅接收上述固定结构，不是通用配置校验器；测试输入也全部为教学构造，不代表任何设备的真实寄存器定义。
# expect: PASS: normal signed busy timeout limits decode invalid budget
from datetime import datetime, timezone
from time import monotonic, sleep
POINT = dict(name="temperature", slave=1, function=3, address=0,
count=1, dtype="int16", scale=0.1, unit="degC",
invalid=65535, map_version="teaching-1")
class DeviceError(Exception):
def __init__(self, code):
self.code = code
def collect(read, point=POINT, now=monotonic, pause=sleep, budget=0.5):
deadline = now() + budget
result = dict(point=point["name"], unit=point["unit"], value=None,
quality="bad", error=None, attempts=0, sampled_at=None,
attempted_at=datetime.now(timezone.utc).isoformat(),
map_version=point["map_version"])
for attempt in range(1, 4):
remaining = deadline - now()
if remaining <= 0:
result["error"] = "budget_exhausted"
break
result["attempts"] = attempt
retry = False
try:
regs = read(point, min(0.2, remaining))
if now() >= deadline:
result["error"] = "budget_exhausted"
break
if (len(regs) != point["count"] or len(regs) != 1
or type(regs[0]) is not int or not 0 <= regs[0] <= 65535):
raise ValueError("register_shape")
raw = regs[0]
if raw == point["invalid"]:
raise ValueError("invalid_value")
signed = raw if raw < 32768 else raw - 65536
result.update(value=signed * point["scale"], quality="good",
error=None, sampled_at=datetime.now(timezone.utc).isoformat())
return result
except DeviceError as exc:
result["error"] = "modbus_%02X" % exc.code
retry = exc.code == 6
except TimeoutError:
result["error"] = "timeout"
retry = True
except ValueError as exc:
result["error"] = str(exc)
if not retry or attempt == 3:
break
delay = 0.05 * attempt
if deadline - now() <= delay:
result["error"] = "budget_exhausted"
break
pause(delay)
return result
class Sim:
def __init__(self, events):
self.events, self.t, self.calls = iter(events), 0.0, 0
def now(self):
return self.t
def pause(self, delay):
self.t += delay
def read(self, point, timeout):
self.calls += 1
event = next(self.events)
if isinstance(event, TimeoutError):
self.t += timeout
if isinstance(event, Exception):
raise event
return event
def run(events, budget=1.0):
sim = Sim(events)
result = collect(sim.read, now=sim.now, pause=sim.pause, budget=budget)
assert result["attempts"] == sim.calls
return result
r = run([[253]])
assert r["quality"] == "good" and abs(r["value"] - 25.3) < 1e-9
assert r["sampled_at"] and r["attempts"] == 1
assert abs(run([[65526]])["value"] + 1.0) < 1e-9
r = run([DeviceError(6), [253]])
assert r["quality"] == "good" and r["attempts"] == 2
r = run([TimeoutError(), [253]])
assert r["quality"] == "good" and r["attempts"] == 2
for code in (1, 2, 3, 4):
r = run([DeviceError(code)])
assert r["attempts"] == 1 and r["error"] == "modbus_%02X" % code
for event in (DeviceError(6), TimeoutError()):
r = run([event, event, event])
assert r["attempts"] == 3 and r["value"] is None
assert r["quality"] == "bad" and r["sampled_at"] is None
assert run([[]])["error"] == "register_shape"
assert run([[65535]])["error"] == "invalid_value"
r = run([TimeoutError()], budget=0.1)
assert r["attempts"] == 1 and r["error"] == "budget_exhausted"
print("PASS: normal signed busy timeout limits decode invalid budget")
输出中 attempted_at 是本轮开始时间，sampled_at 仅在成功解码时记录软件接收时间，不冒充设备测量时间。失败保持 value 为 None、quality 为 bad，error 与 attempts 解释失败位置；历史值若需展示，应由独立缓存携带原采集时间，不能回填本次结果。测试用可推进的模拟时钟覆盖预算耗尽，不等待真实超时，也不连接任何设备。
项目实践：用教学模拟走通验收步骤
这里用一次教学模拟演练串起验收步骤，当前没有可核验的真实项目材料。测试在本机 Python 标准库环境执行，复用上节采集函数，以预设寄存器响应、异常和可推进时钟替代设备与等待；串口连接、报文收发及设备寄存器读取均未实测。
先核对单点映射：从站为 1，功能码为 3，协议地址偏移为 0，读取一个寄存器，按有符号整数乘以 0.1 解码，单位为摄氏度。注入原始值 253，实跑结果为 25.3，quality 为 good，attempts 为 1。这只证明教学映射与解码逻辑一致，真实地址、量纲仍需逐项对照设备手册。
再注入异常：先返回忙碌码 06、再返回 253，第二次尝试成功；返回非法地址码 02 时，只调用一次便结束，error 为 modbus_02。两者的区别说明配置错误应先修映射，暂时忙碌才进入有限重试。
最后在同一个模拟读取器中连续注入三次超时，再准备一条正常响应。总预算设为一秒，首轮恰好尝试三次后停止，value 为 None、quality 为 bad、sampled_at 为空；随后重新调用采集函数，下一周期一次成功，得到 25.3，两轮合计四次读取。恢复来自新响应，不是旧值回填。这些断言已实际执行通过，但不能据此推断真实总线的恢复时间或长期稳定性。进入现场联调前，还应把接线、串口参数和设备手册版本列入验收记录，逐点核对原始寄存器与解码结果。
价值总结：判断标准与复用边界
判断脚本是否具备联调基础，可以逐项核对以下记录：
- 映射可追溯：每个点位能对应到手册条目与映射版本，地址含义清楚。
- 解码可复现：给定原始寄存器，能按类型、字序、缩放和单位复算结果，无效值单独处理。
- 错误可区分：异常码、超时和解码失败各有记录，配置错误不会进入无差别重试。
- 重试可终止：尝试次数与总预算都有上限，失败点位结束后能继续处理后续任务。
- 结果可信用：失败不会冒充零值或成功；展示历史值时，保留原采集时间并标记陈旧。
复用时可以沿用调度、错误分类和结果结构，设备映射必须重新核实。更换型号或手册版本后，寄存器布局、缩放、字序和无效值规则都要复查，不能只改从站地址便投入运行。
本文模拟验证覆盖的是采集逻辑。接入真实设备后，还须逐点比对原始响应与解码值，验证断连、恢复及整轮调度耗时，再确定采集周期。效率和稳定性结论应来自这些实测记录；目前不作收益或长期运行承诺。