在实际产线上跑了几年RFID项目我越来越觉得“设备联网”这件事本身比选哪款RFID硬件更考验功底。前阵子做一台工装防错机客户指定要CK-LR08-E00这款工业级RFID读写器控制器用的是汇川PLC通讯方式明确要求走以太网TCP/IP自由协议。这个组合听起来不复杂真正动手时会发现细节非常密集自由协议到底怎么定义报文、PLC侧该用哪个功能块去收发、调试时连不上怎么办每个环节都有坑。这篇文章把整套联机方案和调试过程完整拆开从报文格式到PLC程序实现适合正在做RFID与PLC对接的电气工程师、自动化集成商以及想搞懂自由协议通讯底层的朋友。1. 方案价值与总体设计思路1.1 为什么选“以太网自由协议”而不选Modbus TCP或Profinet先说明一个概念工业RFID读写器的对外接口通常有RS232、RS485、以太网三类以太网里又分Modbus TCP、Profinet、EtherNet/IP等“标准协议”以及本文要说的“自由协议”。自由协议本质上就是TCP/IP Socket通讯——PLC作为TCP客户端或服务器直接按读写器厂商规定的报文格式收发原始字节流中间不经过任何协议转换。有人会问Modbus TCP不是更通用吗这里有个很现实的选型逻辑。Modbus TCP虽然上手快但它是一种“寄存器映射”通讯方式读写器必须把读到的标签数据映射到特定寄存器区PLC侧再按Modbus地址去读取。麻烦在于RFID的返回数据往往是变长的比如EPC有6字节、12字节、甚至更多Modbus寄存器地址一旦规划好数据长度变了就不好处理。而自由协议最大的优势就是“透明”——读写器返回什么字节PLC就收到什么字节数据区长度在报文里直接标出来解析起来非常直观。我做过的项目里选择自由协议还有几个实际考量一是读写器的报文功能更完整像盘点标签、读取TID、写用户区数据这些操作自由协议里都是一个命令搞定二是调试过程更容易用Wireshark或者TCP调试工具就能直接看到原始报文问题定位比黑盒的Modbus映射快得多三是和MES、上位机对接时自由协议的报文格式和PC端SDK是一致的PLC程序写好了上位机接手也方便。另外提一句Modbus RTU。很多旧设备还在用RS485走Modbus RTU但RTU通讯里有个经典问题——高低字节顺序。因为Modbus寄存器是16位的而RFID返回的EPC/TID是字节流一组16位数据要在两个寄存器里存谁高谁低如果不统一触摸屏上显示的字符串就会乱。用TCP自由协议时就没有这个高低位转换问题当然前提是你要在PLC内部解析时报文字节序时留个心眼这一点在后面报文解析部分会细说。1.2 CK-LR08-E00 的实际选型理解CK-LR08-E00在CK-LR08系列里属于带以太网口的高配版本工作频率是超高频段UHF860MHz到960MHz支持EPC Gen2和ISO18000-6C标准。超高频RFID的核心优势是识别距离远、速度快配合合适的天线和标签读距能做到两三米甚至更远适合用在产线托盘识别、工装防错、AGV站点定位这类场景。这里做一个关键表格方便大家理解不同接口版本的选择差异型号版本通讯接口适用场景注意事项CK-LR08-E00以太网TCP/IP支持自由协议和Modbus TCP需要高速率、大数据量、多设备联网需要PLC或上位机具备以太网接口CK-LR08-S00示例RS232/RS485串口距离近、点数少、老设备改造串口线缆长度受限485需要终端电阻CK-LR08-E00IO版示例以太网IO输入输出有传感器/执行器联动的场景IO点可作为读卡触发信号或结果输出我为什么建议自动化项目优先考虑以太网版因为PLC和读写器之间只拉一根网线供电另外走24V布线比串口干净得多。而且现在汇川的中大型PLC基本都带以太网口H5U、AM系列都支持Socket通讯硬件上不需要额外加通讯模块。现场维护也方便网线坏了换一根就行不像RS485还要检查终端电阻和极性。当然如果现场PLC确实没有以太网口或者距离超过100米只能走光纤那只能选串口方案这是另一种故事了。工业级这个词也不是随便标的。CK-LR08-E00外壳防护等级在IP54以上能扛0到60度的工作温度电磁兼容性过了工业标准。我见过有人拿商用读写器在产线边上用三个月坏两回最后换工业级设备才算安稳。金属粉尘、电机启停的干扰、夏天车间四十多度的高温这些都是很现实的环境考验。选工业级读写器后面能少很多麻烦。再补充一个点这个读写器除了支持TCP/IP自由协议通常还附带IO输入输出可以接光电传感器做读卡触发也可以输出一个OK/NG信号给PLC这在自动化产线联动时非常有用。实际项目中IO触发比PLC通过网口发“开始读卡”命令更可靠因为硬件信号没有网络延迟问题。2. 通讯协议解析与报文翻译2.1 通讯模型谁主动谁被动开始写PLC程序前先把通讯模型搞清楚。CK-LR08-E00作为服务器模式时PLC作为客户端主动建立TCP连接连接建立后PLC发送命令帧读写器返回应答帧。这个“一问一答”的机制是整个通讯的底层逻辑读写器很少主动上报数据除非你开了“自动读取/主动上传”模式——但工业项目里我通常不建议开原因很简单PLC需要对读卡操作有绝对的控制权什么时候读、读哪些区、要不要重试都应该由PLC的流程逻辑决定而不是靠读写器自己往外面吐数据。为什么推荐读写器做服务器ServerPLC做客户端Client因为PLC做客户端时程序可以在上电初始化时主动去connect如果连接失败可以定时重连逻辑非常好写。反过来如果让PLC做Server读写器主动连PLC你就得在PLC上额外配置监听端口、处理多客户端连接这对大多数PLC来说是很别扭的事。实际调试中我用过让读写器做TCP服务器的模式稳定跑了几个月断线重连机制做在PLC里每两秒检测一次Socket状态断开了就自动重连很好用。2.2 帧结构从报文头到校验码自由协议最核心的功夫就在于“组帧”和“拆帧”。虽然不同厂商的帧格式有差异但结构基本固定。CK-LR08-E00的命令帧一般包含以下部分字节位置内容说明帧头0xBB固定起始字节命令字如0x01表示读卡/写卡/盘点等数据长度2字节从命令字后到校验前的数据区长度数据区可变具体参数不同命令各不相同校验码1字节或2字节常见为CRC16或XOR校验和举个例子单次读取标签EPC假设天线1不需要密码发送命令帧 BB 01 00 03 00 01 00 46 拆解 0xBB 帧头 0x01 命令字读取EPC 0x00 0x03 数据长度3字节 0x00 天线号天线1 0x01 读取标签的EPC区数据区开始共2字节 0x00 保留字段 0x46 校验码XOR或CRC计算结果这里示意读卡器返回帧可能是这样示意结构返回帧 BB 01 00 0E 00 01 00 00 30 31 32 33 34 35 36 37 38 39 3F 拆解 0xBB 帧头 0x01 命令字应答 0x00 0x0E 数据长度14字节 0x00 状态0表示成功 0x01 天线号 0x00 标签数量1个 0x00 保留 0x30~0x39 标签EPC数据ASCII码“0123456789” 0x3F 校验码注意实际项目中不要仅仅凭记忆里的帧结构去写PLC代码一定要以随机附带的通讯协议手册为准。很多设备厂家会更新协议比如增加新命令、调整长度字段的起始位置差一个字节整个帧就解析错了。写卡就复杂一些需要对数据区做更多参数拼接。比如把“12345678”这8个ASCII字符写入标签EPC区命令帧里的数据区会包含写卡密码通常4字节、目标区标志、写入地址、写入数据长度和数据本身。如果需要防改写EPC区默认是锁定状态必须先发送解锁命令再写否则写操作会直接返回失败——这个细节我吃过亏后面专门讲。2.3 报文字节序一个绕不开的细节字节序问题在工业通讯里特别容易踩坑。TCP/IP协议是网络字节序即大端模式高字节在前、低字节在后。多数RFID读写器的协议手册里数据区都是按大端排列的也就是说一个16位的数据0x1234在报文里显示为12 34而不是34 12。但注意汇川PLC尤其是H5U、AM系列内部做数据处理时默认可能是小端模式或按字Word为单位存储。也就是说你在PLC里把一个数组当成字数组去访问时高字节和低字节的排布会和你从报文里看到的不一致这时就需要手动做高低字节交换。最常见的情况是标签里存的是一个“0123456789”的ASCII字符串结果你在触摸屏上看到的是“1032547698”这就是字节序反了。解决思路有两个一是在PLC程序里写一个字节交换函数把接收缓冲区里的每两个字节调换后再拼接二是在读写器配置里看看有没有“输出格式”设置有些读写器的参数页面可以直接选择“字节顺序”改一下就能避免在PLC里处理。我个人的习惯是优先在PLC里做处理因为你无法保证现场其他人改动了读写器配置到时候程序解析会乱。3. 硬件连接与网络参数配置3.1 硬件接线看起来简单细节都在暗处CK-LR08-E00的物理接线有三路24V直流电源、以太网线、IO信号线如果有外接传感器。很多第一次用的工程师会忽略电源的质量直接用PLC的开关电源供电。读写器在发射功率较大时瞬间电流可能到1A以上如果PLC电源本身已经带了伺服、传感器容易造成电压跌落读写器会随机重启或者通讯闪断。我建议给读写器配一个独立的24V 2A开关电源贵不了几十块钱稳定性提升非常明显。以太网连接有两种方式一种是读写器直接网线连PLC的以太网口这种适用于只有一台读写器的场景IP地址规划简单另一种是接入工业交换机适用于多台读写器或PLC和上位机同时需要访问的情况。直连时建议用超五类及以上屏蔽网线长度尽量控制在50米内。工业现场有电机变频器网线抗干扰能力直接决定通讯稳定性。IO信号线的作用要根据应用来定义。最常见的用法是光电传感器接到读写器的IO输入标签到位后给一个硬信号触发读卡PLC只需要等待读写器返回结果也可以由PLC输出一个指令触发读卡但这种方式受网络延迟影响重复性不如硬件触发。现场如果传感器信号抖动严重通常要在读写器配置里加一个小延时滤波。3.2 IP地址规划第一次调试最痛苦的就是IP对不上CK-LR08-E00出厂一般有一个默认IP地址通常是192.168.1.100或者类似网段。要改IP地址一般有两种途径一是用网线连接读写器后通过浏览器访问设备内置配置页面二是用厂家提供的调试工具软件扫描后修改。这里有一个实操建议先不要急着把PLC网口地址改成和读写器同一网段而是先把电脑网卡地址改成同网段用浏览器登录读写器管理页面把IP改到PLC所在的网段里去。否则一旦IP冲突你又忘了登录密码恢复出厂设置会非常麻烦。IP地址规划有个必须遵守的原则PLC和读写器必须在同一个网段子网掩码一致且IP地址不能和网络中其他设备冲突。汇川H5U系列PLC的以太网口默认IP一般是192.168.1.88视版本而定这时候读写器IP最好设成192.168.1.100、192.168.1.101这样预留好的固定地址不参与DHCP自动分配。生产网络里如果还有上位机、MES服务器干脆做一个IP分配表设备多了以后才知道这个规划多重要。设置好IP后的第一个测试动作是ping。电脑ping读写器通不通PLC再ping读写器通不通。有时候是在同一网段还是ping不通很可能是防火墙拦截了ICMP报文这时候可以换一个TCP调试工具直接连60000端口试试比单纯ping更能判断问题。端口方面CK-LR08-E00的TCP服务端口是固定的可能是60000也可能是30000以手册为准。3.3 用TCP调试工具先把“语言”调试通我不建议一上来就写PLC程序先用电脑上的TCP调试工具把报文调通这是整个项目效率最高的环节。你可以用SocketTool、网络调试助手或者串口助手如果支持TCP这类工具建立一个TCP客户端连接读写器的服务端口然后手动发送那几条核心命令比如读EPC、读TID、写EPC。观察返回帧是否和手册一致。这一步做完你基本就掌握了这套设备“说的话”。同时建议把调好的报文复制粘贴到一个txt文件里标注好每条命令的作用这个文件后面写PLC程序时就是最可靠的注释文档。我习惯把“初始化/读EPC/写EPC/读用户区”四条命令的报文样本固定下来后面的PLC程序全部围绕这四类报文来开发。注意一点TCP工具做测试时打开连接的瞬间读写器可能会收到TCP握手之外的空数据有些读写器会返回一个版本号提示有些则直接忽略。如果发现TCP调试工具一连接就收到一串未知数据先别慌可以把它当成读写器上电或者连接成功时的版本信息。4. 汇川PLC侧程序实现4.1 先确认你的汇川PLC支持哪些自由协议能力汇川PLC系列很多不是所有型号都支持TCP Socket自由协议。H5U系列、AM系列是基于Codesys平台的可以使用Socket通讯功能块H3U、H1U系列用的是AutoShop平台部分型号只有串口自由协议没有以太网自由协议或者要通过扩展模块才能实现这一点选型时就要确认好。编程软件也有差异H3U用AutoShopH5U用InoProShop基于CodesysAM系列用InoProShop或InoProShopCodesys内核。如果用的是H5U你的编程环境里可以直接调用内置的TCP客户端功能块比如TcpClientConnect、TcpClientSend、TcpClientReceive也可以直接用更强的Socket库在程序里自己管理连接状态和收发缓冲区。这些功能块本质就是对Berkeley Socket的封装只是把底层细节暴露成梯形图或ST可以调用的形式。提一下“汇川plc下载编程软件”这个问题AutoShop和InoProShop都可以在汇川官网找到下载页面但下载前最好确认软件版本和PLC固件版本匹配不然在线连接时可能提示固件版本不匹配虽然可以强制更新固件但不建议在产线上随意升级。4.2 PLC建立TCP连接初始化与断线重连以汇川H5UInoProShop为例一个最基础的自由协议通讯程序需要三步建立连接、发送命令、接收解析。可以用ST语言或梯形图写我习惯用ST包一个功能块方便以后复用。先定义连接参数VAR bConnect : BOOL; //连接成功标志 TcpClient_0 : TcpClient; //TCP客户端功能块 sServerIP : STRING : 192.168.1.100; uiServerPort : UINT : 60000; xExecuteConnect : BOOL; //触发连接 END_VAR初始化时xExecuteConnect给一个上升沿触发TcpClient功能块内部有连接状态机你只需要监控它的输出引脚。连接成功后bConnect会变为TRUE。断线重连一定要做。实际现场我见过PLC上电顺序不同导致读写器还没启动PLC先连接失败的情况。正确做法是在PLC程序里加一个计时器每2秒检测一次连接状态如果断开就自动重连。有些汇川PLC的TcpClient功能块本身支持自动重连参数直接使能即可如果没这个参数就在外围逻辑里写重连触发。如果不做重连设备运行中读写器断电重启一次PLC就要重启才能恢复这是不能接受的。这一点强烈建议重点检查。4.3 组帧在PLC里拼出一个合法报文组帧看起来只是把固定字节放到数组里其实有几个容易出问题的点一是数组长度和帧头的位置二是长度字段的计算三是校验码的算法。我用ST写一个简单的XOR校验函数因为很多读写器支持最简单的XOR校验和FUNCTION F_XorCheck : BYTE VAR_INPUT pData : POINTER TO BYTE; uiLen : UINT; END_VAR VAR i : UINT; tmp : BYTE; END_VAR tmp : 0; FOR i : 0 TO uiLen - 1 DO tmp : tmp XOR pData[i]; END_FOR F_XorCheck : tmp;如果设备手册要求CRC16而不是XOR建议先在电脑上用Python或者工具算好一组样例报文把CRC结果和手册对上再在PLC里写CRC函数。CRC16的实现本身不复杂但表驱动在PLC里会占用很多存储空间可以用移位法的循环计算实时性完全够。组好帧后调用发送功能块abySendData[0] : 16#BB; abySendData[1] : 16#01; abySendData[2] : 16#00; abySendData[3] : 16#03; abySendData[4] : 16#00; abySendData[5] : 16#01; abySendData[6] : 16#00; abySendData[7] : F_XorCheck(ADR(abySendData), 7); TcpClient_0.ExecuteSend(ADR(abySendData), 8);记得发送前把字节数计算准确多一帧少一帧都会导致读写器不应答。4.4 收包与解析状态机比“扫描周期轮询”更可靠接收数据是自由协议通讯里最考验编程功力的地方。很多人直接在PLC扫描周期里调用“接收”功能块每次收几个字节然后拼在一起处理这种做法在数据量大时会出问题因为TCP是流式传输一次发送的数据可能分多个包到达也可能多个包黏在一起到达。更稳妥的方式是建立“接收状态机”。逻辑是这样的PLC在后台循环接收字节存到缓冲区然后按帧头0xBB、长度字段、完整帧长度来切包。只有缓冲区的字节数达到一帧完整长度后才启动解析。如果收到的第一个字节不是0xBB就继续往后找直到找到帧头。这个思路在Modbus RTU和自由协议里完全通用。ST代码思路示例WHILE bReceiveValid DO //从TcpClient接收缓冲区读1字节 bReceived : TcpClient_0.ReceiveByte(byByte); IF NOT bReceived THEN EXIT; END_IF; //状态机 CASE byState OF 0: //等待帧头 IF byByte 16#BB THEN abyBuffer[0] : byByte; byState : 1; iIndex : 1; END_IF; 1: //接收长度字段和数据 abyBuffer[iIndex] : byByte; iIndex : iIndex 1; IF iIndex 4 THEN //长度字段在abyte[2]和abyte[3]得到完整帧长度 uiFullLen : abyBuffer[2] * 256 abyBuffer[3] 4; END_IF; IF iIndex uiFullLen THEN //完整帧已到 bFrameReady : TRUE; byState : 0; END_IF; END_CASE; END_WHILE;帧准备好后再按命令字去解析。以读EPC为例返回帧的命令字是0x01数据区里偏移量的位置可能随协议版本变化解析时注意状态字和天线号、标签数量这些字段通常都有相对固定的偏移。如果标签数量为0表示没有读到标签这时候PLC逻辑要跳转到重试分支。4.5 数据上抛字符串转换是基本功RFID读到的EPC本质是十六进制字节流但触摸屏和MES通常要显示的是可读字符串。比如一个EPC可能是8个字节E2 00 11 22 33 44 55 66触摸屏上应该显示“E200112233445566”这样一个16个字符的ASCII字符串。这个过程要用PLC标准库里的“字节转十六进制字符串”函数没有的话自己写一个FUNCTION F_ByteToHexStr : STRING(32) VAR_INPUT byVal : BYTE; END_VAR VAR sb : STRING(2); tmp : BYTE; END_VAR tmp : byVal SHR 4; IF tmp 9 THEN sb : CHR(48 tmp); ELSE sb : CHR(55 tmp); END_IF tmp : byVal AND 16#0F; ...转换后得到的大写十六进制字符串在触摸屏里显示就非常直观。如果你要把“E200112233445566”写回标签也要执行反向转换每一对十六进制字符转成一个字节注意大小写不敏感。这里提一个经验EPC字符串的处理最好在PLC里完成不要把原始字节直接丢给上位机。因为上位机工程师不一定熟悉RFID帧格式转换工作放在PLC侧上位机只需要处理一行字符串整体集成效率高很多。我遇到过一个项目上位机直接显示乱码查了半天发现是PLC把原始字节当ASC码发给触摸屏了反复提醒后改为此处的转换方案立刻解决。5. 常见问题与排查技巧实录5.1 联调典型问题速查表现象可能原因处理方式PLC连接读写器失败IP地址不在同一网段、读写器未上电、网线故障先用电脑ping读写器IP确认网段和网线再查PLC防火墙或路由设置可以连接但发送命令无响应报文格式错误、校验码不正确、端口号不对用TCP调试工具手动发帧定位对照协议手册逐字节确认能读到标签但数据显示乱码字节序反了、十六进制和ASCII转换错误检查PLC中的字节交换逻辑确认触摸屏上期望的显示格式读卡距离明显缩短天线被金属遮挡、标签类型不匹配、输出功率配置过低检查安装位置换标签测试在读写器配置里调高发射功率偶尔读不到标签标签移动速度过快、天线区有干扰、多标签冲突增加读卡重试次数调整传感器触发位置开启读写器的防碰撞算法PLC报类似ER75等通讯或轴相关报警PLC与外部设备通讯超时、EtherCAT/以太网通讯异常排查网线、交换机端口、设备供电重点检查PLC是否与某些模块断连上电后PLC和读写器连不上重启后恢复读写器上电比PLC慢处于启动过程中PLC侧增加延迟初始化或自动重连机制多标签同时进入天线区读到多个EPC没有开启单标签模式或者读写器默认盘点模式按应用需求改为单标签读取或在上层逻辑里指定EPC过滤5.2 汇川PLC报类似ER75这类报警时怎么办汇川PLC的报警代码是一个大深坑不同系列的报警含义不完全一致。以“类似ER75”这类以ER开头的报警代码为例通常和通讯类异常有关可能指以太网连接超时、从站掉线或内部总线通讯故障。当你在联调RFID时看到这类报警先别慌按三步排查第一步确认是不是RFID通讯导致的。暂时断开PLC和读写器的连接看报警是否复位。如果能复位说明大概率是TCP连接异常触发相关保护。 第二步检查PLC的以太网口状态。查看PLC系统诊断页面里以太网口的物理连接状态如果显示断开大概率是网线接触不良、交换机端口损坏或读写器关机。 第三步查看PLC的Socket连接状态。如果一个TCP连接长期处于半开状态连接已经断了但PLC没感知也会导致通讯任务超时报错。解决办法是在PLC设置里开启TCP KeepAlive或者定期检测连接状态并重连。现场实际处理过一个案例读写器独立电源有问题电压纹波偏大运行几个小时就会死机重启每次重启PLC端的Socket连接还没释放导致PLC持续报通讯异常。后来在电源前端加了一个滤波器和压敏电阻问题就消失了。所以看到ER系列报警先看物理层再看连接层最后才查报文逻辑。5.3 几个独家避坑经验调试自由协议时我总结出几个能帮你少熬夜的经验。第一TCP调试工具测试时最好把“本地端口”固定下来。有些调试工具每次连接使用随机端口而读写器端如果配置了心跳检测可能会认为IP相同但端口变化的连接是异常连接直接断开。固定本地端口后问题基本消失。第二PLC程序里尽量使用“发送完成”和“接收完成”的回调或标志不要用定时器估算。因为自由协议没有固定通讯周期你估算1秒超时现场网络稍微拥堵就失败。正确做法是设置一个较长的超时时间比如3秒同时统计重试次数。重试次数达到上限后再断开连接重连比单纯延长等待时间更有效。第三标签贴装方向会影响读距。超高频RFID天线有极化方向标签的天线方向要和读写器天线的极化方向匹配否则读距会缩短一半以上。现场调试时如果发现读距和测试时差距很大先检查标签的方向再查功率。第四PLC接收缓冲区要做动态管理。我见过有的工程师直接把所有接收到的数据放一个固定数组没有做偏移保护帧一多就把数组写爆了PLC直接跑飞。正确做法是在缓冲区里设置读写指针收到数据后移动写指针解析完移动读指针指针到达数组末尾时回卷。这个环形缓冲区的思路在PLC里实现并不复杂但能避免很多头疼问题。第五关于“汇川plc用modbus rtu高低位转换”这个搜索热词顺带说一句如果你还在用Modbus RTU接RFID设备强烈建议加一个协议转换思路的验证步骤先用串口调试工具确认设备的返回帧是“大端”还是“小端”然后再模拟PLC按字读取的方式转成字符串。很多人在这一步摔跟头就是默认Modbus RTU一定是低字节在前实际有些厂商寄存器存储顺序是反的。这个坑在TCP自由协议里虽然不存在但换回串口项目时一定要小心。5.4 高低温环境下的稳定性工业现场环境往往不如实验室理想。RFID读写器如果装在高温车间比如注塑、热处理车间要重点关注读写器的功耗和散热。CK-LR08-E00这类超高频读写器发射功率高自身发热也不少如果环境温度已经到40度以上读写器内部温度可能到60度以上长时间运行会触发过温保护或者灵敏度下降。解决方案是尽量安装在通风良好的位置避免阳光直射或在封闭电柜内闷着。低温环境比如冷库、北方室外同样有影响。标签的读距会缩短读写器上电后的启动时间变长这些都是低温下常见的现象。解决办法是选用低温专用标签并在PLC程序初始化时增加一段延时等读写器完全启动后再建立连接。电源方面我前面强调过独立供电这里再补一句读写器的电源地和PLC的地最好都接到同一个接地排防止地电位差导致通讯故障。网线的屏蔽层也要保证单端接地如果双端接地反而会形成地环路干扰。6. 实例复盘一台工装防错机的完整调试流程6.1 设备背景与需求举个近期完成的案例。一台汽车零部件装配工装每个工装上有一个RFID标签里面存了工装编号、保养周期、上次使用时间等信息。操作工把工装放到装配台上光电传感器检测到位PLC要读取工装标签里的编号与工艺配方表比对匹配了才允许下一步操作不匹配就报警并锁定气缸动作。这个案例里CK-LR08-E00负责读标签汇川H5U PLC负责逻辑控制和与HMI交互。工装标签是抗金属标签因为工装本身是金属材质普通标签贴在金属表面读不了。这里提醒做类似项目的朋友金属环境千万不要用普通不干胶标签抗金属标签虽然贵一点但可靠性完全不同。6.2 调试节奏与关键细节先做离线测试用TCP调试工具连接读写器确认读EPC和读用户区的命令帧正常。工装标签预先在写卡工位写入了“WLZY-1001”这样的编号存在用户区PLC读到的是一串ASCII字节直接转换成字符串触摸屏就能显示。接着配置网络读写器IP设为192.168.1.100H5U的IP设为192.168.1.88用小型工业交换机把两者连起来。这里注意产线上如果还有其他PLC或者上位机IP冲突要及时排查。我一般先用笔记本电脑ping一遍整个网段确认没有占用才开始下一步。然后是PLC程序建立连接功能块上电后自动连接读写器收到光电传感器的到位信号后延时200ms确保标签完全进入读取区域发送读用户区命令接收解析成功后把工装编号字符串和工艺配方表里预存的编号比较一致则输出OK信号不一致则输出NG信号并闪烁报警灯。这里有一个很关键的小细节读卡命令发送后PLC不能干等要有一个超时保护逻辑。如果光电信号触发了但标签没读到3秒内没有返回帧PLC应输出“读取失败”提示并重新触发一次读取重试3次仍失败才报警。这个机制在现场特别有用因为工装放置不到位、标签轻微污损都可能导致偶发读失败自动重试比直接报警停机更友好。6.3 现场调试遇到的意外问题这个项目调试时遇到一个有意思的问题标签放在工装侧面天线装在装配台侧面传感器触发时读卡距离大概15厘米按理说很稳但在车间里就是偶尔读不到。排查了很久最后把笔记本电脑屏幕盖上拿频谱仪一看周围有一台高频焊机焊接瞬间产生了强烈的电磁干扰。虽然读写器本身有抗干扰设计但标签收到的能量被干扰信号压制了导致解调失败。解决方式是调整天线的安装角度让标签和天线尽量对正同时把读写器的发射功率从26dBm提高到30dBm读卡可靠性大幅提升。这也说明超高频RFID的现场调试电磁环境的影响绝不能忽视。6.4 与MES联动的扩展思路这个项目后续还做了一个很实用的功能扩展PLC把每次读到的工装编号、读卡时间、操作工号一起通过Modbus TCP上传给MES系统MES里记录每套工装的使用次数和保养提醒。因为RFID数据已经在PLC里解析为字符串了MES侧收到的就是干净的文本数据对接成本很低。如果你也在做类似的数据追溯项目建议在PLC程序里把读卡时间和关键状态位也一并缓存需要查询时按时间戳索引能省很多回头找数据的功夫。另外如果工装标签要做定期复写比如每次使用后更新“最近使用时间”那就需要在PLC里再写一条写卡命令步骤和读卡类似只是报文里多了写入数据。写卡前务必确认标签没有被锁定否则写操作必定失败。7. 一些个人心得与建议PID调试、伺服参数整定、RFID通讯这三样是我觉得自动化现场最容易“玄学化”的东西其实都有规律。自由协议通讯只要把报文格式吃透就不存在玄学。我的习惯是拿到任何RFID读写器先在办公室用TCP调试工具把所有命令跑一遍把每条命令的请求帧和应答帧截图存档。真正去现场前PLC程序里的组帧和解析逻辑就能提前写好现场只是改IP和调试安装位置效率高很多。还有一个小技巧测试标签时不要用金属表面直接贴标签测试读距因为金属完全改变了天线的阻抗特性读距会异常短。如果现场标签是贴在金属上的测试时就必须用抗金属标签贴在金属板上测试否则你会被误差极大的读距数据误导白白浪费半天时间。这套CK-LR08-E00加汇川PLC的方案后续如果再扩展可以考虑用读写器的IO输出做防错门控制或者在PLC里加一个Socket连接池管理多台读写器这些都是在同一个技术框架下的增强底层思路没有变化。先把自由协议的报文逻辑和PLC通讯机制打通后面接什么设备都不怕。 工业RFID读写器与汇川PLC自由协议通讯实战解析
在实际产线上跑了几年RFID项目我越来越觉得“设备联网”这件事本身比选哪款RFID硬件更考验功底。前阵子做一台工装防错机客户指定要CK-LR08-E00这款工业级RFID读写器控制器用的是汇川PLC通讯方式明确要求走以太网TCP/IP自由协议。这个组合听起来不复杂真正动手时会发现细节非常密集自由协议到底怎么定义报文、PLC侧该用哪个功能块去收发、调试时连不上怎么办每个环节都有坑。这篇文章把整套联机方案和调试过程完整拆开从报文格式到PLC程序实现适合正在做RFID与PLC对接的电气工程师、自动化集成商以及想搞懂自由协议通讯底层的朋友。1. 方案价值与总体设计思路1.1 为什么选“以太网自由协议”而不选Modbus TCP或Profinet先说明一个概念工业RFID读写器的对外接口通常有RS232、RS485、以太网三类以太网里又分Modbus TCP、Profinet、EtherNet/IP等“标准协议”以及本文要说的“自由协议”。自由协议本质上就是TCP/IP Socket通讯——PLC作为TCP客户端或服务器直接按读写器厂商规定的报文格式收发原始字节流中间不经过任何协议转换。有人会问Modbus TCP不是更通用吗这里有个很现实的选型逻辑。Modbus TCP虽然上手快但它是一种“寄存器映射”通讯方式读写器必须把读到的标签数据映射到特定寄存器区PLC侧再按Modbus地址去读取。麻烦在于RFID的返回数据往往是变长的比如EPC有6字节、12字节、甚至更多Modbus寄存器地址一旦规划好数据长度变了就不好处理。而自由协议最大的优势就是“透明”——读写器返回什么字节PLC就收到什么字节数据区长度在报文里直接标出来解析起来非常直观。我做过的项目里选择自由协议还有几个实际考量一是读写器的报文功能更完整像盘点标签、读取TID、写用户区数据这些操作自由协议里都是一个命令搞定二是调试过程更容易用Wireshark或者TCP调试工具就能直接看到原始报文问题定位比黑盒的Modbus映射快得多三是和MES、上位机对接时自由协议的报文格式和PC端SDK是一致的PLC程序写好了上位机接手也方便。另外提一句Modbus RTU。很多旧设备还在用RS485走Modbus RTU但RTU通讯里有个经典问题——高低字节顺序。因为Modbus寄存器是16位的而RFID返回的EPC/TID是字节流一组16位数据要在两个寄存器里存谁高谁低如果不统一触摸屏上显示的字符串就会乱。用TCP自由协议时就没有这个高低位转换问题当然前提是你要在PLC内部解析时报文字节序时留个心眼这一点在后面报文解析部分会细说。1.2 CK-LR08-E00 的实际选型理解CK-LR08-E00在CK-LR08系列里属于带以太网口的高配版本工作频率是超高频段UHF860MHz到960MHz支持EPC Gen2和ISO18000-6C标准。超高频RFID的核心优势是识别距离远、速度快配合合适的天线和标签读距能做到两三米甚至更远适合用在产线托盘识别、工装防错、AGV站点定位这类场景。这里做一个关键表格方便大家理解不同接口版本的选择差异型号版本通讯接口适用场景注意事项CK-LR08-E00以太网TCP/IP支持自由协议和Modbus TCP需要高速率、大数据量、多设备联网需要PLC或上位机具备以太网接口CK-LR08-S00示例RS232/RS485串口距离近、点数少、老设备改造串口线缆长度受限485需要终端电阻CK-LR08-E00IO版示例以太网IO输入输出有传感器/执行器联动的场景IO点可作为读卡触发信号或结果输出我为什么建议自动化项目优先考虑以太网版因为PLC和读写器之间只拉一根网线供电另外走24V布线比串口干净得多。而且现在汇川的中大型PLC基本都带以太网口H5U、AM系列都支持Socket通讯硬件上不需要额外加通讯模块。现场维护也方便网线坏了换一根就行不像RS485还要检查终端电阻和极性。当然如果现场PLC确实没有以太网口或者距离超过100米只能走光纤那只能选串口方案这是另一种故事了。工业级这个词也不是随便标的。CK-LR08-E00外壳防护等级在IP54以上能扛0到60度的工作温度电磁兼容性过了工业标准。我见过有人拿商用读写器在产线边上用三个月坏两回最后换工业级设备才算安稳。金属粉尘、电机启停的干扰、夏天车间四十多度的高温这些都是很现实的环境考验。选工业级读写器后面能少很多麻烦。再补充一个点这个读写器除了支持TCP/IP自由协议通常还附带IO输入输出可以接光电传感器做读卡触发也可以输出一个OK/NG信号给PLC这在自动化产线联动时非常有用。实际项目中IO触发比PLC通过网口发“开始读卡”命令更可靠因为硬件信号没有网络延迟问题。2. 通讯协议解析与报文翻译2.1 通讯模型谁主动谁被动开始写PLC程序前先把通讯模型搞清楚。CK-LR08-E00作为服务器模式时PLC作为客户端主动建立TCP连接连接建立后PLC发送命令帧读写器返回应答帧。这个“一问一答”的机制是整个通讯的底层逻辑读写器很少主动上报数据除非你开了“自动读取/主动上传”模式——但工业项目里我通常不建议开原因很简单PLC需要对读卡操作有绝对的控制权什么时候读、读哪些区、要不要重试都应该由PLC的流程逻辑决定而不是靠读写器自己往外面吐数据。为什么推荐读写器做服务器ServerPLC做客户端Client因为PLC做客户端时程序可以在上电初始化时主动去connect如果连接失败可以定时重连逻辑非常好写。反过来如果让PLC做Server读写器主动连PLC你就得在PLC上额外配置监听端口、处理多客户端连接这对大多数PLC来说是很别扭的事。实际调试中我用过让读写器做TCP服务器的模式稳定跑了几个月断线重连机制做在PLC里每两秒检测一次Socket状态断开了就自动重连很好用。2.2 帧结构从报文头到校验码自由协议最核心的功夫就在于“组帧”和“拆帧”。虽然不同厂商的帧格式有差异但结构基本固定。CK-LR08-E00的命令帧一般包含以下部分字节位置内容说明帧头0xBB固定起始字节命令字如0x01表示读卡/写卡/盘点等数据长度2字节从命令字后到校验前的数据区长度数据区可变具体参数不同命令各不相同校验码1字节或2字节常见为CRC16或XOR校验和举个例子单次读取标签EPC假设天线1不需要密码发送命令帧 BB 01 00 03 00 01 00 46 拆解 0xBB 帧头 0x01 命令字读取EPC 0x00 0x03 数据长度3字节 0x00 天线号天线1 0x01 读取标签的EPC区数据区开始共2字节 0x00 保留字段 0x46 校验码XOR或CRC计算结果这里示意读卡器返回帧可能是这样示意结构返回帧 BB 01 00 0E 00 01 00 00 30 31 32 33 34 35 36 37 38 39 3F 拆解 0xBB 帧头 0x01 命令字应答 0x00 0x0E 数据长度14字节 0x00 状态0表示成功 0x01 天线号 0x00 标签数量1个 0x00 保留 0x30~0x39 标签EPC数据ASCII码“0123456789” 0x3F 校验码注意实际项目中不要仅仅凭记忆里的帧结构去写PLC代码一定要以随机附带的通讯协议手册为准。很多设备厂家会更新协议比如增加新命令、调整长度字段的起始位置差一个字节整个帧就解析错了。写卡就复杂一些需要对数据区做更多参数拼接。比如把“12345678”这8个ASCII字符写入标签EPC区命令帧里的数据区会包含写卡密码通常4字节、目标区标志、写入地址、写入数据长度和数据本身。如果需要防改写EPC区默认是锁定状态必须先发送解锁命令再写否则写操作会直接返回失败——这个细节我吃过亏后面专门讲。2.3 报文字节序一个绕不开的细节字节序问题在工业通讯里特别容易踩坑。TCP/IP协议是网络字节序即大端模式高字节在前、低字节在后。多数RFID读写器的协议手册里数据区都是按大端排列的也就是说一个16位的数据0x1234在报文里显示为12 34而不是34 12。但注意汇川PLC尤其是H5U、AM系列内部做数据处理时默认可能是小端模式或按字Word为单位存储。也就是说你在PLC里把一个数组当成字数组去访问时高字节和低字节的排布会和你从报文里看到的不一致这时就需要手动做高低字节交换。最常见的情况是标签里存的是一个“0123456789”的ASCII字符串结果你在触摸屏上看到的是“1032547698”这就是字节序反了。解决思路有两个一是在PLC程序里写一个字节交换函数把接收缓冲区里的每两个字节调换后再拼接二是在读写器配置里看看有没有“输出格式”设置有些读写器的参数页面可以直接选择“字节顺序”改一下就能避免在PLC里处理。我个人的习惯是优先在PLC里做处理因为你无法保证现场其他人改动了读写器配置到时候程序解析会乱。3. 硬件连接与网络参数配置3.1 硬件接线看起来简单细节都在暗处CK-LR08-E00的物理接线有三路24V直流电源、以太网线、IO信号线如果有外接传感器。很多第一次用的工程师会忽略电源的质量直接用PLC的开关电源供电。读写器在发射功率较大时瞬间电流可能到1A以上如果PLC电源本身已经带了伺服、传感器容易造成电压跌落读写器会随机重启或者通讯闪断。我建议给读写器配一个独立的24V 2A开关电源贵不了几十块钱稳定性提升非常明显。以太网连接有两种方式一种是读写器直接网线连PLC的以太网口这种适用于只有一台读写器的场景IP地址规划简单另一种是接入工业交换机适用于多台读写器或PLC和上位机同时需要访问的情况。直连时建议用超五类及以上屏蔽网线长度尽量控制在50米内。工业现场有电机变频器网线抗干扰能力直接决定通讯稳定性。IO信号线的作用要根据应用来定义。最常见的用法是光电传感器接到读写器的IO输入标签到位后给一个硬信号触发读卡PLC只需要等待读写器返回结果也可以由PLC输出一个指令触发读卡但这种方式受网络延迟影响重复性不如硬件触发。现场如果传感器信号抖动严重通常要在读写器配置里加一个小延时滤波。3.2 IP地址规划第一次调试最痛苦的就是IP对不上CK-LR08-E00出厂一般有一个默认IP地址通常是192.168.1.100或者类似网段。要改IP地址一般有两种途径一是用网线连接读写器后通过浏览器访问设备内置配置页面二是用厂家提供的调试工具软件扫描后修改。这里有一个实操建议先不要急着把PLC网口地址改成和读写器同一网段而是先把电脑网卡地址改成同网段用浏览器登录读写器管理页面把IP改到PLC所在的网段里去。否则一旦IP冲突你又忘了登录密码恢复出厂设置会非常麻烦。IP地址规划有个必须遵守的原则PLC和读写器必须在同一个网段子网掩码一致且IP地址不能和网络中其他设备冲突。汇川H5U系列PLC的以太网口默认IP一般是192.168.1.88视版本而定这时候读写器IP最好设成192.168.1.100、192.168.1.101这样预留好的固定地址不参与DHCP自动分配。生产网络里如果还有上位机、MES服务器干脆做一个IP分配表设备多了以后才知道这个规划多重要。设置好IP后的第一个测试动作是ping。电脑ping读写器通不通PLC再ping读写器通不通。有时候是在同一网段还是ping不通很可能是防火墙拦截了ICMP报文这时候可以换一个TCP调试工具直接连60000端口试试比单纯ping更能判断问题。端口方面CK-LR08-E00的TCP服务端口是固定的可能是60000也可能是30000以手册为准。3.3 用TCP调试工具先把“语言”调试通我不建议一上来就写PLC程序先用电脑上的TCP调试工具把报文调通这是整个项目效率最高的环节。你可以用SocketTool、网络调试助手或者串口助手如果支持TCP这类工具建立一个TCP客户端连接读写器的服务端口然后手动发送那几条核心命令比如读EPC、读TID、写EPC。观察返回帧是否和手册一致。这一步做完你基本就掌握了这套设备“说的话”。同时建议把调好的报文复制粘贴到一个txt文件里标注好每条命令的作用这个文件后面写PLC程序时就是最可靠的注释文档。我习惯把“初始化/读EPC/写EPC/读用户区”四条命令的报文样本固定下来后面的PLC程序全部围绕这四类报文来开发。注意一点TCP工具做测试时打开连接的瞬间读写器可能会收到TCP握手之外的空数据有些读写器会返回一个版本号提示有些则直接忽略。如果发现TCP调试工具一连接就收到一串未知数据先别慌可以把它当成读写器上电或者连接成功时的版本信息。4. 汇川PLC侧程序实现4.1 先确认你的汇川PLC支持哪些自由协议能力汇川PLC系列很多不是所有型号都支持TCP Socket自由协议。H5U系列、AM系列是基于Codesys平台的可以使用Socket通讯功能块H3U、H1U系列用的是AutoShop平台部分型号只有串口自由协议没有以太网自由协议或者要通过扩展模块才能实现这一点选型时就要确认好。编程软件也有差异H3U用AutoShopH5U用InoProShop基于CodesysAM系列用InoProShop或InoProShopCodesys内核。如果用的是H5U你的编程环境里可以直接调用内置的TCP客户端功能块比如TcpClientConnect、TcpClientSend、TcpClientReceive也可以直接用更强的Socket库在程序里自己管理连接状态和收发缓冲区。这些功能块本质就是对Berkeley Socket的封装只是把底层细节暴露成梯形图或ST可以调用的形式。提一下“汇川plc下载编程软件”这个问题AutoShop和InoProShop都可以在汇川官网找到下载页面但下载前最好确认软件版本和PLC固件版本匹配不然在线连接时可能提示固件版本不匹配虽然可以强制更新固件但不建议在产线上随意升级。4.2 PLC建立TCP连接初始化与断线重连以汇川H5UInoProShop为例一个最基础的自由协议通讯程序需要三步建立连接、发送命令、接收解析。可以用ST语言或梯形图写我习惯用ST包一个功能块方便以后复用。先定义连接参数VAR bConnect : BOOL; //连接成功标志 TcpClient_0 : TcpClient; //TCP客户端功能块 sServerIP : STRING : 192.168.1.100; uiServerPort : UINT : 60000; xExecuteConnect : BOOL; //触发连接 END_VAR初始化时xExecuteConnect给一个上升沿触发TcpClient功能块内部有连接状态机你只需要监控它的输出引脚。连接成功后bConnect会变为TRUE。断线重连一定要做。实际现场我见过PLC上电顺序不同导致读写器还没启动PLC先连接失败的情况。正确做法是在PLC程序里加一个计时器每2秒检测一次连接状态如果断开就自动重连。有些汇川PLC的TcpClient功能块本身支持自动重连参数直接使能即可如果没这个参数就在外围逻辑里写重连触发。如果不做重连设备运行中读写器断电重启一次PLC就要重启才能恢复这是不能接受的。这一点强烈建议重点检查。4.3 组帧在PLC里拼出一个合法报文组帧看起来只是把固定字节放到数组里其实有几个容易出问题的点一是数组长度和帧头的位置二是长度字段的计算三是校验码的算法。我用ST写一个简单的XOR校验函数因为很多读写器支持最简单的XOR校验和FUNCTION F_XorCheck : BYTE VAR_INPUT pData : POINTER TO BYTE; uiLen : UINT; END_VAR VAR i : UINT; tmp : BYTE; END_VAR tmp : 0; FOR i : 0 TO uiLen - 1 DO tmp : tmp XOR pData[i]; END_FOR F_XorCheck : tmp;如果设备手册要求CRC16而不是XOR建议先在电脑上用Python或者工具算好一组样例报文把CRC结果和手册对上再在PLC里写CRC函数。CRC16的实现本身不复杂但表驱动在PLC里会占用很多存储空间可以用移位法的循环计算实时性完全够。组好帧后调用发送功能块abySendData[0] : 16#BB; abySendData[1] : 16#01; abySendData[2] : 16#00; abySendData[3] : 16#03; abySendData[4] : 16#00; abySendData[5] : 16#01; abySendData[6] : 16#00; abySendData[7] : F_XorCheck(ADR(abySendData), 7); TcpClient_0.ExecuteSend(ADR(abySendData), 8);记得发送前把字节数计算准确多一帧少一帧都会导致读写器不应答。4.4 收包与解析状态机比“扫描周期轮询”更可靠接收数据是自由协议通讯里最考验编程功力的地方。很多人直接在PLC扫描周期里调用“接收”功能块每次收几个字节然后拼在一起处理这种做法在数据量大时会出问题因为TCP是流式传输一次发送的数据可能分多个包到达也可能多个包黏在一起到达。更稳妥的方式是建立“接收状态机”。逻辑是这样的PLC在后台循环接收字节存到缓冲区然后按帧头0xBB、长度字段、完整帧长度来切包。只有缓冲区的字节数达到一帧完整长度后才启动解析。如果收到的第一个字节不是0xBB就继续往后找直到找到帧头。这个思路在Modbus RTU和自由协议里完全通用。ST代码思路示例WHILE bReceiveValid DO //从TcpClient接收缓冲区读1字节 bReceived : TcpClient_0.ReceiveByte(byByte); IF NOT bReceived THEN EXIT; END_IF; //状态机 CASE byState OF 0: //等待帧头 IF byByte 16#BB THEN abyBuffer[0] : byByte; byState : 1; iIndex : 1; END_IF; 1: //接收长度字段和数据 abyBuffer[iIndex] : byByte; iIndex : iIndex 1; IF iIndex 4 THEN //长度字段在abyte[2]和abyte[3]得到完整帧长度 uiFullLen : abyBuffer[2] * 256 abyBuffer[3] 4; END_IF; IF iIndex uiFullLen THEN //完整帧已到 bFrameReady : TRUE; byState : 0; END_IF; END_CASE; END_WHILE;帧准备好后再按命令字去解析。以读EPC为例返回帧的命令字是0x01数据区里偏移量的位置可能随协议版本变化解析时注意状态字和天线号、标签数量这些字段通常都有相对固定的偏移。如果标签数量为0表示没有读到标签这时候PLC逻辑要跳转到重试分支。4.5 数据上抛字符串转换是基本功RFID读到的EPC本质是十六进制字节流但触摸屏和MES通常要显示的是可读字符串。比如一个EPC可能是8个字节E2 00 11 22 33 44 55 66触摸屏上应该显示“E200112233445566”这样一个16个字符的ASCII字符串。这个过程要用PLC标准库里的“字节转十六进制字符串”函数没有的话自己写一个FUNCTION F_ByteToHexStr : STRING(32) VAR_INPUT byVal : BYTE; END_VAR VAR sb : STRING(2); tmp : BYTE; END_VAR tmp : byVal SHR 4; IF tmp 9 THEN sb : CHR(48 tmp); ELSE sb : CHR(55 tmp); END_IF tmp : byVal AND 16#0F; ...转换后得到的大写十六进制字符串在触摸屏里显示就非常直观。如果你要把“E200112233445566”写回标签也要执行反向转换每一对十六进制字符转成一个字节注意大小写不敏感。这里提一个经验EPC字符串的处理最好在PLC里完成不要把原始字节直接丢给上位机。因为上位机工程师不一定熟悉RFID帧格式转换工作放在PLC侧上位机只需要处理一行字符串整体集成效率高很多。我遇到过一个项目上位机直接显示乱码查了半天发现是PLC把原始字节当ASC码发给触摸屏了反复提醒后改为此处的转换方案立刻解决。5. 常见问题与排查技巧实录5.1 联调典型问题速查表现象可能原因处理方式PLC连接读写器失败IP地址不在同一网段、读写器未上电、网线故障先用电脑ping读写器IP确认网段和网线再查PLC防火墙或路由设置可以连接但发送命令无响应报文格式错误、校验码不正确、端口号不对用TCP调试工具手动发帧定位对照协议手册逐字节确认能读到标签但数据显示乱码字节序反了、十六进制和ASCII转换错误检查PLC中的字节交换逻辑确认触摸屏上期望的显示格式读卡距离明显缩短天线被金属遮挡、标签类型不匹配、输出功率配置过低检查安装位置换标签测试在读写器配置里调高发射功率偶尔读不到标签标签移动速度过快、天线区有干扰、多标签冲突增加读卡重试次数调整传感器触发位置开启读写器的防碰撞算法PLC报类似ER75等通讯或轴相关报警PLC与外部设备通讯超时、EtherCAT/以太网通讯异常排查网线、交换机端口、设备供电重点检查PLC是否与某些模块断连上电后PLC和读写器连不上重启后恢复读写器上电比PLC慢处于启动过程中PLC侧增加延迟初始化或自动重连机制多标签同时进入天线区读到多个EPC没有开启单标签模式或者读写器默认盘点模式按应用需求改为单标签读取或在上层逻辑里指定EPC过滤5.2 汇川PLC报类似ER75这类报警时怎么办汇川PLC的报警代码是一个大深坑不同系列的报警含义不完全一致。以“类似ER75”这类以ER开头的报警代码为例通常和通讯类异常有关可能指以太网连接超时、从站掉线或内部总线通讯故障。当你在联调RFID时看到这类报警先别慌按三步排查第一步确认是不是RFID通讯导致的。暂时断开PLC和读写器的连接看报警是否复位。如果能复位说明大概率是TCP连接异常触发相关保护。 第二步检查PLC的以太网口状态。查看PLC系统诊断页面里以太网口的物理连接状态如果显示断开大概率是网线接触不良、交换机端口损坏或读写器关机。 第三步查看PLC的Socket连接状态。如果一个TCP连接长期处于半开状态连接已经断了但PLC没感知也会导致通讯任务超时报错。解决办法是在PLC设置里开启TCP KeepAlive或者定期检测连接状态并重连。现场实际处理过一个案例读写器独立电源有问题电压纹波偏大运行几个小时就会死机重启每次重启PLC端的Socket连接还没释放导致PLC持续报通讯异常。后来在电源前端加了一个滤波器和压敏电阻问题就消失了。所以看到ER系列报警先看物理层再看连接层最后才查报文逻辑。5.3 几个独家避坑经验调试自由协议时我总结出几个能帮你少熬夜的经验。第一TCP调试工具测试时最好把“本地端口”固定下来。有些调试工具每次连接使用随机端口而读写器端如果配置了心跳检测可能会认为IP相同但端口变化的连接是异常连接直接断开。固定本地端口后问题基本消失。第二PLC程序里尽量使用“发送完成”和“接收完成”的回调或标志不要用定时器估算。因为自由协议没有固定通讯周期你估算1秒超时现场网络稍微拥堵就失败。正确做法是设置一个较长的超时时间比如3秒同时统计重试次数。重试次数达到上限后再断开连接重连比单纯延长等待时间更有效。第三标签贴装方向会影响读距。超高频RFID天线有极化方向标签的天线方向要和读写器天线的极化方向匹配否则读距会缩短一半以上。现场调试时如果发现读距和测试时差距很大先检查标签的方向再查功率。第四PLC接收缓冲区要做动态管理。我见过有的工程师直接把所有接收到的数据放一个固定数组没有做偏移保护帧一多就把数组写爆了PLC直接跑飞。正确做法是在缓冲区里设置读写指针收到数据后移动写指针解析完移动读指针指针到达数组末尾时回卷。这个环形缓冲区的思路在PLC里实现并不复杂但能避免很多头疼问题。第五关于“汇川plc用modbus rtu高低位转换”这个搜索热词顺带说一句如果你还在用Modbus RTU接RFID设备强烈建议加一个协议转换思路的验证步骤先用串口调试工具确认设备的返回帧是“大端”还是“小端”然后再模拟PLC按字读取的方式转成字符串。很多人在这一步摔跟头就是默认Modbus RTU一定是低字节在前实际有些厂商寄存器存储顺序是反的。这个坑在TCP自由协议里虽然不存在但换回串口项目时一定要小心。5.4 高低温环境下的稳定性工业现场环境往往不如实验室理想。RFID读写器如果装在高温车间比如注塑、热处理车间要重点关注读写器的功耗和散热。CK-LR08-E00这类超高频读写器发射功率高自身发热也不少如果环境温度已经到40度以上读写器内部温度可能到60度以上长时间运行会触发过温保护或者灵敏度下降。解决方案是尽量安装在通风良好的位置避免阳光直射或在封闭电柜内闷着。低温环境比如冷库、北方室外同样有影响。标签的读距会缩短读写器上电后的启动时间变长这些都是低温下常见的现象。解决办法是选用低温专用标签并在PLC程序初始化时增加一段延时等读写器完全启动后再建立连接。电源方面我前面强调过独立供电这里再补一句读写器的电源地和PLC的地最好都接到同一个接地排防止地电位差导致通讯故障。网线的屏蔽层也要保证单端接地如果双端接地反而会形成地环路干扰。6. 实例复盘一台工装防错机的完整调试流程6.1 设备背景与需求举个近期完成的案例。一台汽车零部件装配工装每个工装上有一个RFID标签里面存了工装编号、保养周期、上次使用时间等信息。操作工把工装放到装配台上光电传感器检测到位PLC要读取工装标签里的编号与工艺配方表比对匹配了才允许下一步操作不匹配就报警并锁定气缸动作。这个案例里CK-LR08-E00负责读标签汇川H5U PLC负责逻辑控制和与HMI交互。工装标签是抗金属标签因为工装本身是金属材质普通标签贴在金属表面读不了。这里提醒做类似项目的朋友金属环境千万不要用普通不干胶标签抗金属标签虽然贵一点但可靠性完全不同。6.2 调试节奏与关键细节先做离线测试用TCP调试工具连接读写器确认读EPC和读用户区的命令帧正常。工装标签预先在写卡工位写入了“WLZY-1001”这样的编号存在用户区PLC读到的是一串ASCII字节直接转换成字符串触摸屏就能显示。接着配置网络读写器IP设为192.168.1.100H5U的IP设为192.168.1.88用小型工业交换机把两者连起来。这里注意产线上如果还有其他PLC或者上位机IP冲突要及时排查。我一般先用笔记本电脑ping一遍整个网段确认没有占用才开始下一步。然后是PLC程序建立连接功能块上电后自动连接读写器收到光电传感器的到位信号后延时200ms确保标签完全进入读取区域发送读用户区命令接收解析成功后把工装编号字符串和工艺配方表里预存的编号比较一致则输出OK信号不一致则输出NG信号并闪烁报警灯。这里有一个很关键的小细节读卡命令发送后PLC不能干等要有一个超时保护逻辑。如果光电信号触发了但标签没读到3秒内没有返回帧PLC应输出“读取失败”提示并重新触发一次读取重试3次仍失败才报警。这个机制在现场特别有用因为工装放置不到位、标签轻微污损都可能导致偶发读失败自动重试比直接报警停机更友好。6.3 现场调试遇到的意外问题这个项目调试时遇到一个有意思的问题标签放在工装侧面天线装在装配台侧面传感器触发时读卡距离大概15厘米按理说很稳但在车间里就是偶尔读不到。排查了很久最后把笔记本电脑屏幕盖上拿频谱仪一看周围有一台高频焊机焊接瞬间产生了强烈的电磁干扰。虽然读写器本身有抗干扰设计但标签收到的能量被干扰信号压制了导致解调失败。解决方式是调整天线的安装角度让标签和天线尽量对正同时把读写器的发射功率从26dBm提高到30dBm读卡可靠性大幅提升。这也说明超高频RFID的现场调试电磁环境的影响绝不能忽视。6.4 与MES联动的扩展思路这个项目后续还做了一个很实用的功能扩展PLC把每次读到的工装编号、读卡时间、操作工号一起通过Modbus TCP上传给MES系统MES里记录每套工装的使用次数和保养提醒。因为RFID数据已经在PLC里解析为字符串了MES侧收到的就是干净的文本数据对接成本很低。如果你也在做类似的数据追溯项目建议在PLC程序里把读卡时间和关键状态位也一并缓存需要查询时按时间戳索引能省很多回头找数据的功夫。另外如果工装标签要做定期复写比如每次使用后更新“最近使用时间”那就需要在PLC里再写一条写卡命令步骤和读卡类似只是报文里多了写入数据。写卡前务必确认标签没有被锁定否则写操作必定失败。7. 一些个人心得与建议PID调试、伺服参数整定、RFID通讯这三样是我觉得自动化现场最容易“玄学化”的东西其实都有规律。自由协议通讯只要把报文格式吃透就不存在玄学。我的习惯是拿到任何RFID读写器先在办公室用TCP调试工具把所有命令跑一遍把每条命令的请求帧和应答帧截图存档。真正去现场前PLC程序里的组帧和解析逻辑就能提前写好现场只是改IP和调试安装位置效率高很多。还有一个小技巧测试标签时不要用金属表面直接贴标签测试读距因为金属完全改变了天线的阻抗特性读距会异常短。如果现场标签是贴在金属上的测试时就必须用抗金属标签贴在金属板上测试否则你会被误差极大的读距数据误导白白浪费半天时间。这套CK-LR08-E00加汇川PLC的方案后续如果再扩展可以考虑用读写器的IO输出做防错门控制或者在PLC里加一个Socket连接池管理多台读写器这些都是在同一个技术框架下的增强底层思路没有变化。先把自由协议的报文逻辑和PLC通讯机制打通后面接什么设备都不怕。