在焊装车间做过设备改造的人应该都有同感设备越来越老但产能要求越来越高控制系统不联网生产数据全靠人工抄表管理层要个产量报表还得等班组长自己填。我这次要聊的这套系统本质是给欧姆龙 CPM2C 这种老一代微型 PLC 做一次“联网升级”通过以太网模块把上位机和威纶触摸屏同时接进去组成一套能看、能控、能采集的车间级小系统。如果你手上正好有老设备、老 PLC又没预算整套换新那这篇文章就是冲着你写的。整套方案的核心其实就三件事第一CPM2C 本体只有一个串口怎么让上位机和触摸屏“和平共处”第二老串口怎么转成以太网给上位机用第三威纶触摸屏这一端怎么配置、上位机怎么写才能稳定采集 DM 区和开关量。下面我按一个真实项目的推进顺序把从选型、接线、配置到调试的完整过程讲一遍中间会重点说几个很容易踩的坑尤其是通信超时和双主站冲突这两个处理不好能把人折腾一整天。1. 项目背景焊装车间的实际痛点与选型理由1.1 焊装车间的实际痛点焊装车间跟别的工序不一样工位分散、设备动作节奏快、干扰因素多。我当时接手的那条线大概是十几个工位每个工位用一台 CPM2C 控制点焊钳的动作顺序、电极加压时间和焊接计数。听起来不算复杂但实际运行中问题很具体第一是产量数据不准。焊钳每焊一个点PLC 里计数器加一次但没人去读它每天下班全靠工人看计数器手动报数漏报错报都是常事月底对不上账还要翻岗查。第二是故障响应慢。设备一停机操作工只能按急停再去喊维修维修来了还得用编程手持器或者电脑插线才能看到报警代码耽误时间。第三是工艺参数没法统一管理。电极修磨次数、焊接电流档位这些参数分散在每台 PLC 里工艺员要改参数得一台一台去按很容易漏改。这些痛点的本质就是设备没有一张“网”把它们串起来。当时有两条路摆在面前一条是干脆换新一代带以太网口的 PLC另一条是把现有设备接入网络。换新一代 PLC 当然好但这条线十几台设备光硬件成本加上重新写程序、重新调试的工时预算根本批不下来而且停产改造的时间窗口也只有短短一个假期。所以方案只能朝着“利旧”的方向想保住 CPM2C加通信模块做一套低成本联网改造。1.2 为什么还用 CPM2C 这种老 PLC可能有人会问CPM2C 都停产多少年了为什么不直接换说实话在车间现场做改造最忌讳的就是“为了新技术而新技术”。CPM2C 的性能放在今天看确实平平无奇但它的可靠性是经过十多年现场考验的I/O 点也够用程序容量就算放在当时的工艺要求下也只用了不到一半。而且这台设备本身的机械部分状态还很好冲压、气动、焊接这些执行机构没到寿命就没理由只因为控制器老旧就整机报废。更关键的是CPM2C 虽然老但它的通信协议是欧姆龙经典的 Host Link 协议从 C** 时代传到今天文档非常全上位机开发资料也好找。威纶触摸屏的驱动库里到现在都还保留着对欧姆龙 Host Link 的完整支持选这个组合在技术风险上是最低的。再加上老工程师基本都摸过 C 系列程序维护不需要重新培训长远看反而比换新系统省心。当然利旧不等于硬撑前提是 PLC 本体运行稳定故障率高不高。如果一台 CPM2C 三天两头烧 I/O 点那还是果断换掉更划算。我的判断标准很简单PLC 平均每年非计划停机不超过两次就值得投入做联网改造如果设备的故障已经出在控制器本身上那联网只会把故障放大不如直接换新。1.3 通信方案的思路明确了利旧之后通信方案就变成一道“老串口如何上以太网”的题。CPM2C 不像后来的 CJ 系列有自带以太网口的型号它只有串口通信能力。所以整套系统的骨架是这样PLC 侧CPM2C 的串口负责对外通信支持 Host Link 协议。中间层用以太网模块串口服务器/协议转换器把 RS-232C 转成 TCP/IP这样上位机就不用纠结串口线长度和驱动问题了。上位机侧以 TCP 客户端的方式连接以太网模块的 IP 和端口按 Host Link 协议的帧格式收发数据。触摸屏侧威纶触摸屏本身有串口可以直接和 PLC 的另一个串口相连做本地操作面板和状态显示。这么一拆问题瞬间清晰了。上位机走以太网触摸屏走串口两者通过 PLC 的两个通信口分开互不抢占这是整套系统能稳定运行的关键前提。如果只有一个通信口两个主站抢一个从站通信质量基本没法保证下面会专门讲。2. 通信链路设计与方案选型2.1 三种设备之间的通信拓扑焊装车间这个场景里三台设备的数据流向其实是三种不同的业务上位机要的是“采集和分析”触摸屏要的是“显示和操作”。这两种业务有一个共性——它们都是主站角色而 PLC 是从站角色所有数据交互必须由主站发起请求PLC 被动响应。所以正确的拓扑是这样的上位机 → 以太网模块 → CPM2C 串口 A走 Host Link TCP 封装读取产量、报警、工艺参数下发修改指令。威纶触摸屏 → CPM2C 串口 B走 Host Link 串口直连人机界面读取当前状态、显示故障信息操作工按键控制设备模式。这样划分的另一个好处是故障隔离。上位机那边无论是软件崩溃还是网络断线都不会影响触摸屏的正常使用。操作工靠触摸屏仍然能看状态、操作设备反过来如果触摸屏坏了上位机的数据采集照常进行不至于整个工位变成“盲区”。2.2 以太网模块的两种实现路线对比串口转以太网这件事市面上常见的方案其实是两种很多人一开始会搞混这里必须说清楚。第一种是“串口服务器”。它的本质是把 RS-232C/RS-485/RS-422 串口数据原封不动地打包进 TCP/IP 里面去。上位机连上之后相当于通过网线延长了一根串口线发送的仍然是纯 Host Link 字节流。这种模块的好处是透明传输、协议无关PLC 端和上位机端都不需要改通信逻辑是最贴近原系统的方式。缺点是模块本身没有“理解”协议的能力数据包边界靠字符间隔识别有些廉价模块在波特率较高时会粘包。第二种是“协议网关”。它内置了欧姆龙 Host Link 或者 Modbus 协议的解析能力把以太网侧的 Modbus TCP 请求转换成串口侧的 Host Link 请求。这种方式的好处是上位机可以不用写复杂的 Host Link 帧直接按 Modbus 地址读写就行编程门槛低。坏处是地址映射关系要先理清楚而且网关本身是“半个头脑”如果它固件里对某些特殊区域的映射有 bug排查起来非常恼火。我自己在实际项目里用的是串口服务器这一路具体选的是市面上比较常见的工业级串口服务器模块支持 TCP Server 模式RS-232C 接口波特率最高能到 230400bps。选它而不是协议网关核心原因就一条这套系统里触摸屏已经是标准的 Host Link 直连了上位机照着 Host Link 写一遍两端协议一致排查问题的时候同一个数据帧可以同时对照触摸屏的报文和上位机的报文逻辑很简单。而且 Host Link 本身并不难写后面会展开。2.3 Host Link 协议基础与 FCS 校验既然要写上位机Host Link 这个老牌协议就绕不过去。它的 C 模式帧格式形如 设备号(2字符) 命令码(2字符) 正文数据 FCS(2字符) * CR“”是帧起始标志。设备号是 PLC 上设置的 Host Link 单元号默认是 00范围是 00-31。命令码比如 RD 代表读 DM 区、WD 代表写 DM 区、RR 代表读 IR/AR 区、WR 代表写 IR/AR 区。FCS 是帧校验计算范围是“”后一直到 FCS 前的所有 ASCII 字符两两异或然后把异或结果的高 4 位和低 4 位分别转成 ASCII 十六进制字符就是两位校验码。最后以“* CR”结束。举个读 DM 区的例子要读取 DM0000 开始的 1 个字构造的命令正文是00RD0000000001这里的地址部分和字数部分都是四位。FCS 就是对除去 和帧尾的00RD0000000001做异或计算。这种帧格式看着机械但好处是明确清晰任何语言都能轻松构造。串口参数方面Host Link 的标准搭配是 9600bps、7 数据位、偶校验、2 停止位设备默认参数就是这个。PLC 侧如果之前被人改过参数触摸屏和上位机都会连不上排查时首先要核对这一组设置。FCS 校验是很多初写上位机的人最容易忽略的地方漏了或者算错了PLC 根本不会理你而且它不会报任何错误只会持续沉默这一点在排查故障时很容易让人误判为“线路断了”。3. 现场配置与实操实现3.1 硬件接线与外设端口规划CPM2C 这个型号的通信口资源要提前数清楚。本体上有一个外设端口一般用来接手持编程器或者上位机下载程序优先留给调试不建议在运行中占用它。如果 PLC 本体自带一个 RS-232C 口那这个口就是主要的通信通道如果本体没有就得通过扩展通信板增加一个串口。我这套项目的做法是这样分配的RS-232C 口 → 接串口服务器的 RS-232 端串口服务器再接网线到交换机上位机走 TCP 访问。这根线距离短也就是控制柜内十几厘米不存在抗干扰问题。扩展通信板上的 RS-422 口 → 接威纶触摸屏的 COM 口。因为触摸屏安装在工位面板上离控制柜有一段距离用 RS-422 差分信号走三四米完全没问题。外设端口 → 只在下载程序和现场调试时接线平时盖子盖好防尘防碰。接线这一点上有个极其重要的细节RS-232C 的收发线很容易接反。有些工控老手都栽过PLC 侧的 RXD 要接对方设备的 TXDTXD 接对方设备的 RXD地线必须接屏蔽层单端接地。接反之后的现象是触摸屏通信灯偶尔闪一下但数据全是乱码或者干脆一点反应没有。我当时接完第一件事不是上电而是拿万用表通断档逐根核对线序这一步能省掉后面大量无意义的排查时间。3.2 PLC 侧通信参数设置CPM2C 的通信参数不是写在程序里的而是存在 PLC 的特殊数据区。简单说你把 PLC 切换到编程模式通过 CX-Programmer 的“设置”窗口修改“上位机链接”相关参数或者直接操作 DM 配置区域然后断电重启参数才会生效。我当时设置的参数如下通信协议Host Link上位机链接。设备号00。波特率9600这个速率在短距离串口通信下非常稳没必要贪高反而高速率高电磁干扰环境下容易出奇奇怪怪的字节丢失问题。帧格式7 位数据、偶校验、2 位停止位也就是标准 Host Link 8.9.2 那套。模式无论 PLC 处于运行、监视还是编程模式Host Link 指令都能正常执行。这里要说一句很多人会忽略 PLC 的模式问题。实际调试中发现写 DM 区可以通过 Host Link 指令完成但在运行模式下写某些特殊区域或者执行一些控制类指令时PLC 会直接返回错误码 16 之类的拒绝响应。这不是通信问题而是欧姆龙对运行模式下某些区域写入的保护机制。上位机逻辑里要考虑这一点要么把写入目标限制在 DM 区要么要求现场人员在监控模式下执行参数下传。3.3 威纶触摸屏的组态步骤威纶触摸屏这一侧相对简单因为驱动库里已经把欧姆龙 Host Link 封装好了不需要自己拼帧。我用的是威纶通主流的 MT 系列屏组态软件打开后按这几步走新建工程时设备类型选“OMRON C/N Series Host Link”。设置 COM 口参数要和 PLC 侧完全一致9600、7、偶校验、2 停止位。设备站号填 0对应 PLC 的单元号 00。在画面上新建数值显示元件变量类型选 DM 字地址比如 DM0000 或 DM0100注意地址格式要与驱动型号匹配有些驱动里 DM 地址不带“DM”前缀直接写数字这一点要看驱动帮助文档。按钮元件可以用“设置位”功能关联 PLC 的 IR 区某个位比如 00000 到 00011 这些位用来做启动、停止、复位操作。触摸屏的通信是周期性的它会一直循环发送读命令刷新画面。这里有个小经验画面上的元件如果太多刷新频率会明显下降尤其是 CPM2C 这种老 PLC 的处理能力有限一个循环只响应一帧读列表太长时画面会感觉“卡”。解决方法是把画面分组尽量减少单屏显示的数据点数量或者把数据刷新周期从默认的 100ms 调整到 200ms 以上对实际观察没有影响但 CPU 负载能明显降下来。3.4 上位机通信程序的核心实现上位机我用的 C# 写这不是什么花哨选型纯粹是因为车间现有的管理软件生态是 WindowsC# 里 TcpClient 用起来顺手。整个通信模块的逻辑其实就是一个典型的生产者消费者模型一个后台线程定时发送 Host Link 读命令把返回的数据解析后放进共享变量UI 线程只从共享变量里取数展示。核心部分代码如下已经简化成可理解的结构using System.Net.Sockets; class HostLinkClient : IDisposable { private TcpClient _client; private NetworkStream _stream; public string Ip { get; set; } 192.168.1.100; public int Port { get; set; } 4001; public int TimeoutMs { get; set; } 1000; public void Connect() { _client new TcpClient(); _client.Connect(Ip, Port); _stream _client.GetStream(); _stream.ReadTimeout TimeoutMs; _stream.WriteTimeout TimeoutMs; } public bool IsConnected _client?.Connected true; static string CalcFcs(string data) { byte xor 0; foreach (char c in data) xor ^ (byte)c; return ((char)0123456789ABCDEF[xor 4]).ToString() ((char)0123456789ABCDEF[xor 0x0F]).ToString(); } public string ReadDm(int address, int count) { string body 00RD address.ToString(D4) count.ToString(D4); return SendFrame(body); } public string WriteDm(int address, int value) { string body 00WD address.ToString(D4) 0001 value.ToString(X4); return SendFrame(body); } private string SendFrame(string body) { string frame body CalcFcs(body) * \r; byte[] bytes System.Text.Encoding.ASCII.GetBytes(frame); _stream.Write(bytes, 0, bytes.Length); var resp ReadResponse(); // 解析时需跳过起始帧头检查结束符 return resp; } private string ReadResponse() { System.Text.StringBuilder sb new(); using var ms new MemoryStream(); byte[] buf new byte[1]; while (true) { int n _stream.Read(buf, 0, 1); if (n 0) break; sb.Append((char)buf[0]); if (buf[0] \r) break; } return sb.ToString(); } public void Dispose() _stream?.Dispose(); }上面这段代码只保留了主干实际工程里还要做断线重连、FCS 校验失败重发、日志记录。特别要说明的是读取响应时判断结束符Host Link 的响应帧也是以“* CR”结束所以用读单字节的方式循环读到 CR 为止是相对稳妥的。如果串口服务器开启了“TCP 粘包打包时间”之类的参数响应帧包之间有时间间隔按字节读基本不会出错。另外FCS 校验我做了一层防御发送前算好放进去接收后再验一次。因为 Host Link 在车间电磁环境里偶尔会出现单字节翻转靠串口服务器自己的物理层校验根本拦不住协议层的错帧。收到 FCS 不对的响应就丢弃重发比盲目信任“收到数据就算成功”要靠谱得多。这套逻辑我后来在很多项目里都复制过效果稳定。上位机界面上的东西就不细说了无非是工位状态列表、产量统计、报警记录、参数下发窗口这几块。和触摸屏各有分工触摸屏面向操作工是单设备的“仪表盘”上位机面向班组长和工艺员是整条线的“驾驶舱”。4. 车间调试实录与常见问题排查4.1 通信超时与循环周期之间的取舍通信超时这个坑几乎每个做 Host Link 上位机的人都会撞上一次。症状很典型程序运行几分钟、甚至几十分钟后某一次读操作迟迟收不到响应或者收到但不完整然后整个通信线程就卡死在那里界面上的数据再也不刷新了。问题的根源在于串口服务器是低速串行通道的发包方式它不是瞬时返回的。触摸屏每读一次要等 PLC 从收到帧到响应完成中间隔着串口字节间隔、PLC 扫描周期、帧间延时。如果上位机设置了很短的读写超时比如 200ms现场环境稍微有点干扰某帧重传一次就超时了。但设置太长也有麻烦一旦某次请求真的丢失要等超时结束后才重发耽误时间不说如果多个读命令排队每个都等超时整个循环就彻底拖垮了。我最终的参数是发送超时 500ms接收超时 1000ms把“单帧响应”和“整体等待”分成两层。读命令的轮询周期用 300ms绝不让上位机像发疯一样连续发命令不给 PLC 喘息机会。Host Link 是半双工协议一次只能执行一个主站的请求两个主站同时在两个串口上发请求PLC 其实是分时处理的这一点了解之后就不容易自己把网口流量打满。另外一个容易被忽略的问题是上位机轮询列表的设计。刚开始我为了把数据都读上来一个循环里连续发几十条读命令结果发现后面几条经常超时。后来改成每 300ms 只发一条命令所有数据滚动读取每条数据的实时性稍微差了一点但整条链路的稳定性大幅提升。车间看板上的一组数字哪怕是 1 秒前更新的也完全够用了追求 100ms 级实时性在这个场景里没有意义。4.2 触摸屏和上位机双主站怎么共用前面提过这套系统里触摸屏和上位机分别占用 PLC 的两个串口当时就是这么设计的但实际调试时还是出过状况。我把串口服务器接到扩展板的 RS-422 口触摸屏接本体的 RS-232C 口本来想着两者各走各的可是触摸屏偶尔会报通信错误过几秒又自己恢复很不稳定。排查过程很有意思。先用电脑直接接 PLC 的串口发测试帧一切正常。再把触摸屏单独接上去也正常。两个都接上问题就出现了。最后用串口抓包工具分别挂两个口看数据才发现问题不在协议层而在电气层扩展板的 RS-422 信号和本体 RS-232C 信号虽然物理隔离但电源用的是同一个控制柜开关电源触摸屏一刷新画面、背光功率波动电源纹波会耦合进 PLC 的串口电路导致通信字节偶尔出错。解决的办法土但有效把触摸屏的电源改成单独一路断路器供电和 PLC、串口服务器的电源分开同时 RS-422 屏蔽线只在 PLC 端单端接地避免形成地环路。改完之后连续跑了两个班次通信错误记录一条都没有。这给了我很深的一个教训不少通信问题根本不在协议和软件里而在现场电源和接地排查时不要只盯着网线和串口线要抬头看看配电柜。还有一个软件层面的细节虽然上位机和触摸屏各占一个口但它们同时修改同一个数据区时可能会互相覆盖。比如触摸屏上操作工把模式切到“手动”上位机又正好把模式参数写回“自动”两个操作叠加就会出现不可预期的动作。所以我在 PLC 程序里加了一条“模式切换互锁”逻辑任何主站写入模式字时必须附带一个固定的切换指令码并且写入后 PLC 立即回读校验不一致就恢复到安全状态并报警。这种做法本质上是通过 PLC 端的仲裁来保证双主站安全比在两端“协商”更可靠。4.3 常见故障速查表与排除套路调试过程中整理了一批故障现象和处理套路很多都是靠现场蹲点总结出来的这里直接做成速查表给后面做类似项目的人参考故障现象可能原因排查与处理触摸屏一直显示“PLC No Response”串口参数不一致、设备号错误、接线错误先核对波特率/数据位/校验/停止位再看单元号是否从 00 开始最后用万用表测线序上位机能连接串口服务器但收不到任何数据串口服务器串口参数与 PLC 不一致、Host Link 帧 FCS 算错先用串口助手手动发送一帧正确数据验证 PLC 是否响应上位机偶发超时重新连接后恢复串口服务器 TCP 会话被异常断开、防火墙干扰查看串口服务器日志把 TCP 保活时间调短上位机做好断线重连触摸屏刷新慢、画面卡顿单画面数据元件过多、PLC 扫描周期被频繁中断减画面点数把刷新周期从 100ms 调到 200-300ms通信正常但写入没反应PLC 处于运行模式、写入区域受保护切换到监视模式再写入或修改上位机写入逻辑到允许的区域新增工位后整个网络变慢交换机端口流量冲突、多个主站广播包用静态 IP 分段工位之间不互相广播串口服务器设置独立端口这套速查表后来被我打印出来贴在控制柜门内侧现场维修人员遇到通信问题第一件事先查表大部分情况几分钟内能定位到方向比自己瞎猜强得多。我在多个车间项目的经验都表明通信疑难杂症十有八九出在参数一致性、接地电源和接线这三类物理层面问题真正协议算法写错的反而是少数。4.4 线上通信调试的一个特殊心得调试焊装线通信的时候还有一个很微妙但值得说透的现象。焊装工位的气动电磁阀、焊机变压器功率都不小特别是点焊机工作的瞬间电流可以达到千安级。这种强干扰环境下RS-232C 甚至 RS-422 都容易受影响。该做的屏蔽、接地都做对了可我发现偶尔还是会有帧校验错误尤其是焊机启动的那一刹那。后来仔细观察发现干扰并不只在通信线上还通过 PLC 自身的电源串进来。CPM2C 供电是 DC24V控制柜里的开关电源如果容量富余不大焊机启动的瞬时压降会引起 PLC 电源电压短暂跌落导致串口芯片工作异常。处理办法是在 PLC 电源输入端并一个 4700μF 的电解电容同时把开关电源换成电流余量更大的型号。并上电容之后这类故障几乎绝迹。这个经验我后来在别的车间也给同行提过反馈都说有效。5. 写在最后这套系统上线之后最直观的变化是车间主任再也不用来回打电话问产量了办公电脑上打开上位机界面每个工位焊点数、设备状态、当日累计一目了然。触摸屏端的操作工也反馈设备报警时能看到具体代码不用等维修过来“盲猜”处理故障的时间明显缩短。整体投入只花了十几个串口服务器和一批屏蔽线对比换 PLC 的预算几乎可以忽略不计但产线数据信息化的效果基本达到了预期。最后再分享一个小技巧如果预算允许每个工位的串口服务器尽量选带双串口或至少带一个调试口的型号调试时可以直接从串口服务器的另一个串口接电脑做抓包不用临时改线或者拔插。和我一起跟产线的同事常说这套配置最值钱的地方其实不是省了多少钱而是让两个不同角色的设备都拿到了自己那份数据互不干扰出了问题还能快速定位到物理层还是协议层。如果你也在做老设备联网改造请记住网络规划不一定要做得多么高大上但每个主站该怎么拿数据、拿完数据干什么用一定要在动工之前想清楚。
在焊装车间做过设备改造的人应该都有同感设备越来越老但产能要求越来越高控制系统不联网生产数据全靠人工抄表管理层要个产量报表还得等班组长自己填。我这次要聊的这套系统本质是给欧姆龙 CPM2C 这种老一代微型 PLC 做一次“联网升级”通过以太网模块把上位机和威纶触摸屏同时接进去组成一套能看、能控、能采集的车间级小系统。如果你手上正好有老设备、老 PLC又没预算整套换新那这篇文章就是冲着你写的。整套方案的核心其实就三件事第一CPM2C 本体只有一个串口怎么让上位机和触摸屏“和平共处”第二老串口怎么转成以太网给上位机用第三威纶触摸屏这一端怎么配置、上位机怎么写才能稳定采集 DM 区和开关量。下面我按一个真实项目的推进顺序把从选型、接线、配置到调试的完整过程讲一遍中间会重点说几个很容易踩的坑尤其是通信超时和双主站冲突这两个处理不好能把人折腾一整天。1. 项目背景焊装车间的实际痛点与选型理由1.1 焊装车间的实际痛点焊装车间跟别的工序不一样工位分散、设备动作节奏快、干扰因素多。我当时接手的那条线大概是十几个工位每个工位用一台 CPM2C 控制点焊钳的动作顺序、电极加压时间和焊接计数。听起来不算复杂但实际运行中问题很具体第一是产量数据不准。焊钳每焊一个点PLC 里计数器加一次但没人去读它每天下班全靠工人看计数器手动报数漏报错报都是常事月底对不上账还要翻岗查。第二是故障响应慢。设备一停机操作工只能按急停再去喊维修维修来了还得用编程手持器或者电脑插线才能看到报警代码耽误时间。第三是工艺参数没法统一管理。电极修磨次数、焊接电流档位这些参数分散在每台 PLC 里工艺员要改参数得一台一台去按很容易漏改。这些痛点的本质就是设备没有一张“网”把它们串起来。当时有两条路摆在面前一条是干脆换新一代带以太网口的 PLC另一条是把现有设备接入网络。换新一代 PLC 当然好但这条线十几台设备光硬件成本加上重新写程序、重新调试的工时预算根本批不下来而且停产改造的时间窗口也只有短短一个假期。所以方案只能朝着“利旧”的方向想保住 CPM2C加通信模块做一套低成本联网改造。1.2 为什么还用 CPM2C 这种老 PLC可能有人会问CPM2C 都停产多少年了为什么不直接换说实话在车间现场做改造最忌讳的就是“为了新技术而新技术”。CPM2C 的性能放在今天看确实平平无奇但它的可靠性是经过十多年现场考验的I/O 点也够用程序容量就算放在当时的工艺要求下也只用了不到一半。而且这台设备本身的机械部分状态还很好冲压、气动、焊接这些执行机构没到寿命就没理由只因为控制器老旧就整机报废。更关键的是CPM2C 虽然老但它的通信协议是欧姆龙经典的 Host Link 协议从 C** 时代传到今天文档非常全上位机开发资料也好找。威纶触摸屏的驱动库里到现在都还保留着对欧姆龙 Host Link 的完整支持选这个组合在技术风险上是最低的。再加上老工程师基本都摸过 C 系列程序维护不需要重新培训长远看反而比换新系统省心。当然利旧不等于硬撑前提是 PLC 本体运行稳定故障率高不高。如果一台 CPM2C 三天两头烧 I/O 点那还是果断换掉更划算。我的判断标准很简单PLC 平均每年非计划停机不超过两次就值得投入做联网改造如果设备的故障已经出在控制器本身上那联网只会把故障放大不如直接换新。1.3 通信方案的思路明确了利旧之后通信方案就变成一道“老串口如何上以太网”的题。CPM2C 不像后来的 CJ 系列有自带以太网口的型号它只有串口通信能力。所以整套系统的骨架是这样PLC 侧CPM2C 的串口负责对外通信支持 Host Link 协议。中间层用以太网模块串口服务器/协议转换器把 RS-232C 转成 TCP/IP这样上位机就不用纠结串口线长度和驱动问题了。上位机侧以 TCP 客户端的方式连接以太网模块的 IP 和端口按 Host Link 协议的帧格式收发数据。触摸屏侧威纶触摸屏本身有串口可以直接和 PLC 的另一个串口相连做本地操作面板和状态显示。这么一拆问题瞬间清晰了。上位机走以太网触摸屏走串口两者通过 PLC 的两个通信口分开互不抢占这是整套系统能稳定运行的关键前提。如果只有一个通信口两个主站抢一个从站通信质量基本没法保证下面会专门讲。2. 通信链路设计与方案选型2.1 三种设备之间的通信拓扑焊装车间这个场景里三台设备的数据流向其实是三种不同的业务上位机要的是“采集和分析”触摸屏要的是“显示和操作”。这两种业务有一个共性——它们都是主站角色而 PLC 是从站角色所有数据交互必须由主站发起请求PLC 被动响应。所以正确的拓扑是这样的上位机 → 以太网模块 → CPM2C 串口 A走 Host Link TCP 封装读取产量、报警、工艺参数下发修改指令。威纶触摸屏 → CPM2C 串口 B走 Host Link 串口直连人机界面读取当前状态、显示故障信息操作工按键控制设备模式。这样划分的另一个好处是故障隔离。上位机那边无论是软件崩溃还是网络断线都不会影响触摸屏的正常使用。操作工靠触摸屏仍然能看状态、操作设备反过来如果触摸屏坏了上位机的数据采集照常进行不至于整个工位变成“盲区”。2.2 以太网模块的两种实现路线对比串口转以太网这件事市面上常见的方案其实是两种很多人一开始会搞混这里必须说清楚。第一种是“串口服务器”。它的本质是把 RS-232C/RS-485/RS-422 串口数据原封不动地打包进 TCP/IP 里面去。上位机连上之后相当于通过网线延长了一根串口线发送的仍然是纯 Host Link 字节流。这种模块的好处是透明传输、协议无关PLC 端和上位机端都不需要改通信逻辑是最贴近原系统的方式。缺点是模块本身没有“理解”协议的能力数据包边界靠字符间隔识别有些廉价模块在波特率较高时会粘包。第二种是“协议网关”。它内置了欧姆龙 Host Link 或者 Modbus 协议的解析能力把以太网侧的 Modbus TCP 请求转换成串口侧的 Host Link 请求。这种方式的好处是上位机可以不用写复杂的 Host Link 帧直接按 Modbus 地址读写就行编程门槛低。坏处是地址映射关系要先理清楚而且网关本身是“半个头脑”如果它固件里对某些特殊区域的映射有 bug排查起来非常恼火。我自己在实际项目里用的是串口服务器这一路具体选的是市面上比较常见的工业级串口服务器模块支持 TCP Server 模式RS-232C 接口波特率最高能到 230400bps。选它而不是协议网关核心原因就一条这套系统里触摸屏已经是标准的 Host Link 直连了上位机照着 Host Link 写一遍两端协议一致排查问题的时候同一个数据帧可以同时对照触摸屏的报文和上位机的报文逻辑很简单。而且 Host Link 本身并不难写后面会展开。2.3 Host Link 协议基础与 FCS 校验既然要写上位机Host Link 这个老牌协议就绕不过去。它的 C 模式帧格式形如 设备号(2字符) 命令码(2字符) 正文数据 FCS(2字符) * CR“”是帧起始标志。设备号是 PLC 上设置的 Host Link 单元号默认是 00范围是 00-31。命令码比如 RD 代表读 DM 区、WD 代表写 DM 区、RR 代表读 IR/AR 区、WR 代表写 IR/AR 区。FCS 是帧校验计算范围是“”后一直到 FCS 前的所有 ASCII 字符两两异或然后把异或结果的高 4 位和低 4 位分别转成 ASCII 十六进制字符就是两位校验码。最后以“* CR”结束。举个读 DM 区的例子要读取 DM0000 开始的 1 个字构造的命令正文是00RD0000000001这里的地址部分和字数部分都是四位。FCS 就是对除去 和帧尾的00RD0000000001做异或计算。这种帧格式看着机械但好处是明确清晰任何语言都能轻松构造。串口参数方面Host Link 的标准搭配是 9600bps、7 数据位、偶校验、2 停止位设备默认参数就是这个。PLC 侧如果之前被人改过参数触摸屏和上位机都会连不上排查时首先要核对这一组设置。FCS 校验是很多初写上位机的人最容易忽略的地方漏了或者算错了PLC 根本不会理你而且它不会报任何错误只会持续沉默这一点在排查故障时很容易让人误判为“线路断了”。3. 现场配置与实操实现3.1 硬件接线与外设端口规划CPM2C 这个型号的通信口资源要提前数清楚。本体上有一个外设端口一般用来接手持编程器或者上位机下载程序优先留给调试不建议在运行中占用它。如果 PLC 本体自带一个 RS-232C 口那这个口就是主要的通信通道如果本体没有就得通过扩展通信板增加一个串口。我这套项目的做法是这样分配的RS-232C 口 → 接串口服务器的 RS-232 端串口服务器再接网线到交换机上位机走 TCP 访问。这根线距离短也就是控制柜内十几厘米不存在抗干扰问题。扩展通信板上的 RS-422 口 → 接威纶触摸屏的 COM 口。因为触摸屏安装在工位面板上离控制柜有一段距离用 RS-422 差分信号走三四米完全没问题。外设端口 → 只在下载程序和现场调试时接线平时盖子盖好防尘防碰。接线这一点上有个极其重要的细节RS-232C 的收发线很容易接反。有些工控老手都栽过PLC 侧的 RXD 要接对方设备的 TXDTXD 接对方设备的 RXD地线必须接屏蔽层单端接地。接反之后的现象是触摸屏通信灯偶尔闪一下但数据全是乱码或者干脆一点反应没有。我当时接完第一件事不是上电而是拿万用表通断档逐根核对线序这一步能省掉后面大量无意义的排查时间。3.2 PLC 侧通信参数设置CPM2C 的通信参数不是写在程序里的而是存在 PLC 的特殊数据区。简单说你把 PLC 切换到编程模式通过 CX-Programmer 的“设置”窗口修改“上位机链接”相关参数或者直接操作 DM 配置区域然后断电重启参数才会生效。我当时设置的参数如下通信协议Host Link上位机链接。设备号00。波特率9600这个速率在短距离串口通信下非常稳没必要贪高反而高速率高电磁干扰环境下容易出奇奇怪怪的字节丢失问题。帧格式7 位数据、偶校验、2 位停止位也就是标准 Host Link 8.9.2 那套。模式无论 PLC 处于运行、监视还是编程模式Host Link 指令都能正常执行。这里要说一句很多人会忽略 PLC 的模式问题。实际调试中发现写 DM 区可以通过 Host Link 指令完成但在运行模式下写某些特殊区域或者执行一些控制类指令时PLC 会直接返回错误码 16 之类的拒绝响应。这不是通信问题而是欧姆龙对运行模式下某些区域写入的保护机制。上位机逻辑里要考虑这一点要么把写入目标限制在 DM 区要么要求现场人员在监控模式下执行参数下传。3.3 威纶触摸屏的组态步骤威纶触摸屏这一侧相对简单因为驱动库里已经把欧姆龙 Host Link 封装好了不需要自己拼帧。我用的是威纶通主流的 MT 系列屏组态软件打开后按这几步走新建工程时设备类型选“OMRON C/N Series Host Link”。设置 COM 口参数要和 PLC 侧完全一致9600、7、偶校验、2 停止位。设备站号填 0对应 PLC 的单元号 00。在画面上新建数值显示元件变量类型选 DM 字地址比如 DM0000 或 DM0100注意地址格式要与驱动型号匹配有些驱动里 DM 地址不带“DM”前缀直接写数字这一点要看驱动帮助文档。按钮元件可以用“设置位”功能关联 PLC 的 IR 区某个位比如 00000 到 00011 这些位用来做启动、停止、复位操作。触摸屏的通信是周期性的它会一直循环发送读命令刷新画面。这里有个小经验画面上的元件如果太多刷新频率会明显下降尤其是 CPM2C 这种老 PLC 的处理能力有限一个循环只响应一帧读列表太长时画面会感觉“卡”。解决方法是把画面分组尽量减少单屏显示的数据点数量或者把数据刷新周期从默认的 100ms 调整到 200ms 以上对实际观察没有影响但 CPU 负载能明显降下来。3.4 上位机通信程序的核心实现上位机我用的 C# 写这不是什么花哨选型纯粹是因为车间现有的管理软件生态是 WindowsC# 里 TcpClient 用起来顺手。整个通信模块的逻辑其实就是一个典型的生产者消费者模型一个后台线程定时发送 Host Link 读命令把返回的数据解析后放进共享变量UI 线程只从共享变量里取数展示。核心部分代码如下已经简化成可理解的结构using System.Net.Sockets; class HostLinkClient : IDisposable { private TcpClient _client; private NetworkStream _stream; public string Ip { get; set; } 192.168.1.100; public int Port { get; set; } 4001; public int TimeoutMs { get; set; } 1000; public void Connect() { _client new TcpClient(); _client.Connect(Ip, Port); _stream _client.GetStream(); _stream.ReadTimeout TimeoutMs; _stream.WriteTimeout TimeoutMs; } public bool IsConnected _client?.Connected true; static string CalcFcs(string data) { byte xor 0; foreach (char c in data) xor ^ (byte)c; return ((char)0123456789ABCDEF[xor 4]).ToString() ((char)0123456789ABCDEF[xor 0x0F]).ToString(); } public string ReadDm(int address, int count) { string body 00RD address.ToString(D4) count.ToString(D4); return SendFrame(body); } public string WriteDm(int address, int value) { string body 00WD address.ToString(D4) 0001 value.ToString(X4); return SendFrame(body); } private string SendFrame(string body) { string frame body CalcFcs(body) * \r; byte[] bytes System.Text.Encoding.ASCII.GetBytes(frame); _stream.Write(bytes, 0, bytes.Length); var resp ReadResponse(); // 解析时需跳过起始帧头检查结束符 return resp; } private string ReadResponse() { System.Text.StringBuilder sb new(); using var ms new MemoryStream(); byte[] buf new byte[1]; while (true) { int n _stream.Read(buf, 0, 1); if (n 0) break; sb.Append((char)buf[0]); if (buf[0] \r) break; } return sb.ToString(); } public void Dispose() _stream?.Dispose(); }上面这段代码只保留了主干实际工程里还要做断线重连、FCS 校验失败重发、日志记录。特别要说明的是读取响应时判断结束符Host Link 的响应帧也是以“* CR”结束所以用读单字节的方式循环读到 CR 为止是相对稳妥的。如果串口服务器开启了“TCP 粘包打包时间”之类的参数响应帧包之间有时间间隔按字节读基本不会出错。另外FCS 校验我做了一层防御发送前算好放进去接收后再验一次。因为 Host Link 在车间电磁环境里偶尔会出现单字节翻转靠串口服务器自己的物理层校验根本拦不住协议层的错帧。收到 FCS 不对的响应就丢弃重发比盲目信任“收到数据就算成功”要靠谱得多。这套逻辑我后来在很多项目里都复制过效果稳定。上位机界面上的东西就不细说了无非是工位状态列表、产量统计、报警记录、参数下发窗口这几块。和触摸屏各有分工触摸屏面向操作工是单设备的“仪表盘”上位机面向班组长和工艺员是整条线的“驾驶舱”。4. 车间调试实录与常见问题排查4.1 通信超时与循环周期之间的取舍通信超时这个坑几乎每个做 Host Link 上位机的人都会撞上一次。症状很典型程序运行几分钟、甚至几十分钟后某一次读操作迟迟收不到响应或者收到但不完整然后整个通信线程就卡死在那里界面上的数据再也不刷新了。问题的根源在于串口服务器是低速串行通道的发包方式它不是瞬时返回的。触摸屏每读一次要等 PLC 从收到帧到响应完成中间隔着串口字节间隔、PLC 扫描周期、帧间延时。如果上位机设置了很短的读写超时比如 200ms现场环境稍微有点干扰某帧重传一次就超时了。但设置太长也有麻烦一旦某次请求真的丢失要等超时结束后才重发耽误时间不说如果多个读命令排队每个都等超时整个循环就彻底拖垮了。我最终的参数是发送超时 500ms接收超时 1000ms把“单帧响应”和“整体等待”分成两层。读命令的轮询周期用 300ms绝不让上位机像发疯一样连续发命令不给 PLC 喘息机会。Host Link 是半双工协议一次只能执行一个主站的请求两个主站同时在两个串口上发请求PLC 其实是分时处理的这一点了解之后就不容易自己把网口流量打满。另外一个容易被忽略的问题是上位机轮询列表的设计。刚开始我为了把数据都读上来一个循环里连续发几十条读命令结果发现后面几条经常超时。后来改成每 300ms 只发一条命令所有数据滚动读取每条数据的实时性稍微差了一点但整条链路的稳定性大幅提升。车间看板上的一组数字哪怕是 1 秒前更新的也完全够用了追求 100ms 级实时性在这个场景里没有意义。4.2 触摸屏和上位机双主站怎么共用前面提过这套系统里触摸屏和上位机分别占用 PLC 的两个串口当时就是这么设计的但实际调试时还是出过状况。我把串口服务器接到扩展板的 RS-422 口触摸屏接本体的 RS-232C 口本来想着两者各走各的可是触摸屏偶尔会报通信错误过几秒又自己恢复很不稳定。排查过程很有意思。先用电脑直接接 PLC 的串口发测试帧一切正常。再把触摸屏单独接上去也正常。两个都接上问题就出现了。最后用串口抓包工具分别挂两个口看数据才发现问题不在协议层而在电气层扩展板的 RS-422 信号和本体 RS-232C 信号虽然物理隔离但电源用的是同一个控制柜开关电源触摸屏一刷新画面、背光功率波动电源纹波会耦合进 PLC 的串口电路导致通信字节偶尔出错。解决的办法土但有效把触摸屏的电源改成单独一路断路器供电和 PLC、串口服务器的电源分开同时 RS-422 屏蔽线只在 PLC 端单端接地避免形成地环路。改完之后连续跑了两个班次通信错误记录一条都没有。这给了我很深的一个教训不少通信问题根本不在协议和软件里而在现场电源和接地排查时不要只盯着网线和串口线要抬头看看配电柜。还有一个软件层面的细节虽然上位机和触摸屏各占一个口但它们同时修改同一个数据区时可能会互相覆盖。比如触摸屏上操作工把模式切到“手动”上位机又正好把模式参数写回“自动”两个操作叠加就会出现不可预期的动作。所以我在 PLC 程序里加了一条“模式切换互锁”逻辑任何主站写入模式字时必须附带一个固定的切换指令码并且写入后 PLC 立即回读校验不一致就恢复到安全状态并报警。这种做法本质上是通过 PLC 端的仲裁来保证双主站安全比在两端“协商”更可靠。4.3 常见故障速查表与排除套路调试过程中整理了一批故障现象和处理套路很多都是靠现场蹲点总结出来的这里直接做成速查表给后面做类似项目的人参考故障现象可能原因排查与处理触摸屏一直显示“PLC No Response”串口参数不一致、设备号错误、接线错误先核对波特率/数据位/校验/停止位再看单元号是否从 00 开始最后用万用表测线序上位机能连接串口服务器但收不到任何数据串口服务器串口参数与 PLC 不一致、Host Link 帧 FCS 算错先用串口助手手动发送一帧正确数据验证 PLC 是否响应上位机偶发超时重新连接后恢复串口服务器 TCP 会话被异常断开、防火墙干扰查看串口服务器日志把 TCP 保活时间调短上位机做好断线重连触摸屏刷新慢、画面卡顿单画面数据元件过多、PLC 扫描周期被频繁中断减画面点数把刷新周期从 100ms 调到 200-300ms通信正常但写入没反应PLC 处于运行模式、写入区域受保护切换到监视模式再写入或修改上位机写入逻辑到允许的区域新增工位后整个网络变慢交换机端口流量冲突、多个主站广播包用静态 IP 分段工位之间不互相广播串口服务器设置独立端口这套速查表后来被我打印出来贴在控制柜门内侧现场维修人员遇到通信问题第一件事先查表大部分情况几分钟内能定位到方向比自己瞎猜强得多。我在多个车间项目的经验都表明通信疑难杂症十有八九出在参数一致性、接地电源和接线这三类物理层面问题真正协议算法写错的反而是少数。4.4 线上通信调试的一个特殊心得调试焊装线通信的时候还有一个很微妙但值得说透的现象。焊装工位的气动电磁阀、焊机变压器功率都不小特别是点焊机工作的瞬间电流可以达到千安级。这种强干扰环境下RS-232C 甚至 RS-422 都容易受影响。该做的屏蔽、接地都做对了可我发现偶尔还是会有帧校验错误尤其是焊机启动的那一刹那。后来仔细观察发现干扰并不只在通信线上还通过 PLC 自身的电源串进来。CPM2C 供电是 DC24V控制柜里的开关电源如果容量富余不大焊机启动的瞬时压降会引起 PLC 电源电压短暂跌落导致串口芯片工作异常。处理办法是在 PLC 电源输入端并一个 4700μF 的电解电容同时把开关电源换成电流余量更大的型号。并上电容之后这类故障几乎绝迹。这个经验我后来在别的车间也给同行提过反馈都说有效。5. 写在最后这套系统上线之后最直观的变化是车间主任再也不用来回打电话问产量了办公电脑上打开上位机界面每个工位焊点数、设备状态、当日累计一目了然。触摸屏端的操作工也反馈设备报警时能看到具体代码不用等维修过来“盲猜”处理故障的时间明显缩短。整体投入只花了十几个串口服务器和一批屏蔽线对比换 PLC 的预算几乎可以忽略不计但产线数据信息化的效果基本达到了预期。最后再分享一个小技巧如果预算允许每个工位的串口服务器尽量选带双串口或至少带一个调试口的型号调试时可以直接从串口服务器的另一个串口接电脑做抓包不用临时改线或者拔插。和我一起跟产线的同事常说这套配置最值钱的地方其实不是省了多少钱而是让两个不同角色的设备都拿到了自己那份数据互不干扰出了问题还能快速定位到物理层还是协议层。如果你也在做老设备联网改造请记住网络规划不一定要做得多么高大上但每个主站该怎么拿数据、拿完数据干什么用一定要在动工之前想清楚。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
