简介面向工业自动化开发者与PLC调试工程师这份资源围绕OMRON PLC串口通讯实例展开以Visual Studio解决方案形式提供完整的上位机通讯程序覆盖串口参数设置、通讯协议封装、指令收发与响应解析等关键环节既适合初学者按图索骥也为工程师提供了可复用的工程框架。压缩包内共38个文件以C#源码cs为主辅以工程配置sln/csproj、窗体设计resx、位图资源bmp、可执行文件exe及说明文档txt资源紧凑总体积仅1.64MB目录结构清晰便于按模块查找。已有3646人学习浏览实用性得到一定验证。资源中的PLC_OMRON通讯程序测试工程演示了RS-232/485串口下的通讯设置、数据请求与返回值判断流程配套的“OMRON串口通讯实例.txt”详细描述了协议交互与错误处理细节通过阅读源码、运行exe并对照文档可快速掌握OMRON PLC串口通讯的工程化实现为后续开发监控或控制网络提供直接参考。 搞工业自动化这行的绕不开串口通讯。别管现在Ethernet/IP、PROFINET这些工业以太网吹得多厉害真到了现场一堆老设备、仪表、扫码枪、变频器最稳的通讯方式还是RS232/RS485串口。我最近刚做完一个欧姆龙OMRONCP1H PLC的串口通讯项目从接线、参数配置、协议帧结构到梯形图逻辑再到上位机联调踩了一路的坑。这篇就把整个过程拆开揉碎了讲清楚给后面要做OMRON串口通讯的人当个参考。先说清楚这篇适合谁看设备维护工程师要接第三方仪表、做上位机的程序员要跟欧姆龙PLC通过串口交换数据、或者刚入门PLC通讯想搞懂Host Link协议的小白都能从里面找到能直接抄作业的东西。项目背景是一个老产线改造上位机需要实时读取三台温控仪的设定值和当前温度并且从PLC侧下发新的温度设定值通讯距离大概50米现场还有变频器干扰所以最终选了RS485总线加Host Link协议的方式实现。为什么这么选后面会详细说。1. 项目背景与选型为什么用串口而不是网口1.1 哪些场景你绕不开串口先说结论能用网口的项目当然用网口但串口通讯在工业现场的生命力比很多人想象中顽强得多。我这次接手的老产线三台温控仪都是十几年前的进口货只支持RS485通讯通讯协议是Modbus-RTU。PLC用的是欧姆龙CP1H自带一个RS232C串口后来又加了一块CP1W-CIF11的RS422/485选件板。为什么不上网口因为温控仪根本就没网口想要跟这三台仪表通讯串口是唯一的选择。类似的场景还有老式变频器的RS485端口、扫码枪的串口输出、电子秤的连续称重数据输出、上位机跟PLC之间的备用通讯通道——这些都是串口通讯的典型应用场景。另外还有一个现实原因在很多工厂里设备维护工程师对串口通讯的熟悉程度远高于工业以太网。现场调试时拿着一根USB转串口线、一个串口调试助手就能干活排查问题比抓以太网包直观得多。所以串口通讯这块技能做自动化的人真不能丢。1.2 为什么选了Host Link而不是纯Modbus欧姆龙PLC的串口通讯大体上有三条路Host Link协议、无协议通讯TXD/RXD指令、Modbus-RTU简易主站功能。我这次的情况比较特殊上位机既要读三台温控仪的数据又必须经过PLC来中转。如果PLC单纯做Modbus主站去采集温控仪数据存在PLC的DM区里上位机怎么把这些数据拿上来有两个方案一是PLC再往上跟PC走Host Link或Modbus二是PC直接再拉一条RS485总线去读温控仪。后者显然增加了硬件成本和复杂性。所以最终方案是PLC用Modbus-RTU通过无协议模式采集三台温控仪上位机通过Host Link协议跟PLC通讯。两层都用串口但协议各司其职。为什么上位机侧选Host Link而不是让PLC做Modbus从站因为欧姆龙CP1H串口在Modbus-RTU从站模式下上位机读数据的灵活性和故障诊断能力不如Host Link。Host Link是欧姆龙自己的标准串口协议支持的读写指令非常全不光能读写DM区还能操作CIO区、W区、定时器计数器当前值而且协议帧里自带FCS校验出错能返回具体错误码调试的时候特别方便。2. 接线与端口参数先避开一半的坑2.1 CP1H串口引脚定义跟常规DB9头不一样先说一个最容易踩的坑欧姆龙CP1H内置RS232C口的引脚定义跟电脑上常见的DB9串口定义是反的。电脑DB9公头是2号脚RXD收数据、3号脚TXD发数据而欧姆龙PLC这边是2号脚SD发数据、3号脚RD收数据。所以PLC跟PC直连时要用交叉线2对3、3对2不能拿一条直通线硬插。CP1H内置RS232C口引脚定义大致如下引脚信号方向说明1FG-框架接地2SD输出发送数据3RD输入接收数据4RS输出请求发送5CS输入清除发送65V输出电源输出7DR输入数据集就绪8ER输出数据终端就绪9SG-信号地如果是用USB转串口线连电脑转出来的通常已经是标准RS232电平但DB9的线序仍然要按照上面的关系交叉。最稳的做法是买一条PLC编程线欧姆龙官方型号CP1W-CIF01配线的交叉线别自己焊现场吃过亏的人都知道自己焊的线有多不靠谱。2.2 RS485扩展板与组网要点项目里要接三台温控仪距离50米RS232肯定不行必须上RS485。我在CP1H上加了CP1W-CIF11这块RS422/485选件板插在PLC的选件板槽位里设置通讯模式后PLC本体就能通过它做RS485通讯。RS485组网有四个细节必须注意通讯线用屏蔽双绞线A线对应D0-接B线对应D1这种说法不同厂家容易混接的时候一定以设备的接线端子丝印为准。总线的两端要接终端电阻一般是120欧。我这个项目里温控仪是总线末端在其内部端子上打了终端电阻PLC这边作为起点没有接如果通讯不稳定可以在CP1W-CIF11的端子上加一个120欧电阻试试。屏蔽层单端接地不要两端都接地否则现场电磁干扰会从地环流窜进来。实际调试中遇到过屏蔽层两端都接地导致通讯误码率飙升的情况后来把PLC这端屏蔽层悬空问题就消失了。手拉手菊花链拓扑不要星形连接。三台温控仪在一条总线上一台一台串下去避免分支过长。2.3 串口参数设置两边必须一字不差串口通讯的所有问题一半以上出在参数不一致上。波特率、数据位、停止位、校验位这四个参数两边只要有一个字母对不上通讯就是乱码或者根本不通。CP1H的串口设置位置在CX-Programmer软件里工程区双击“设置”打开PLC型号设置窗口切到“串口选项”或“内置RS232C”标签页。Host Link模式下的标准默认参数是波特率9600、数据位7位、停止位2位、偶校验。这是欧姆龙Host Link协议的出厂默认值上位机侧必须配成完全一样的参数。我这次因为温控仪那边是8数据位无校验Modbus-RTU通讯要求统一用8N18数据位、无校验、1停止位而PLC的单个串口在无协议模式下只能设一组通讯参数所以最后温控仪总线参数为9600、8N1上位机Host Link那路参数保持不变用Host Link默认值。两个串口各管各的互不干扰这也是当初选CP1H的原因之一。3. Host Link协议实例帧结构、FCS校验与读写指令3.1 先看懂一帧数据是怎么组成的Host Link协议是欧姆龙PLC串口通讯的看家本领。它的命令帧结构非常固定每一个字节都有明确含义 设备号(2字符) 命令码(2字符) 正文(若干字符) FCS(2字符) *回车起始符ASCII码0x40也就是字符表示一帧命令的开始。设备号上下位机之间约定的PLC单元号范围00-31默认00。多个PLC挂在同一条总线上时靠这个区分是发给谁的。命令码两位大写字母RR是读IR/SR区RD是读DM区WR是写DM区WD是写多个DM区这几种最常用。正文跟命令码相关比如读DM区时就是起始地址加读取字数。FCS帧校验它的计算逻辑下面细说。结束符*字符加回车0x2A和0x0D一帧到此结束。我举个例子用上位机发一条命令读取PLC里DM00000开始的2个字00RD00000002FCS*CR这里的RD表示读DM区0000是起始地址对应DM000000002是读取字数。响应帧同样以开头返回数据后以FCS和结束符收尾。3.2 FCS校验码的手算过程写程序前先搞懂原理FCS是整个Host Link协议里最需要细心的地方。它的计算规则是把从字符开始、一直到正文结束不含FCS本身和结束符的所有字符逐个取ASCII码做异或运算结果转成两个十六进制ASCII字符放在帧尾。以读取DM00000开始2个字的命令为例要参与计算的是这些字符00RD00000002它们的ASCII码分别是是0x400是0x30R是0x52D是0x44数字依次累加异或。手算一遍0x40 XOR 0x30 0x70XOR 0x30 0x40XOR 0x52 0x12XOR 0x44 0x56再逐个跟后面的0、0、0、0、0、2异或最后得到0x55转成ASCII字符就是55。整帧命令就是00RD0000000255*CR写上位机程序的时候这段异或逻辑用一个循环就能搞定。关键是注意两点一是参与校验的是字符的ASCII码值不是命令里表示的数字本身二是算出来的结果一定要转成两个大写的十六进制字符小写十六进制在部分设备上会直接报FCS错误。调试时建议先用串口调试助手手工验证一遍FCS的计算结果再去写上位机程序能省很多事。3.3 上位机Python实测读取PLC内存数据拿到PLC这边配好Host Link下面就是上位机侧写代码了。我用Python的pyserial库做了一段最小可用的测试程序三步走打开串口、构造命令帧、等待响应并解析。import serial def calc_fcs(data: bytes) - bytes: fcs 0 for b in data: fcs ^ b return f{fcs:02X}.encode() def read_dm(ser: serial.Serial, start_addr: int, count: int) - bytes: # 命令正文00RD 起始地址(4位HEX) 字数(4位HEX) body f00RD{start_addr:04X}{count:04X}.encode() frame body calc_fcs(body) b*\r ser.write(frame) resp ser.read_until(b\r) return resp if __name__ __main__: ser serial.Serial( portCOM5, baudrate9600, bytesizeserial.SEVENBITS, # 7数据位 parityserial.PARITY_EVEN, # 偶校验 stopbitsserial.STOPBITS_TWO, # 2停止位 timeout0.5 ) data read_dm(ser, start_addr0, count2) print(data)这里有个极易踩的坑用串口调试助手测试时很多人习惯以文本模式发送但Host Link命令里的FCS结果如果包含ASCII字符0-9或A-F还好一旦包含不可见字符虽然十六进制表示法下永远是可见字符就容易被编辑器或调试助手自动转义。所以发送时一定要确保以ASCII字符逐字节发送别在编辑器里开了十六进制发送方式也不要在文本前后加多余的空格或换行。3.4 响应帧的解析与错误码判断Host Link响应帧的格式跟命令帧类似。正常响应时读DM区命令返回的响应会是00RD数据1高字节数据1低字节数据2高字节数据2低字节FCS*CR每个字4个十六进制字符按地址递增顺序排列。解析时要先判断是否为正常响应再看长度是否满足预期最后做FCS校验。如果PLC返回错误响应帧里的正文位置会变成一个两位错误码常见的有错误码含义出现场景E0奇偶校验错误通讯参数不一致、线路干扰E1命令格式错误命令码或地址格式写错E2FCS校验错误FCS计算错、发送多字节少字节E4读/写地址超范围地址超出PLC最大范围调试时看到E2先查FCS计算逻辑看到E0那基本就是串口参数两边不一致或者RS485总线受到了干扰。这套错误码排查体系比对着示波器猜干扰要高效得多。4. PLC梯形图侧从TXD/RXD指令到数据影区4.1 无协议模式下的TXD和RXD指令PLC跟温控仪走Modbus-RTU时用的并不是Host Link而是无协议通讯模式下的TXD/RXD指令。CP1H在端口设置里把通讯模式选成“无协议”后就可以用这两条指令通过串口自由收发数据。TXD指令的用法TXD D100 #0000 #0000第一个操作数D100是发送数据存放的首地址第二个操作数是控制字指定发送字节数和是否加换行符第三个操作数指定串口0是内置RS232C1是选件板12是选件板2。实际发送的字节数由控制字决定默认最多256字节。RXD指令的用法RXD D200 #0000 #0000第一个操作数是接收数据存放的首地址第二个控制字指定接收几个字节第三个指定串口。执行RXD后收到的数据会被搬到D200开始的数据区。写梯形图时最核心的一点是串口接收是异步的必须在接收完成标志位ON的时候才去执行RXD否则数据会丢。很多初学者会犯一个毛病——PLC一上电就循环执行RXD结果数据只收到一半。正确做法是在串口接收完成标志位为ON时把接收到的数据搬运到D区然后复位标志位等下一帧。4.2 发送和接收的时序控制不建议用常ONPLC与温控仪之间的Modbus-RTU通讯讲究一问一答。梯形图里如果只是简单地把发送指令放在一个常ON的循环里那一定会出问题——因为上一帧的响应还没回来下一帧请求就又发出去了总线上全是碰撞。我项目中用的是自己搭的一个状态机梯形图一个定时器做发送间隔控制A标志位表示当前是否在等待响应。步骤如下定时到且无等待响应时执行TXD发送Modbus请求帧同时置位等待响应标志。串口接收完成标志位ON时执行RXD接收响应复位等待标志。接收后做一个简单的帧超时判断超过200ms没收到响应就复位等待标志计数加1并准备重发。这套逻辑用PLS、SET、RSET、TIM这些基本指令就能实现不用花里胡哨的ST语言。关键是状态清晰、时序明确调试的时候看标志位状态一眼就知道卡在哪一步。4.3 为什么要在PLC侧建一个数据影区上位机读PLC数据一个很容易被忽视的问题是数据一致性。比如上位机读三个温度值第一次读的时候温度1和温度2刚被PLC刷新过第二次读的时候温度3可能又刷新了数据之间会存在一个时间差。对这个场景来说温度值实时性要求不算高所以影响不大但如果上位机读的是一个累计量比如流量累计值那PLC一边正在写、上位机一边在读因为数据分为高16位和低16位两个字就可能出现读到的高位是新的、低位是旧的情况一加就是巨大的错误。解决办法是在PLC侧建一个数据影区PLC把从温控仪读到的数据整理好放到固定的D区同时用一个“数据有效”标志位置位。上位机读数据前先读这个标志位确认数据更新完成后再读取整个数据块。这样保证了每次上位机拿到的都是一份完整一致的数据快照。这个设计思路其实所有上位机与PLC通讯场景都适用。5. 现场调试实录通讯失败的三次真实排查5.1 现象一串口口灯亮着但上位机收不到任何数据第一次联调PLC的串口指示灯在闪烁说明PLC发了数据但上位机就是收不到。用USB转串口线连上位机串口调试助手打开后一个字节都进不来。排查链路先查USB转串口驱动是否正常设备管理器里面COM口能认到再查波特率设置最后查到是PLC这边选件板CP1W-CIF11没有设置成无协议通讯模式。CP1H的选件板默认可能是Host Link模式它会把所有进来的数据当成Host Link命令去响应而对Modbus-RTU帧没有任何反应。改设置时发现选件板的通讯模式在CX-Programmer的“设置”窗口里有一个单独的标签页“串口选件”需要把接口类型选成“RS422A/485”通讯协议选成“无协议”然后下传到PLC并断电重启才生效。设备通讯参数没有生效就联调这是最典型的低级错误。5.2 现象二数据乱码时不时还丢一帧三台温控仪的读数在画面上跳变显示的数字明显是乱码用串口调试助手抓包发现请求帧发出去后响应帧偶尔缺失。一开始怀疑波特率不一致后来排查发现Modbus-RTU从站设备要求8N1参数而CP1H的选件板参数我一开始设成了跟Host Link一样的7E27数据位偶校验2停止位。把选件板的串口参数改成9600、8N1之后乱码问题立即消失。另一个导致丢帧的坑是总线上的分支线太长——温控仪到总线的连接线用了大概1米多的平行线两根线扭在一起后干扰明显减小丢帧也没了。遇到串口通讯抖动先确认这两件事通讯参数是否一致线缆是否为双绞线。5.3 现象三偶发通讯超时重试后恢复系统运行半天后出现几次温控仪读数不刷新的情况观察发现是温控仪那边偶尔会延迟响应。Modbus-RTU协议对响应时间是有要求的如果主站发出请求后从站没在规定时间内响应主站就认为超时。查了温控仪说明书发现它有个“通讯响应时间”参数默认设的是500ms而我在PLC侧的超时时间设了200ms导致连续几次超时后就放弃了。把PLC侧的超时时间调到了1000ms并且增加了重试机制——第一次超时不立刻报错重发两次仍无响应才产生通讯报警。这样既保证了实时性又能容忍偶发的从站延迟。调试完发现很多时候不是设备不响应而是你的等待时间根本没给够。5.4 梳理一下通用的串口排障路径这套项目跑下来我把串口联调的排查顺序固化成了自己的习惯也分享给你先看物理层线材是否是双绞屏蔽线接线是否正确终端电阻是否匹配。再看参数层波特率、数据位、停止位、校验位两边逐一核对。然后看协议层帧格式是否对FCS校验是否正确设备地址是否匹配。最后看时序层超时时间、重试机制、从站响应延迟。按这个顺序一层一层往上查绝大多数串口问题都能在半小时内定位。忌讳的是上来就改程序、换设备那只会把问题搞得更复杂。6. 数据联调之外几个值得留意的工程细节6.1 通讯状态一定要可视化别让故障藏起来这个项目做完之后我有个特别深的感触PLC和上位机之间一旦通讯断开如果没有任何报警提示操作工可能一整个班都在用旧数据生产等发现的时候废品已经产生了。所以哪怕只是临时项目也要把通讯状态做成可视化。我一般会在PLC侧加一个通讯心跳计数器上位机每隔5秒写一次这个计数器PLC侧程序每隔100ms检查最后一次写入时间超过10秒没有更新就置一个“通讯中断”标志。这个标志既可以在触摸屏上显示报警也可以驱动一个输出点让蜂鸣器响。类似地PLC与每一台温控仪之间的通讯状态也做了单独的标志位哪一台掉线了一目了然。这套东西不复杂但在现场非常管用。6.2 上位机侧的重试与超时参数也要给出合理的值串口通讯不是TCP/IP没有内建的可靠传输机制可靠性的最后一环得靠应用层自己兜底。上位机侧不能发一条命令就死等必须设超时也不能超时了一次就放弃要有合理的重试次数。以本次项目为例Host Link命令的超时时间设为1000ms连续3次超时判定为通讯故障触发上位机的声光报警同时PLC侧的通讯心跳计数器也因为没有刷新而置位了中断标志。这个设计让两个独立系统都能感知到同一条通讯链路的状态不需要靠人眼发现“好像数据不动了”。6.3 关于“选型能不能一步到位”的一点个人看法项目收尾后回头看一下其实有一个环节本可以更省事如果当初把CP1H换成内置以太网口的型号上位机这侧数据采集会简单很多FINS/TCP协议比Host Link帧结构更友好速度也更快。但这是事后的视角在改造旧产线、配套设备只有RS485接口的现实条件下串口通讯依然是最直接、最可靠的方案。所以我个人的看法是选型时不要唯“新”是举先看现场的既有设备支持什么再看通讯距离和数据量然后才决定用串口还是以太网。很多上了年纪的设备只有串口你想跟它通讯绕不开串口协议这时候能把Host Link、Modbus-RTU这些串口协议吃透永远是加分项。最后再分享一个实操时的小技巧手边常备一个USB转RS485的调试工具配合串口调试助手能在PLC不参与、上位机不参与的情况下单独监听总线上跑了什么数据。很多时候“设备没反应”和“没人发指令”是两回事监听一下总线就能立刻分清责任。这个习惯让我在多个项目里少跟人扯了很多皮。本文还有配套的精品资源点击获取