ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

汇川PLC与RFID读写器TCP/IP自由协议联机实战

汇川PLC与RFID读写器TCP/IP自由协议联机实战 去年做一条汽车零部件装配线的追溯改造甲方点名要用RFID做工序防错读写器选了晨控智能的CK-LR08-E00PLC用的是汇川通讯方式要求走以太网TCP/IP自由协议。当时团队里有人建议直接上MODBUS TCP但甲方现场习惯用厂家私有帧做设备联调最后我们按自由协议把整个链路跑通了。这篇文章把完整的联机方案、报文格式、PLC程序思路和现场踩坑记录整理出来给正卡在RFID与PLC通讯调试上的同行做个参考。1. 先把方案想清楚自由协议联机这件事该怎么做1.1 项目要解决的实际问题RFID在产线上的作用说白了就三件事识别、防错、追溯。以这个项目为例每个托盘装一个载码体读写器安装在工位下面托盘到位后PLC自动触发读卡读到当前工件的工序信息判断合格后放行同时把下一道工序的加工结果回写到标签里。整个过程如果靠人工扫码枪节拍根本跟不上而且容易漏扫、错扫。CK-LR08-E00这类工业级RFID读写器的定位就是代替人工完成识别动作。它跟普通读卡器的区别主要在外壳防护、安装方式、电气接口和通讯可靠性上。工业现场有油污、振动、金属遮挡读写器得能扛住这些环境并且要有稳定、可对接PLC的通讯接口。CK-LR08-E00恰好提供了以太网口支持MODBUS TCP和TCP/IP自由协议两种方式这就给PLC联机留出了很大的灵活性。这次项目里PLC选用的是汇川的中大型系列编程环境用InoProShop。汇川PLC分好几个平台老一代和新的Codesys平台在以太网自由通讯上的做法不太一样后面我会专门说。项目刚开始时我最担心的是厂家的协议文档和实际报文对不上所以第一步先把协议手册里关于TCP自由通讯的帧结构逐字节看懂再决定PLC侧怎么写。1.2 为什么选TCP/IP自由协议而不是其他方案通讯方案的选择看着是个细节实际上决定了整个调试周期。CK-LR08-E00支持串口、MODBUS TCP和TCP/IP自由协议。很多人习惯性选MODBUS TCP因为PLC里现成的指令多方便。但自由协议的价值在于指令帧完全由你控制读写器的所有功能都能按厂家私有协议直接调有些特殊指令和自定义数据区访问MODBUS映射未必覆盖得全。打个比方MODBUS TCP就像你去便利店买固定的几样东西货架上有什么你拿什么自由协议则像直接跟店老板下单你想怎么搭配就怎么搭配。RFID读写器这种设备功能码比较多读UID、读数据块、写数据块、配置射频参数每种功能对应的数据格式都不一样用自由协议最直接。另外汇川PLC的支持度也决定了这个选择。像H5U、Easy系列、AM系列这些支持以太网Socket通讯的机型完全可以自己组TCP帧。连接建立后把读写器当服务器PLC当客户端按厂家要求的帧格式发送请求然后接收响应整个逻辑链路非常清晰。需要说明的是这里讲的自由协议是指基于TCP/IP的Socket通讯不是串口自由协议。两者差别很大串口自由协议一般走RS485或RS232波特率、数据位、校验位都要配以太网自由协议走TCP只要IP和端口对就成功了一大半。2. 硬件与通讯架构设计拓扑、IP和端口都不能拍脑袋2.1 硬件清单与连接方式一套完整的读写系统硬件上主要包括读写器、天线如果读写器是分体式、电子标签、工业交换机、PLC和供电模块。CK-LR08-E00有一体式和分体式型号一体式结构简单天线内置或外置可选适合安装空间紧凑的工位分体式读写器通过射频线缆连接外部天线适合读卡区域比较特殊、需要把天线埋进夹具里的场合。安装时要注意读写器的射频区域不能被金属完全包围标签在读写区域内要能稳定经过速度不要超过读写器支持的动态读取能力。实际项目里托盘带着标签从读写器上方经过停留时间大约0.5秒这个节拍对高频RFID来说非常宽裕读个UID和数据块毫无压力。供电方面CK-LR08-E00需要单独供电一般是直流24V注意正负极别接反也别和电机驱动共用一路电源。工业现场电源干扰是隐形的坑如果读写器偶尔出现通讯超时但报文看着又没问题多半是电源纹波或接地不良导致的。网络拓扑建议汇川PLC --- 工业交换机 --- CK-LR08-E00读写器 --- 上位机(可选调试用)我建议现场一定加一台工业交换机不要PLC直接网线连读写器。原因很简单调试阶段上位机要抓包、改参数有交换机可以同时挂电脑运行阶段万一要加第二台读写器交换机也能轻松扩展。一台4口的工业交换机成本不高但省去了后续大量扯线改拓扑的麻烦。2.2 IP规划与通讯角色分配TCP自由协议联机前IP规划是优先级最高的事。现场设备一多IP冲突的坑我踩过不止一次。建议把PLC、读写器、上位机划分在同一个网段各自地址固定不要用DHCP。设备IP地址端口角色汇川PLC192.168.1.10任意未占用端口如8000TCP客户端CK-LR08-E00192.168.1.88默认监听端口按厂家手册TCP服务器调试电脑192.168.1.100无抓包/诊断端口号要注意PLC和读写器通讯时读写器作为服务器监听固定端口PLC作为客户端去连接。有的厂家读写器默认端口是502或6000具体以CK-LR08-E00手册为准配置时必须保证和读写器里的监听端口一致否则TCP握手都完不成。PLC作为客户端主动连接这是工业现场最常见的做法。好处是PLC上电后能自己决定什么时候发起连接断线后也方便PLC侧做重连逻辑。有些场景会把读写器配成客户端、PLC做服务器但从稳定性和维护成本看除非甲方有特殊要求我一般都建议读写器做服务器。3. 报文结构与协议细节不搞懂帧格式后面全是坑3.1 CK-LR08-E00的指令帧长什么样自由协议联机最核心的部分就是报文。CK-LR08-E00的TCP自由协议指令帧结构一般由帧头、命令字、长度、数据区、校验码组成。不同厂家不同型号帧结构有差异这里以常见结构为例具体字节定义要严格对厂家手册我这边只讲通用思路。常见帧结构如下字段字节长度说明帧头2字节一般固定用于帧同步命令字1字节区分读、写、配置等操作数据长度2字节数据区字节数数据区N字节标签数据、地址、内容等校验码2字节CRC16低字节在前举个例子读取标签UID的指令假设厂家定义为0x01命令字如果帧头是0xAA 0xAA那么发送帧大致是AA AA 01 00 00 03 05 CRC_LO CRC_HI其中03是数据长度05表示要读的块地址CRC是前面所有字节的校验结果。这种格式看着简单但很多人第一次写程序就挂在CRC上。CRC算错或者高低字节顺序反了读写器直接不响应而且不会给你任何提示。响应帧的格式和请求帧差不多只是命令字后面会多一个状态字节0表示成功非0表示异常。读UID成功后数据区里就是8字节或4字节的UID值顺序按厂家定义来。这里有个容易忽略的点有些标签返回的UID是反序的需要程序里把字节顺序调整过来再和MES系统比对。3.2 PLC侧需要处理的高低字节与CRC问题用汇川PLC组织TCP报文时最烦的就是高低字节问题。汇川PLC内部寄存器一般按16位存储而RFID报文是按字节流的顺序发的。比如一个16位寄存器里的0x0102如果按大端发出去是01 02按小端发出去是02 01。厂家协议里如果明确说“低字节在前”你就必须把寄存器的低8位先放到发送缓冲区。这跟很多人搜过的“汇川PLC用MODBUS RTU高低位转换”是一个道理。MODBUS RTU里写32位浮点数也要处理字序而TCP自由协议处理的是字节序。我建议在PLC里专门建一个发送缓冲区BYTE数组发送前按帧格式逐字节填充不要直接用一个字数组往Socket里发否则高低字节问题会折腾你半天。CRC16校验的算法网上很多PLC里可以用ST语言实现。核心逻辑是查表法或按位计算这里给一个简单的ST实现片段兼容汇川的ST编辑器FUNCTION CRC16_MODBUS : WORD VAR_INPUT Data : ARRAY OF BYTE; Len : INT; END_VAR VAR i : INT; j : INT; Crc : WORD; Carry : BOOL; END_VAR Crc : 16#FFFF; FOR i : 0 TO Len - 1 DO Crc : Crc XOR WORD(Data[i]); FOR j : 0 TO 7 DO Carry : (Crc AND WORD(16#0001)) 0; Crc : SHR(Crc, 1); IF Carry THEN Crc : Crc XOR WORD(16#A001); END_IF; END_FOR; END_FOR; CRC16_MODBUS : Crc;校验算完后发送时需要注意厂家协议要求的是CRC高字节在前还是低字节在前。这个细节太容易翻车了我在现场见过有人调了一整天最后发现就是发送时校验字节顺序反了。所以拿到协议文档第一步先把示例帧里的CRC值自己拿算法算一遍对上了再往下写PLC程序。3.3 读卡流程的状态机设计PLC读卡不能简单一条指令发出去就干等因为TCP是异步通讯发送到接收之间有时间差。我在PLC里习惯用状态机管理整个读写流程空闲态、建连态、发送态、等响应态、解析态、错误处理态。空闲态等待触发信号触发后检查连接没连上先执行连接连接成功后发送读卡帧同时把超时定时器清零然后在等响应态里轮询接收缓冲区收到完整帧就跳去解析超时没收到就跳错误处理重试或报警。这个状态机看起来笨但现场稳定性非常高不会出现因为通讯慢导致的上位机逻辑卡死问题。超时时间的设置一般给500毫秒。如果读写器读卡区域比较小、标签又走得快可以把超时适当延长但不要超过1秒否则托盘憋在工位前等结果节拍就拉垮了。4. 汇川PLC端联机实操从建连到收发帧的完整流程4.1 初始化与网络配置以汇川H5U/Easy系列为例打开InoProShop新建工程后先在PLC的以太网配置里设置好本机IP让PLC和读写器处于同一网段。不同系列的设置位置不太一样但思路一致先确保物理链路通再谈应用层。Socket通讯在汇川里有对应的功能块或指令有的系列叫OPEN_SOCKET、TCP_SEND、TCP_RECV有的系列集成在通讯指令库里。你需要先确认自己的PLC固件版本是否支持不支持的话得升级固件或改用MODBUS TCP映射方式。我建议把Socket相关功能块封装成一个FB功能块比如叫FB_RFID_READER内部封装连接、发送、接收、超时处理。这样主程序里只需要一个FB实例读卡时调用一次回传读到的数据和状态码。封装的好处是后期换读写器型号只需要改这个FB的内部实现主逻辑一行不用动。4.2 连接建立与数据接收的关键逻辑连接建立要注意一个细节PLC作为客户端发起连接后读写器不会主动发送任何数据只有PLC发送请求帧它才回响应帧。所以PLC侧的接收缓冲区不需要常年监听只要发送完请求后去“捞”响应就行。接收响应时要按帧头判断是不是完整的一帧。有些现场网络抖动可能一次TCP接收只收到半个帧或者一个包粘了两帧。我的做法是PLC每扫描周期检查Socket接收缓冲区把收到的字节追加到一个BYTE数组里先用帧头包头判断能不能找到完整帧再根据长度字段确认一帧是否收齐收齐了才解析。这个处理逻辑写起来不复杂但对稳定性提升很大。汇川PLC里如果用ST写接收处理逻辑类似// 假设从Socket读到 rxTemp FOR i : 0 TO rxLen - 1 DO rxBuf[rxIndex] : rxTemp[i]; rxIndex : rxIndex 1; END_FOR; // 查找帧头0xAA 0xAA IF rxIndex 2 AND rxBuf[0] 16#AA THEN // 移位找帧头 END_IF; // 解析完整帧长度判断是否满足一帧 IF rxIndex 帧总长度 THEN // 执行解析 END_IF;这里要注意汇川的ST语言和高级语言的数组操作有点差异写之前先在文档里确认指令语法别等编译报错再翻手册。4.3 写卡逻辑与数据绑定读卡搞定了写卡是另一个大头。产线防错不仅要读还要往标签里写结果。写卡指令一般需要指定块地址和数据内容比如把“OK”或“NG”状态、操作工号、加工时间写到标签的数据块里。写卡前建议加一个校验步骤先读出来确认当前标签状态再执行写入写完再读回比对。有人觉得这样太啰嗦但RFID写卡存在射频功率不够、标签进入半写状态的情况写一半掉线会造成标签数据错乱后续追溯就全乱了。加读回比对多耗几十毫秒但对可靠性提升是值得的。数据绑定方面PLC读到的UID和工装托盘绑定上传给上位机或MES时注意UID字节序要和数据库里存的比对规则一致不然会出现同一张卡在MES里却查不到历史的诡异问题。4.4 现场联调的标准步骤联调时我会按下面的顺序走每一步都确认无误再进下一步。第1步用电脑的串口调试助手或网络调试助手直接连CK-LR08-E00手动发送读卡帧确认读写器本身工作正常、帧格式正确。这个步骤排除了PLC的干扰把问题范围缩小到设备和协议层面。第2步电脑的IP改成和读写器同网段用网络调试工具建立TCP连接发送刚才调通的读卡帧确认以太网通讯正常。同时用Wireshark抓包看TCP握手和数据报文确认没有丢包、重复包。第3步把PLC的IP配好用调试工具模拟PLC作为客户端连接读写器确认连接和收发帧逻辑顺畅。如果这一层有问题重点检查PLC的Socket功能块参数。第4步把上面的收发逻辑移植到PLC程序里先不要接产线信号直接手动触发读卡看PLC能不能收到正确的UID。第5步接入自动流程信号用托盘实际跑几轮观察读卡时间、写卡结果和异常重试逻辑。5. 现场排查实录与避坑技巧5.1 高频故障速查表联机项目调试中问题基本都有固定的套路可查。这里把常见的现象和排查方法整理成一个速查表每个问题我都在现场实际处理过。现象可能原因排查与解决PLC连不上读写器IP网段不一致、端口错误、读写器未启动先ping通读写器IP再检查端口配置确认读写器电源正常能连接但发帧无响应帧格式错误、CRC错误、命令字不对用调试助手发已知正确的示例帧对比用计算器验证CRC响应帧解析乱码高低字节顺序不对、粘包、丢失帧头检查接收缓冲区处理逻辑确认按字节流接收不是按寄存器直接读读卡偶尔失败标签移动速度过快、射频区域遮挡、电源不稳调整读写器安装高度降低标签移动速度换独立电源写卡写一半报错标签距天线过远、射频功率不够靠近读写区域检查天线接线适当增加写卡等待时间通讯时好时坏网线屏蔽差、交换机和PLC端口问题换屏蔽网线检查交换机端口速率匹配不要用劣质水晶头5.2 别被其他站点的报警带偏现场有个特点是各设备之间互相耦合一个地方出问题好几个地方同时报警。调试RFID通讯时如果PLC上同时报了ER75等伺服报警很容易被误导成是通讯问题引起的。事实上ER75是伺服驱动器那一侧的故障码跟上位机与RFID的TCP通讯并没有直接关系。排查时一定要按站段分隔开先用调试助手独立测读写器再去查伺服报警不然会在错误方向浪费时间。还有一点现场常见的还有网线质量问题。工业环境里用的是带屏蔽层的超五类或六类网线水晶头屏蔽层必须压接到位。我见过一个项目RFID读写器偶尔超时排查了两天最后发现是网线屏蔽层没有接地设备一启停干扰就串进网线里。换了一根正规压接的屏蔽网线问题马上消失。5.3 断线重连和心跳机制TCP通讯还有一个容易被忽略的点断电重连。现场读写器或交换机偶尔会断电重启PLC如果不做断线检测和自动重连系统就卡死了。我一般在程序里加一个连接状态监测如果TCP连接断开PLC主动重新发起连接。另外读写器在空闲时不会主动发数据但有些设备支持心跳包机制PLC可以定时给读写器发一个空操作或查询指令一能维持连接活跃二能顺便检查读写器是否在线。心跳间隔一般设3秒左右太频繁增加网络负担太久会让故障发现不及时。5.4 标签安装和天线方向是最容易被忽视的物理坑协议和程序都调通了最后还是可能读不到卡。这时候问题多半出在物理层。金属托盘上装标签标签和金属面之间必须有安装间隙或专门的抗金属标签否则标签天线直接被金属吃掉能量读写器怎么调都没用。天线方向也很讲究。CK-LR08-E00的一体式读写器天线面有固定的辐射方向标签经过时标签平面要和天线面尽量平行读取距离别超过厂家标称范围。如果现场安装位置有限制读写器倾斜安装的话要认真做距离测试别按理论最大距离去设计产线节拍。我个人在实际项目中养成的一个习惯是RFID硬件装好后先用厂家自带的演示工具把所有可能的位置、角度都测试一遍记录每个位置的读取成功率形成一张现场“读取热区图”。后期调试PLC程序时所有参数都基于这张图来定省去大量盲目调参的时间。6. 实操经验收尾前面几节基本把CK-LR08-E00与汇川PLC通过以太网TCP/IP自由协议联机的流程过了一遍最后再分享一个我自己总强调的建议自由协议联机没有捷径协议文档里每一个字节都不能放过尤其CRC校验和字节顺序错一个就前功尽弃。而一旦调通了第一套后面复制到别的工位就非常快。从项目交付的角度讲RFID读写器是否能稳定联机直接决定整个追溯系统能不能跑起来。技术上并不复杂难的是细节。希望这个实际案例能让你少走一点弯路尤其是那些在协议帧、CRC、IP规划上反复折腾的同行按我这里的状态机和排查思路走一遍应该能把联机时间压缩到半个工作日以内。
返回列表