企业官网建设流程全解析

在焊装车间做过设备改造的人应该都有同感：设备越来越老，但产能要求越来越高，控制系统不联网，生产数据全靠人工抄表，管理层要个产量报表还得等班组长自己填。我这次要聊的这套系统，本质是给欧姆龙 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 要接对方设备的 TXD，TXD 接对方设备的 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# 写，这不是什么花哨选型，纯粹是因为车间现有的管理软件生态是 Windows，C# 里 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 常见故障速查表与排除套路

调试过程中整理了一批故障现象和处理套路，很多都是靠现场蹲点总结出来的，这里直接做成速查表，给后面做类似项目的人参考：

这套速查表后来被我打印出来贴在控制柜门内侧，现场维修人员遇到通信问题第一件事先查表，大部分情况几分钟内能定位到方向，比自己瞎猜强得多。我在多个车间项目的经验都表明，通信疑难杂症十有八九出在参数一致性、接地电源和接线这三类物理层面问题，真正协议算法写错的反而是少数。

4.4 线上通信调试的一个特殊心得

调试焊装线通信的时候，还有一个很微妙但值得说透的现象。焊装工位的气动电磁阀、焊机变压器功率都不小，特别是点焊机工作的瞬间，电流可以达到千安级。这种强干扰环境下，RS-232C 甚至 RS-422 都容易受影响。该做的屏蔽、接地都做对了，可我发现偶尔还是会有帧校验错误，尤其是焊机启动的那一刹那。

后来仔细观察，发现干扰并不只在通信线上，还通过 PLC 自身的电源串进来。CPM2C 供电是 DC24V，控制柜里的开关电源如果容量富余不大，焊机启动的瞬时压降会引起 PLC 电源电压短暂跌落，导致串口芯片工作异常。处理办法是在 PLC 电源输入端并一个 4700μF 的电解电容，同时把开关电源换成电流余量更大的型号。并上电容之后，这类故障几乎绝迹。这个经验我后来在别的车间也给同行提过，反馈都说有效。

5. 写在最后

这套系统上线之后，最直观的变化是车间主任再也不用来回打电话问产量了，办公电脑上打开上位机界面，每个工位焊点数、设备状态、当日累计一目了然。触摸屏端的操作工也反馈，设备报警时能看到具体代码，不用等维修过来“盲猜”，处理故障的时间明显缩短。整体投入只花了十几个串口服务器和一批屏蔽线，对比换 PLC 的预算几乎可以忽略不计，但产线数据信息化的效果基本达到了预期。

最后再分享一个小技巧：如果预算允许，每个工位的串口服务器尽量选带双串口或至少带一个调试口的型号，调试时可以直接从串口服务器的另一个串口接电脑做抓包，不用临时改线或者拔插。和我一起跟产线的同事常说，这套配置最值钱的地方其实不是省了多少钱，而是让两个不同角色的设备都拿到了自己那份数据，互不干扰，出了问题还能快速定位到物理层还是协议层。如果你也在做老设备联网改造，请记住：网络规划不一定要做得多么高大上，但每个主站该怎么拿数据、拿完数据干什么用，一定要在动工之前想清楚。