读码器读得出来屏幕上也有码但 MES 里就是查不到这件产品。这是产线数字化改造里常见的一类问题也容易被误判现场工程师往往一头扎进读码器的参数里调调了两天发现读码器一点问题没有卡的是数据出不去或者出去了但对方不认。接不上不是一个问题是三层不同的问题判别方法和修法都不一样。先分清卡在哪一层再动手。一、先把「接不上」拆成三层层次典型现象一眼确认修的方向通信层传不到MES 里一条记录都没有读码器本地记录正常通信指示灯状态抓包看不到数据发出PLC 对应寄存器无变化协议、网络、接口配置数据层传了不对有记录但条数对不上、同一件重复记、码被截断拿一段时间的过件数去和 MES 记录数对账触发、去重、切帧、缓存重发追溯层有记录查不出记录条数是对的按序列号反查查不到工序或参数随机抽三个序列号反查能否定位到工位和时间绑定关系与字段设计判别只用一个动作先数记录条数。一条都没有是通信层有但对不上是数据层对得上但查不出来是追溯层。这三层的修法完全不重叠混着修是费时间的走法。有一个反直觉的地方要说清楚三层里贵的不是通信层是追溯层。通信层的问题多数能在半天内定位追溯层的问题往往要改数据模型属于上线前不定、上线后难改的那一类。二、通信层读码器读到了MES 没收到通信层先要理清一件事读码器在架构里的位置。多数产线并不是读码器直接连 MES而是读码器把结果交给 PLCPLC 再往上给 MES。读码器直连 MES 是并行的一条路走不走取决于 MES 侧愿不愿意开设备接入。通信方式所处层位时延量级什么时候用Modbus TCP现场到控制毫秒到秒级轮询设备少、点数少、只要结果不要过程实现成本低适合做设备侧接口Modbus RTURS232/485现场到控制毫秒到几十毫秒老设备、串口 PLC接线简单但点对点线长了不稳Profinet现场到控制实时通道 1 到 10 毫秒等时模式可更低产线 PLC 正好是该协议的主流生态、要求节拍确定性需设备描述文件与设备命名配置门槛高于 ModbusEtherNet/IP现场到控制毫秒级产线以另一套主流 PLC 体系为主时对应选它裸 TCP Socket控制到上位取决于网络与实现双方约定自定义报文灵活但重连与心跳要自己做OPC UA控制到 MES 与云端毫秒到几十毫秒跨厂商、要带语义、要安全它是应用层协议不是现场总线不用于控制回路这张表里容易被误用的是一行。OPC UA 不是「更高级的现场总线」它是跑在 TCP/IP 之上的应用层协议作用是让数据带着语义和身份往上走。把它放到读码器与 PLC 之间去做触发和实时控制是放错了层。合理的分工是现场层走 Profinet 或 Modbus控制层往上用 OPC UA 交给 MES。协议定了还有五件事要一一对齐这五件事没对齐协议对了也解析不出来编码ASCII 还是十六进制。同一串码两种编码发出去对方收到的字节完全不同。结束符回车、换行还是两者都要。没有约定结束符接收端只能按超时切帧超时设长了会粘包设短了会截断。字节序多字节数据是大端还是小端。码本身不受影响但同一报文里的长度、计数字段会。前后缀要不要加站号、要不要加状态位。加了对方不认不加事后分不清数据来自哪台设备。码内容本身大小写是否统一、首尾空格是否去掉、有没有不可见字符。这一条琐碎也容易在联调时耗掉半天。现场排查通信层按灯、包、格式三步走。先看通信状态确认链路在再抓一次包或读一次对方寄存器确认数据真的发出去了第三步核对上面五件事确认对方能解析。跳过抓包直接改配置是常见的无效劳动。还有一条现场经验值得单独提TCP 客户端模式下断线后不一定自动重连。产线网络抖动一次读码器可能还认为自己连着实际上一整天没再发出去一条。心跳检测和重连间隔要在联调阶段就配好并测过不能等上线后靠人发现。三、数据层记录有了账对不上数据层的症状是记录条数不对。四种病成因和修法都不同。症状现场表现常见成因修法缺记录MES 条数少于实际过件数上传失败没有重发断网期间没有本地缓存接收和上传耦合在一起网络慢时把接收也堵住上传失败进重发队列断网落本地缓存接收与上传解耦重复记录同一件被记了两次以上光电信号抖动重复触发PLC 没做工件锁存没有按时间窗去重触发信号加锁存同工位按时间窗去重乱序记录顺序和实际过件顺序不一致多工位并发上报报文里没有序号报文加序号与时间戳接收端按序号或时间重排截断或乱码码缺尾、出现多余字符没约定结束符导致切帧错误条码超长被分段串口参数波特率、数据位、停止位、校验位不一致约定结束符与最大长度串口参数逐项核对长码走分段传输四种病里缺记录和重复记录容易被当成读码问题去查实际多数不是。读码器本地有记录、MES 没有是上传环节的事同一件读了两三次是触发和锁存的事。判别的入口很明确把读码器本地日志和 MES 记录按时间并排比差在哪一步一眼能看出来。一个架构上的原则值得写进设计文档接收和上传要解耦。收码的线程只管把字节流按结束符切干净、放进本地队列上传是另一个线程从队列里取、批量发、失败回队。把 HTTP 请求写在收码回调里网络一慢收码就跟着堵堵到触发信号都接不住丢的是整段产线的数据。四、追溯层记录是全的反查还是查不出来这一层容易被忽略因为它不出错只是没用。记录条数对得上随机抽一个序列号去查查不到它在哪个工位、当时用的什么参数、属于哪个批次。这就是追溯不成立。追溯要成立得有三个绑定关系缺一个就断链。绑定缺了会怎样怎么补码与对象一个托盘上多件、一箱多件时只知道读了几个码不知道谁是谁返修后换的新码和原码对不上定父子关系托盘码或箱码对上件码返修件单独建台账记录新旧码对应码与工序工位只知道读到了码不知道是哪道工序读的出问题时定位不到责任工位报文里带站号或工位号每个读码点固定一个唯一站号不共用码与时间批次跨天对账对不上召回时圈不出受影响范围时间戳统一来源以服务器或 MES 为准不用设备本地时钟批次号随工单下发并随码上传三个绑定里站号共用是较隐蔽的一种。一条线上装了几台读码器如果都用一个默认站号事后看数据完全分不清是哪台读的来源信息等于没有。这件事在安装阶段按工位编号分配、写进台账成本几乎为零事后补要停产排查。再往前一步是追溯粒度这个在上线前就得定定完才好定字段。批次级追溯是每个批次一个标识记录这批的原料、设备、人员和参数。成本低圈定范围时是一整批。单件级追溯是每件一个唯一码记录这一件的完整履历。成本高但问题件能精确定位到个体。混合做法在实际项目里常见关键件按单件级管非关键件按批次级管两者通过绑定关系连起来。不同行业的合规要求不一样选粒度不能凭感觉汽车行业相关体系一般要求批次级涉及安全的件要求到单件医药行业要求单件级食品行业常见的要求是向前一步、向后一步。客户审核时看的是能不能拿一个成品码反查到它的全部履历只做到批次级的系统在这类审核里过不去。方向上有两条路要都能走通。正向是从某个批次或原料出发查它流到了哪些成品召回时用反向是从一个成品码出发反查它的工序、参数和物料批次客诉分析时用。两条路的数据基础是同一个码与物料批次的绑定关系在投料或上料那一刻就建立起来。这个绑定漏了反向追溯就断在源头。五、落地顺序从追溯粒度往回定不要从设备往前推这一类项目常见的返工是先买了设备、装好了、再去问 MES 要什么格式结果发现字段不够、站号没规划、时间戳来源不一致回头改。顺序定什么定了之后的产出1追溯粒度批次级、单件级还是混合影响后续全部字段设计必须先定2记录字段每个码要带哪些信息字段清单含站号、时间戳、批次、结果状态3上传时机逐件实时、按批还是失败缓存后补传决定要不要本地队列与重发机制4协议与网络走 PLC 中转还是直连选哪种协议网络规划、IP 与站号分配表5验收试验怎么证明它真的通了验收清单见第六节这个顺序倒过来做前面省的时间后面要成倍还回去。字段这一层尤其如此MES 侧的接口表和数据库字段改一次要动开发比读码器改配置贵得多。六、验收五项试验别等上线才发现联调做完不等于通了。五件事各做一遍通过了才算站住。试验做法通过标准断网试验拔掉网线让产线正常过一批件再插回断网期间数据不丢恢复后自动补传条数与过件数一致重复触发试验同一件在工位前停留、反复遮挡触发只记一条不产生重复记录重码试验用同一个码连续过件数据能上去且业务上能区分返修件与异常件跨天对账连续跑一个班次或一天比对过件数与 MES 记录数数量一致时间顺序一致无截断反查试验随机抽三个序列号从 MES 反查工位、时间、参数三条都能查到且与实际生产记录相符这五项里断网试验和反查试验容易被跳过也容易在上线后暴雷。断网试验验的是缓存与重发反查试验验的是绑定关系这两个恰好是事后难补的。读码器读到码只是起点。数据能从设备走到 MES才算通信通了条数对得上、不重不漏不乱才算数据对了拿一个码反查出它的履历才算追溯成立。三层各有各的判据混着查只会越查越乱。按数条数、对账、反查的顺序走多数问题在半小时内能落到具体一层。