欧姆龙CP1H串口通讯实战：Host Link与RS485 Modbus-RTU全解析

简介：面向工业自动化开发者与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串口。我最近刚做完一个欧姆龙（OMRON）CP1H 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口引脚定义大致如下：

如果是用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通讯要求统一用8N1（8数据位、无校验、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是起始地址（对应DM00000），0002是读取字数。响应帧同样以@开头，返回数据后以FCS和结束符收尾。

3.2 FCS校验码的手算过程，写程序前先搞懂原理

FCS是整个Host Link协议里最需要细心的地方。它的计算规则是：把从@字符开始、一直到正文结束（不含FCS本身和结束符）的所有字符，逐个取ASCII码做异或运算，结果转成两个十六进制ASCII字符，放在帧尾。

以读取DM00000开始2个字的命令为例，要参与计算的是这些字符：

@00RD00000002

它们的ASCII码分别是：@是0x40，0是0x30，R是0x52，D是0x44，数字依次累加异或。手算一遍：0x40 XOR 0x30 = 0x70，XOR 0x30 = 0x40，XOR 0x52 = 0x12，XOR 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 = f"@00RD{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( port="COM5", baudrate=9600, bytesize=serial.SEVENBITS, # 7数据位 parity=serial.PARITY_EVEN, # 偶校验 stopbits=serial.STOPBITS_TWO, # 2停止位 timeout=0.5 ) data = read_dm(ser, start_addr=0, count=2) 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返回错误，响应帧里的正文位置会变成一个两位错误码，常见的有：

调试时看到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是内置RS232C，1是选件板1，2是选件板2）。实际发送的字节数由控制字决定，默认最多256字节。

RXD指令的用法：RXD D200 #0000 #0000，第一个操作数是接收数据存放的首地址，第二个控制字指定接收几个字节，第三个指定串口。执行RXD后，收到的数据会被搬到D200开始的数据区。

写梯形图时，最核心的一点是：串口接收是异步的，必须在接收完成标志位ON的时候才去执行RXD，否则数据会丢。很多初学者会犯一个毛病——PLC一上电就循环执行RXD，结果数据只收到一半。正确做法是，在串口接收完成标志位为ON时，把接收到的数据搬运到D区，然后复位标志位，等下一帧。

4.2 发送和接收的时序控制，不建议用常ON

PLC与温控仪之间的Modbus-RTU通讯，讲究一问一答。梯形图里如果只是简单地把发送指令放在一个常ON的循环里，那一定会出问题——因为上一帧的响应还没回来，下一帧请求就又发出去了，总线上全是碰撞。

我项目中用的是自己搭的一个状态机梯形图：一个定时器做发送间隔控制，A标志位表示当前是否在等待响应。步骤如下：

1. 定时到且无等待响应时，执行TXD发送Modbus请求帧，同时置位等待响应标志。
2. 串口接收完成标志位ON时，执行RXD接收响应，复位等待标志。
3. 接收后做一个简单的帧超时判断，超过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一样的7E2（7数据位偶校验2停止位）。把选件板的串口参数改成9600、8N1之后，乱码问题立即消失。另一个导致丢帧的坑是总线上的分支线太长——温控仪到总线的连接线用了大概1米多的平行线，两根线扭在一起后干扰明显减小，丢帧也没了。遇到串口通讯抖动，先确认这两件事：通讯参数是否一致，线缆是否为双绞线。

5.3 现象三：偶发通讯超时，重试后恢复

系统运行半天后，出现几次温控仪读数不刷新的情况，观察发现是温控仪那边偶尔会延迟响应。Modbus-RTU协议对响应时间是有要求的，如果主站发出请求后从站没在规定时间内响应，主站就认为超时。

查了温控仪说明书，发现它有个“通讯响应时间”参数，默认设的是500ms，而我在PLC侧的超时时间设了200ms，导致连续几次超时后就放弃了。把PLC侧的超时时间调到了1000ms，并且增加了重试机制——第一次超时不立刻报错，重发两次仍无响应才产生通讯报警。这样既保证了实时性，又能容忍偶发的从站延迟。调试完发现，很多时候不是设备不响应，而是你的等待时间根本没给够。

5.4 梳理一下通用的串口排障路径

这套项目跑下来，我把串口联调的排查顺序固化成了自己的习惯，也分享给你：

1. 先看物理层：线材是否是双绞屏蔽线，接线是否正确，终端电阻是否匹配。
2. 再看参数层：波特率、数据位、停止位、校验位，两边逐一核对。
3. 然后看协议层：帧格式是否对，FCS校验是否正确，设备地址是否匹配。
4. 最后看时序层：超时时间、重试机制、从站响应延迟。

按这个顺序一层一层往上查，绝大多数串口问题都能在半小时内定位。忌讳的是上来就改程序、换设备，那只会把问题搞得更复杂。

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不参与、上位机不参与的情况下，单独监听总线上跑了什么数据。很多时候“设备没反应”和“没人发指令”是两回事，监听一下总线就能立刻分清责任。这个习惯让我在多个项目里少跟人扯了很多皮。

本文还有配套的精品资源，点击获取