“数采仪上显示连接成功，平台那边一条数据都没有。”这是最近一个月被问得最多的一句话，来自华东一家印染厂的运维工程师。先把结论放在前面：连接成功只代表 TCP 链路通了，不代表报文被平台收下。在数采仪上传异常处理里，八成问题集中在两处——设备里的 MN 号（设备唯一标识）和平台登记的排口对不上，平台收到了报文却归不到排口，界面上就是“无数据”；或者设备时钟跑快，数据时间戳落到“未来”，被平台当成无效数据丢掉。真正硬件损坏的比例很低。
先分清四层，别一上来就换设备
HJ 212-2017 这套报文从现场机到平台，要过四道关，任何一道不通，最后的表现都是同一句话：平台没数据。分层不是为了显得专业，是为了让排查有先后。
协议层
- 命令码用错：2021 是实时数据上传，2031 是历史数据补发，3012 是响应上位机历史数据提取。2000–2999 这一段是现场机主动上报，1000–1999 是上位机下发的交互命令，3000–3999 是上位机提取现场机数据。补发场景错用 2021，平台很可能按实时数据去重丢掉。
- MN 号、ST 系统编码、PW 访问密码，三个字段任何一个和平台登记的不一致，报文能到，但落不了库。
- 数据段长度字段算错，或者 CRC 校验范围算错——正确范围是从 QN 开始到结尾的 && 结束，不含前面的 ## 和后面的四位 CRC。算错了，平台直接判报文非法。
- CP 段里 DataTime 的时间格式不对，或者污染物编码（比如 01101 这类）平台没有对应的因子。
- Flag 标志位没设对，平台不回应答，设备只能一直重发。
网络层
- 4G 卡没开专网 APN，或者 APN 对了但没加白名单。
- 防火墙只放行了平台 IP，没放行端口；平台换过 IP，设备里还是老地址。
- NAT 会话老化，TCP 状态看着还连着，实际早断了，得靠心跳保活。
设备层
- 数采仪和仪表之间的 RS485/Modbus 链路断了，数采仪自己就没采到值，传上去是空值。
- 设备时钟比平台快几分钟，数据时间戳超前。
- 改完 MN 号没重启，旧会话还在用旧参数跑。
平台层
- 排口没绑定设备，或者设备在平台上处于未激活状态。
- 平台按时间窗去重，补发数据和实时数据时间重叠，后来的被丢掉。
- 平台侧协议版本配置和现场不一致，比如平台按 212-2017 解析，设备发的是更早的格式。
排查顺序本身就是知识
现场最常见的错误是从网线、卡、天线开始查，一圈下来两小时过去了，问题还在原地。数采仪上传异常处理的正确顺序是：先看设备日志有没有收到平台的应答，再核对参数，最后才抓包。
为什么先看应答？因为应答就是平台给的回执。设备发出 2021，平台正常处理会回 9012 数据应答；补发 2031 会回 3020；上位机下发 1013 心跳，设备回 2013。日志里只要能看到这些下行报文，说明链路、IP、端口、校验全是通的，问题一定在参数或者平台关联上，这时候再去抓包纯属浪费。
反过来，如果日志里只有发出去的报文、没有收到的应答，才需要往下走：先确认 TCP 是不是真的连着，再抓包看 2021 有没有出现在对端，最后才怀疑 CRC 和长度字段。
参数核对放第二位，是因为它最快。MN、ST、PW、平台 IP 和端口，四个值在设备界面和平台后台各看一眼，五分钟能对完，比抓包省事得多。抓包放最后，是因为它成本最高，需要镜像口或者现场调试电脑，不到必要不折腾。
每一步的判断标准和处置动作
| 现象 | 判断 | 动作 |
|---|---|---|
| 现场机日志有 9012 或 3020 应答，平台查不到数据 | 报文已被平台接收，问题在参数或平台关联 | 核对 MN、ST 与排口编码，检查设备是否已在平台绑定并激活 |
| 日志只有上行没有下行，TCP 显示已连接 | 平台判报文非法直接丢弃，或中间设备拦截 | 抓包看对端是否收到 2021，核对数据段长度与 CRC 校验范围 |
| 抓包看到 2021，平台回 9011 但带错误标志 | 平台识别到请求，但参数不合法 | 看平台返回的错误描述，多半是 MN 未登记或因子编码不存在 |
| 数据能到平台，时间戳比平台时间靠后 | 设备时钟快，数据被判成未来时间 | 用 1011 提取平台时间、1012 下发校时，并开启定时校时 |
| 心跳 1013/2013 正常，2021 始终没有应答 | 长报文校验错，短报文没暴露出来 | 单独构造一条带完整 CP 段的报文测试，重点查 && 边界和长度字段 |
| 断网恢复后历史数据补不上去 | 补传没开，或者补发命令码用了 2021 | 检查补传开关，确认使用 2031 上传，或按上位机 3011 提取后回 3012 |
| 平台有数据，但因子值是空的 | 数采仪和仪表之间的采集链路断了 | 查 RS485 接线、Modbus 从站地址、寄存器地址和量程设置 |
三个最容易误判的坑
第一个坑，把“连接成功”当成“数据已通”。设备界面上那个连接状态，反映的只是 TCP 三次握手的结果。平台收下报文还要过协议解析、MN 校验、排口匹配三道关，任何一关不过，设备照样显示连接成功。
第二个坑，把“心跳正常”当成“报文没问题”。心跳 1013/2013 是很短的报文，CP 段基本为空，CRC 和长度字段出错的概率天然低。数据报文长得多，带完整 CP 段和多个因子值，长度字段算错一位、CRC 范围多算一个字符，只有长报文才会暴露。所以心跳正常、数据不传，是很典型的一组现象。
第三个坑，只改设备端，不管平台端登记。MN 和 ST 是双向的，设备里改了，平台后台没同步，报文到了也对不上排口。更麻烦的是部分设备改完参数需要重新建立会话，不重启就还是拿旧参数在发，改了等于没改。
FAQ
“数采仪显示连接成功，平台就是没数据，是不是设备坏了？”
先别急着换设备。看设备日志里有没有 9012 或 3020 这类下行应答，有应答说明设备在正常发、平台在正常回，问题出在参数或平台关联上；一条下行都没有，再去查网络和报文格式。
“心跳包一直正常，数据就是传不上去，到底先查哪一头？”
先查设备端的报文参数，重点看数据段长度字段和 CRC 校验范围。心跳正常只能证明短报文通，长报文出问题太常见了。
“断网那几天的数据还能补上去吗？”
能，前提是设备本地存储开着、补传功能开着。补发走 2031，或者等上位机下发 3011 提取历史数据。补发上去之后如果平台还是查不到，看看是不是被平台的时间窗去重规则挡掉了。
“我就改了个 MN 号，怎么反而全不传了？”
改完 MN 要确认两件事：平台后台的排口绑定有没有同步改；设备有没有重启或者重新登录。旧会话还挂着的时候，发的还是老 MN，平台自然不认。