C# 通过 OPC 与 AB PLC 通信实战：从 OPC DA 到 OPC UA 的选型、代码与避坑指南

简介这份资源面向具备一定C#基础、希望打通上位机与工业PLC通信的开发者聚焦使用OPC方式与AB罗克韦尔PLC建立数据交互这一典型工业场景。内容围绕三条主线展开借助Studio 5000编写PLC程序并用Logix Emulate搭建本地仿真环境通过RSLinx Classic配置OPC访问变量再基于Interop.OPCAutomation.dll在C#中实现OPC通信形成从PLC侧到上位机侧的完整链路。压缩包共35个文件约1.53MB以cs源码、exe可执行程序、config配置、resx与resources资源、sln解决方案及csproj工程文件为主另含acd工程、dll库与pdb调试文件结构贴近真实项目。目前已有343人学习下载。读者可据此获得可运行的通信示例、变量配置思路与工程组织方式便于快速复现并迁移到自身项目。1. 从一台 AB PLC 连不上说起C# 走 OPC 通信到底在解决什么产线上有一台 Allen-Bradley 的 ControlLogix上位机是 C# 写的之前一直靠 RSLinx 的 DDE 或者第三方控件硬撑换台电脑就翻车64 位系统上更是玄学。后来我把整条链路换成 OPC问题才算收敛。这篇笔记拆的就是「C# 通过 OPC 和 AB PLC 通信」这件事它是什么、为什么这么选、代码怎么写、参数怎么设、坑在哪。先说清楚定位。AB PLC 是罗克韦尔Rockwell Automation的产品线常见的有 ControlLogix、CompactLogix、MicroLogix 等编程软件是 Studio 5000 / RSLogix 5000。OPC 是一层标准化的数据访问接口把「上位机怎么读 PLC 变量」这件事从厂商私有协议里解耦出来。C# 作为上位机语言通过 OPC 客户端库去连 OPC Server再由 Server 去和 PLC 通信。适合谁做 C# 上位机、SCADA、MES 数据采集的工程师尤其是需要跨品牌、跨版本、长期维护的项目。如果你只是临时读几个点位DDE 也能凑合但只要涉及多客户端、断线重连、批量读写OPC 是更稳的那条路。2. OPC DA 还是 OPC UAAB PLC 场景下的选型与连接链路2.1 两种 OPC 的本质区别与 AB 的适配情况OPC 分两代OPC DAData Access和 OPC UAUnified Architecture。OPC DA 基于 Windows 的 COM/DCOM老项目里到处都是OPC UA 是跨平台、面向服务的新标准自带安全模型和复杂数据类型。AB PLC 这边的情况是罗克韦尔官方主推的是 FactoryTalk Linx以前叫 RSLinx Enterprise作为 OPC DA Server同时新版本也在往 OPC UA 上迁。如果你手上是较老的 ControlLogix 或 CompactLogix用 FactoryTalk Linx Gateway 或 RSLinx Classic 做 OPC DA Server 是最常见的做法如果是新项目、要跨平台或者要过防火墙优先考虑 OPC UA。选型上我给一个实操判断维度OPC DAOPC UA依赖COM/DCOMWindows 限定跨平台TCP 二进制配置难度DCOM 权限是老大难证书 端点前期麻烦后期省心安全性基本没有签名 加密AB 支持RSLinx / FactoryTalk LinxFactoryTalk Linx Gateway、UA ServerC# 库OpcNetApi、Interop.OPCAutomationOPCFoundation.NetStandard.Opc.Ua我一般会这么定老产线、只读、局域网内OPC DA 够用新项目、要写值、要跨网段直接上 OPC UA别犹豫。2.2 搭起 C# 到 AB PLC 的完整链路链路是这样的C# 客户端 → OPC ServerFactoryTalk Linx / RSLinx→ 驱动 → AB PLCEtherNet/IP。第一步在 OPC Server 里配好 AB PLC 的通信路径。以 RSLinx Classic 为例用 RSWho 浏览到 PLC确认能 Online记下 Topic 名比如PLC_LINE1。这一步不通后面全白搭。第二步C# 侧引用 OPC 库。OPC DA 用OpcNetApi.Com或Interop.OPCAutomationOPC UA 用官方 NuGet 包。# OPC UA 官方库NuGet 安装 dotnet add package OPCFoundation.NetStandard.Opc.Ua dotnet add package OPCFoundation.NetStandard.Opc.Ua.Client第三步写连接代码。OPC DA 的典型写法// OPC DA 连接示例基于 OpcNetApi using Opc.Da; using OpcCom.Da; // 指定 OPC Server 的 ProgIDAB 常见的是 RSLinx 的 string serverUrl opcda://localhost/RSLinx OPC Server; Server server new Server(new Factory(), new URL(serverUrl)); // 连接 server.Connect(); // 构造要读的 ItemItemName 就是 PLC 里的标签路径 Item[] items new Item[] { new Item(new ItemIdentifier(PLC_LINE1, [PLC1]Program:MainProgram.Tag_Start)), new Item(new ItemIdentifier(PLC_LINE1, [PLC1]Program:MainProgram.Tag_Speed)) }; // 批量读 ItemValueResult[] results server.Read(items); foreach (var r in results) { Console.WriteLine(${r.ItemName}: {r.Value} 质量{r.Quality}); }逻辑说明Server对象封装了 OPC DA 的连接ItemIdentifier的第一个参数是 RSLinx 里配的 Topic第二个是 PLC 里的标签全路径。Read是批量读比逐个读效率高得多。参数上Quality字段很关键Good才是真值Bad或Uncertain要单独处理。OPC UA 的写法不同走的是 Session 和 Subscription// OPC UA 连接示例 var endpointUrl opc.tcp://192.168.1.10:4840; var endpoint CoreClientUtils.SelectEndpoint(endpointUrl, useSecurity: false); var session Session.Create( configuration, endpoint, false, CSharpClient, 60000, new UserIdentity(), null).Result; // 读一个节点 var nodeId new NodeId(ns2;sPLC1.Tag_Start); var value session.ReadValue(nodeId); Console.WriteLine($值{value.Value} 状态{value.StatusCode});逻辑说明SelectEndpoint会去探测服务端支持的端点Session.Create建立会话超时设 60 秒NodeId的命名空间索引ns2和标识符要跟服务端一致这个最容易填错。ReadValue是同步读批量场景建议用 Subscription 订阅变化。提示OPC DA 的 ItemName 路径格式在不同 Server 上不完全一样RSLinx 用[PLC名]标签FactoryTalk 可能带 Program 层级先在 Server 自带的测试客户端里确认能读到再往 C# 里搬。3. 批量读写与订阅把轮询改成事件驱动的几个关键参数3.1 批量读写的分组与更新速率新手最容易犯的错是「一个标签一个 Read」几百个点位轮询下来 CPU 直接拉满。正确做法是分组批量读或者干脆用订阅。OPC DA 里用Read传数组就是批量OPC UA 里用ReadValue逐个读也行但更推荐Subscription。订阅的核心参数是 PublishingInterval发布间隔和 SamplingInterval采样间隔。PublishingInterval 是服务端往客户端推的周期SamplingInterval 是服务端去 PLC 取值的周期。一般 SamplingInterval ≤ PublishingInterval否则推的是旧值。// OPC UA 订阅示例 var subscription new Subscription(session.DefaultSubscription) { PublishingInterval 1000, // 服务端每 1 秒推送一次 KeepAliveCount 10, // 10 个周期没数据就发心跳 LifetimeCount 30 // 30 个周期没响应就认为订阅失效 }; var item new MonitoredItem(subscription.DefaultItem) { StartNodeId new NodeId(ns2;sPLC1.Tag_Speed), SamplingInterval 500, // 每 500ms 采样一次 QueueSize 10, // 队列缓存 10 个值 DiscardOldest true // 队列满时丢最旧的 }; item.Notification (monitoredItem, args) { foreach (var v in args.NotificationValue.NotificationValue) { Console.WriteLine($变化: {v.Value}); } }; subscription.AddItem(item); session.AddSubscription(subscription); subscription.Create();逻辑说明PublishingInterval决定推送频率SamplingInterval决定采样频率两者配合不好会出现「数据跳变」或「延迟」。QueueSize和DiscardOldest决定突发变化时怎么处理做趋势记录时 QueueSize 要放大做实时控制时反而要小。Notification事件里拿到的才是真正变化的值。3.2 断线重连与质量码处理产线网络抖动是常态断线重连必须做。OPC UA 的 Session 有KeepAlive机制但客户端要主动监听Session.KeepAlive事件断了就重建。OPC DA 的Server对象没有内建重连得自己写定时器去Connect。质量码Quality是另一个重点。OPC DA 的Quality是枚举Good才可信OPC UA 的StatusCode是Good、Bad、Uncertain三类。做数据入库时Bad的值一定要过滤否则数据库里全是脏数据。// 质量码过滤 if (result.Quality Quality.Good) { // 正常入库 } else if (result.Quality Quality.Bad) { // 记录日志触发重连 logger.Warn($点位 {result.ItemName} 质量异常: {result.Quality}); }参数上重连间隔我一般设 5 秒太短会刷屏太长恢复慢。重连成功后要重新建订阅别指望旧订阅能自动恢复。4. 避坑与排查DCOM、标签路径、64 位这几个高频翻车点4.1 DCOM 配置导致连不上 OPC DA现象C# 程序报「拒绝访问」或「服务器不可用」但 OPC Server 自带的测试客户端能连。原因OPC DA 依赖 DCOM跨用户、跨机器时权限没配好。尤其是 Windows 10/11 和 Server 2016 以后默认权限收得很紧。解决在dcomcnfg里找到 OPC Server 的 AppID把「身份标识」设为交互式用户或指定账户在「安全」里给 Everyone 或具体账户加上本地访问、远程访问、本地激活、远程激活权限。跨机器还要在防火墙放行 135 端口和动态端口范围。这一步没有捷径只能一项项对。4.2 标签路径写错读回来全是 Bad现象连接成功但所有点位Quality都是Bad值为空。原因ItemName 路径格式不对。AB PLC 的标签在 RSLinx 里是[PLC名]Program:MainProgram.Tag但不同 Server 对 Program 层级的处理不一样有的要省略有的要加::。解决先在 OPC Server 自带的 Quick Client 或测试工具里浏览到标签把完整路径复制出来再填进 C#。别凭记忆手写。4.3 64 位程序连不上 32 位 OPC Server现象32 位测试程序能连换成 64 位 C# 程序就报「类未注册」。原因老版本 OPC DA Server 很多是 32 位 COM 组件64 位进程默认加载不到。解决把 C# 项目的目标平台改成 x86或者用 OPC UA 绕开 COM。如果必须 64 位得用 DCOM 的代理/存根proxy/stub或者中间层。我一般直接改 x86省事。4.4 订阅创建成功但收不到数据现象subscription.Create()返回成功但Notification事件一直不触发。原因PublishingInterval设得太小服务端不支持或者SamplingInterval大于PublishingInterval推的是空值再或者节点权限不够。解决先把PublishingInterval设成 1000ms 试确认能收到再往下调。检查SamplingInterval是否小于等于PublishingInterval。用 UaExpert 这类客户端工具连同一个端点对比参数能快速定位是服务端问题还是代码问题。4.5 批量读点位过多导致超时现象一次读几百个点位Read返回超时或部分失败。原因单次请求的 Item 数量超过服务端限制或者网络往返时间太长。解决分批读每批 50100 个点位批之间加个小延时。OPC UA 里可以用ReadValue的批量重载但同样要控制数量。别贪多。5. 进阶技巧用 UaExpert 反推参数把配置变成可复现的清单调 OPC UA 的时候我最依赖的工具是 UaExpert。它是个免费的 OPC UA 客户端能浏览节点、看数据类型、试订阅。很多人只拿它当测试工具其实它最大的价值是「反推参数」——你在 UaExpert 里连上服务端看它协商出来的PublishingInterval、SamplingInterval、安全策略直接抄到 C# 代码里比看文档快得多。具体做法在 UaExpert 里连上 AB 的 OPC UA 端点展开 Address Space找到目标标签右键「Monitor」加订阅。然后在 Subscription 面板里看它实际用的参数。如果 UaExpert 能稳定收到数据说明服务端和网络没问题C# 收不到就是代码参数的事。另一个技巧是把连接配置抽成 JSON别硬编码在代码里。产线换 PLC、换 IP 是常事配置化能省很多重新编译的功夫。{ opc: { endpoint: opc.tcp://192.168.1.10:4840, useSecurity: false, publishingInterval: 1000, samplingInterval: 500, tags: [ { name: Start, nodeId: ns2;sPLC1.Tag_Start }, { name: Speed, nodeId: ns2;sPLC1.Tag_Speed } ] } }逻辑说明endpoint和nodeId是最容易变的两项抽出来改配置就行。publishingInterval和samplingInterval按现场网络质量调网络差就放大。tags数组方便批量建订阅。验证方法上我习惯做三步先用 UaExpert 确认服务端正常再用一个最小 C# 控制台程序只读一个点位最后才上完整业务逻辑。这样出问题时能快速定位是哪一层。从那以后我每次接新 PLC都强制走一遍「UaExpert → 最小控制台 → 业务代码」的流程再没出现过整晚查 DCOM 的血泪经验。希望帮到你。本文还有配套的精品资源点击获取