简介这份资源面向工业自动化方向的C#开发者尤其是希望入门或落地OPC通信的初学者与中级工程师。包内提供一套可直接在Visual Studio中打开的OPC客户端源码配合OPCDAAuto.dll与OpcRcw运行时通信组件帮助读者理解如何建立OPC连接、访问服务器数据项、处理读写订阅与异常解决从零搭建OPC DA客户端时缺少可运行范例的问题。压缩包共43个文件约239KB以cs源码、exe可执行程序、dll动态库、pdb调试符号、resources与resx资源文件、config配置及sln解决方案为主另含少量txt说明与zip组件包结构完整便于对照调试。目前已有774人学习下载。通过研读源码与库文件调用方式读者可掌握OPC客户端实现原理、.NET与COM交互的代理类生成思路并借助测试通过的示例快速验证与OPC服务器的通信为后续SCADA或PLC数据采集项目打下实践基础。1. 从一份 OPC 客户端源码说起C# 怎么和产线 PLC 说上话车间里一台西门子 S7-1200 跑着产线节拍上位机要每 500ms 读一次当前产量和报警字你打开 Visual Studio 新建了一个 WinForm 工程引用列表里翻到OPCDAAuto.dll然后卡住了——这个 COM 组件到底怎么调OPCItemMgt、IOPCSyncIO这些接口名看着眼熟写起来全是坑。这份「OPC客户端源码.rar」标题里塞了五个关键词OPC、OPCDAAuto.dll、OPC编程、opc c#、opc client 源码本质上说的是一件事——用 C# 通过 OPC DA 协议把 PLC 里的实时数据读到上位机。它解决的是工控现场最朴素的需求设备运行状态、传感器数值、数控机床的加工计数这些数据锁在 PLC 的寄存器里OPC 就是那把标准钥匙。适合谁看做 MES 对接、SCADA 组态、设备数据采集的 C# 开发者尤其是手里已经有一份 OPC 客户端源码但读不懂、跑不通、连不上的那批人。下面我按「先搞懂 DA 和 UA 怎么选、再把 OPCDAAuto.dll 调通、最后把源码拆开改」的顺序讲一遍。2. OPC DA 与 OPCDAAuto.dll选型理由和 COM 调用原理2.1 为什么老设备还在用 OPC DA而不是直接上 OPC UA先说结论如果你对接的是西门子 S7-200/300/400、施耐德 Premium、三菱 FX 系列这类老 PLC或者现场已经跑着 Schneider Electric OPC Factory Server 这类 DA 服务器那 OPC DA 是绕不开的。OPC DA 基于 Windows COM/DCOM1996 年出的规范数据访问模型简单——服务器暴露一批 Item客户端订阅或同步读写值带时间戳和质量码。它的优势是生态成熟几乎所有组态软件和 PLC 厂商都提供 DA 服务器劣势也明显DCOM 配置玄学、跨机器访问要开一堆权限、不支持跨平台。OPC UA 是 2008 年后的新一代规范独立于 COM支持跨平台、自带安全模型、信息建模能力强。现在新项目我一般直接上 UA但现实是大量存量设备只有 DA 服务器。所以常见做法是老设备用 DA 采集在新旧交界处用 DA 转 UA 网关做一层封装上位机统一走 UA。这份源码标题里出现的是OPCDAAuto.dll说明它走的是 DA 路线下面所有内容都围绕 DA 展开UA 只在选型对比时提一句。OPCDAAuto.dll是什么它是 OPC 基金会提供的一个 Automation Wrapper把底层复杂的 COM 接口IOPCServer、IOPCItemMgt、IOPCSyncIO、IOPCDataCallback等包装成一套 IDispatch 自动化接口让 VB6、C#、Delphi 这类支持 COM 自动化的语言能直接调用。没有它你得手动CoCreateInstance再QueryInterface一层层拿接口指针代码量翻三倍。有了它OPCServer、OPCGroups、OPCItems这些对象直接new出来就能用。2.2 在 C# 里引用 OPCDAAuto.dll 的两种方式第一种是「引用 COM 组件」。在 Visual Studio 里右键项目 → 添加引用 → COM → 找到OPC DA Automation Wrapper 2.02VS 会自动生成Interop.OPCDAAuto.dll互操作程序集。这种方式的问题是目标机器必须注册过OPCDAAuto.dll否则运行时报Class not registered0x80040154。第二种是「直接引用 Interop 程序集」。把生成好的Interop.OPCDAAuto.dll拷到项目 lib 目录添加引用指向它同时把OPCDAAuto.dll本身也拷到输出目录。部署时用regsvr32 OPCDAAuto.dll注册一次。我一般用第二种因为可控。# 注册 OPCDAAuto.dll需要管理员权限的 cmd regsvr32 C:\Windows\SysWOW64\OPCDAAuto.dll # 如果是 64 位系统跑 32 位程序注意 dll 要放对目录 # 32 位程序用 SysWOW64 下的64 位程序用 System32 下的这里有个血泪经验OPCDAAuto.dll分 32 位和 64 位两个版本你的 C# 程序编译目标平台必须和 dll 位数一致。WinForm 默认 AnyCPU在 64 位系统上跑成 64 位进程去调 32 位的 dll 直接报错。解决办法是把项目属性里的「目标平台」改成 x86或者用 64 位版本的 dll。现场调试时这个坑能卡你半天因为报错信息只有一句「检索 COM 类工厂中 CLSID 为 {...} 的组件失败」。2.3 OPC DA 的数据访问模型Server、Group、Item 三层结构理解这三层结构是读懂源码的前提。OPCServer代表一个 OPC 服务器实例比如Schneider-Aut.OFS.2或Siemens.OPCServer。OPCGroups是服务器下的组集合每个OPCGroup可以独立设置更新速率UpdateRate和死区Deadband。OPCItems是组下的数据项集合每个 Item 对应 PLC 里的一个地址比如S7:[S7 connection_1]DB1,INT0或PLC1.Device1.Tag1。为什么要分组因为不同数据的刷新频率需求不同。产量计数需要 100ms 刷一次而设备温度 5 秒刷一次就够了。把不同频率的 Item 分到不同 Group可以避免高频组拖垮低频组的通信负载。源码里如果只有一个 Group 包打天下那是个可以优化的点。// OPC DA 三层结构的典型创建流程 OPCServer server new OPCServer(); server.Connect(Schneider-Aut.OFS.2, 192.168.1.100); // 服务器 ProgID 和节点 OPCGroups groups server.OPCGroups; groups.DefaultGroupUpdateRate 500; // 默认组刷新率 500ms OPCGroup group groups.Add(); // 添加一个组 group.UpdateRate 200; // 这个组 200ms 刷一次 group.IsActive true; // 激活组不激活不回调 OPCItems items group.OPCItems; OPCItem item items.AddItem(PLC1.Tag1, 1); // 添加一个 ItemClientHandle1逻辑说明Connect的第一个参数是 OPC 服务器的 ProgID这个值在注册表HKEY_CLASSES_ROOT下能查到或者用 OPC 客户端工具枚举出来。第二个参数是节点名本机可以传空字符串或机器名远程传 IP。AddItem的第二个参数是 ClientHandle是客户端自己维护的句柄回调时靠它识别是哪个 Item 的数据必须唯一。参数怎么改UpdateRate单位是毫秒设太小比如 10ms服务器可能不支持实际会按服务器能力降级IsActive必须设 true否则订阅了也不推数据这个坑新手常踩。3. 用 C# 把 OPC 客户端源码跑通从连接、订阅到读写的完整步骤3.1 连接 OPC 服务器并枚举可用 ProgID第一步不是写代码是确认现场 OPC 服务器叫什么。用 Matrikon OPC Explorer 或 Kepware 自带的客户端工具连一下能看到 ProgID 列表。代码里也可以枚举本机已注册的 OPC 服务器// 枚举本机所有 OPC DA 服务器 ProgID OPCServer server new OPCServer(); object progIDs server.GetOPCServers(); // 返回 object 数组 foreach (string progID in (Array)progIDs) { Console.WriteLine(progID); // 例如 Schneider-Aut.OFS.2 }逻辑说明GetOPCServers()不带参数枚举本机传节点名枚举远程。拿到 ProgID 后传给Connect。注意远程连接时 DCOM 权限是拦路虎常见做法是在两台机器上建同名同密码的账户然后在组件服务dcomcnfg里给OPCEnum和 OPC 服务器设置访问权限。这一步翻车率极高建议先在本地跑通再折腾远程。3.2 添加 Item 并建立数据订阅连接成功后核心工作是添加 Item 和建立订阅。同步读适合低频、按需读取订阅回调适合高频、实时刷新。源码里两种模式通常都有你要根据场景选。// 建立订阅注册 DataChange 事件回调 group.DataChange new DIOPCGroupEvent_DataChangeEventHandler(OnDataChange); group.IsSubscribed true; // 开启订阅必须设 true // 回调函数服务器数据变化时触发 private void OnDataChange(int TransactionID, int NumItems, ref Array ClientHandles, ref Array ItemValues, ref Array Qualities, ref Array TimeStamps) { for (int i 1; i NumItems; i) // 注意OPC DA 数组从 1 开始 { int handle (int)ClientHandles.GetValue(i); object value ItemValues.GetValue(i); short quality (short)Qualities.GetValue(i); DateTime ts (DateTime)TimeStamps.GetValue(i); // quality 192 (0xC0) 表示 Good Console.WriteLine($Handle{handle} Value{value} Quality{quality} Time{ts}); } }逻辑说明IsSubscribed必须设 true否则回调不触发这是最常见的「订阅了没反应」原因。回调参数里的数组索引从 1 开始不是 0用GetValue(0)会抛异常。Quality是 short 类型192 表示 Good0 表示 Bad64 表示 Uncertain判断数据有效性必须看这个字段不能只看 Value。参数怎么改UpdateRate和Deadband共同决定回调频率Deadband 是死区值变化超过死区才回调设 0 表示任何变化都回调。3.3 同步读写与异步写入的代码差异同步读适合配置参数、配方数据这类低频操作代码简单直接// 同步读一次读多个 Item Array serverHandles new int[] { 0, item1.ServerHandle, item2.ServerHandle }; Array values, errors; group.SyncRead((short)OPCDATASOURCE.OPC_DS_CACHE, 2, ref serverHandles, out values, out errors, out qualities, out timestamps); // values[1] 对应 item1values[2] 对应 item2逻辑说明OPC_DS_CACHE读缓存速度快但可能不是最新值OPC_DS_DEVICE直接读设备慢但实时。serverHandles数组第一个元素是占位因为 OPC DA 数组从 1 开始。写入用SyncWrite参数类似。异步写入用BeginWriteWriteComplete事件适合不阻塞 UI 的场景。我一般读用同步、写用异步避免写操作卡住界面。3.4 把源码里的硬编码地址改成可配置大部分 OPC 客户端源码把 Item ID 硬编码在代码里换个项目就得改代码重编译。正确做法是抽到配置文件!-- app.config 里的 Item 配置 -- appSettings add keyOpcProgID valueSchneider-Aut.OFS.2/ add keyOpcNode value192.168.1.100/ add keyItemList valuePLC1.Tag1,PLC1.Tag2,PLC1.Tag3/ add keyUpdateRate value500/ /appSettings// 读取配置并批量添加 Item string[] tags ConfigurationManager.AppSettings[ItemList].Split(,); foreach (string tag in tags) { items.AddItem(tag, clientHandle); // clientHandle 从 1 递增 }逻辑说明Item ID 的格式取决于 OPC 服务器施耐德 OFS 用PLC1.Tag1这种西门子用S7:[连接名]DB1,INT0这种。配置化之后现场调试只需要改配置文件不用重新编译。参数怎么改UpdateRate从配置读不同项目可以调ItemList用逗号分隔注意 Item ID 本身可能含逗号比如西门子的地址格式那就得换分隔符。4. OPC 客户端开发避坑DCOM、位数、质量码与内存泄漏4.1 坑一Class not registered0x80040154现象程序在本机跑得好好的拷到现场机器上new OPCServer()直接抛异常错误码 0x80040154。原因目标机器没注册OPCDAAuto.dll或者注册的位数和程序不匹配。32 位程序在 64 位系统上会去SysWOW64找如果 dll 只注册到了System32就找不到。解决确认程序目标平台用对应位数的regsvr32注册。注册时用管理员权限的 cmd路径写全。注册完在注册表HKEY_CLASSES_ROOT\OPC.Automation下能看到对应项。如果还不行检查是否装了 OPC Core Components Redistributable有些环境缺这个基础包。4.2 坑二远程连接报「拒绝访问」0x80070005现象本地连 OPC 服务器正常换成远程 IP 就报拒绝访问。原因DCOM 权限没配。OPC DA 走 DCOM默认只允许本机访问。解决三步走。第一两台机器建同名同密码的账户都用这个账户登录。第二在服务器机器上打开 dcomcnfg组件服务 → 计算机 → 我的电脑 → DCOM 配置找到 OPC 服务器对应的项设置「身份验证级别」为「无」「位置」勾选「在数据所在计算机上运行」「安全」里给 Everyone 或指定账户「本地访问」「远程访问」权限。第三防火墙放行 135 端口和 DCOM 动态端口范围。这套配置玄学成分大配不通就退回本地采集 网络转发。4.3 坑三订阅回调不触发现象DataChange事件注册了IsSubscribed也设了 true但回调就是不进来。原因常见三种。一是IsActive没设 true组没激活二是UpdateRate设得比服务器支持的最小值还小服务器忽略了三是 Item 的地址写错了服务器返回 Bad 质量但不报错。解决先检查IsActive和IsSubscribed两个布尔值。再把UpdateRate调到 1000ms 试。最后用同步读验证 Item 地址是否正确如果同步读返回 Bad说明地址本身有问题。质量码 192 是 Good0 是 Bad64 是 Uncertain回调里先判断质量码再处理值。4.4 坑四长时间运行内存持续增长现象程序跑几天后内存从几十兆涨到几百兆最后卡死。原因COM 对象没释放。OPCServer、OPCGroup、OPCItem都是 COM 对象用完必须ReleaseComObject否则引用计数不归零内存泄漏。解决在程序退出或重连时按 Item → Group → Server 的顺序释放// 释放 COM 对象的正确顺序 if (items ! null) { Marshal.ReleaseComObject(items); items null; } if (group ! null) { Marshal.ReleaseComObject(group); group null; } if (server ! null) { server.Disconnect(); Marshal.ReleaseComObject(server); server null; } GC.Collect(); // 强制回收配合 ReleaseComObject 使用逻辑说明ReleaseComObject每次调用减一引用计数必须和创建次数匹配。Disconnect先断开连接再释放。GC.Collect不是必须但在频繁重连场景下能加速回收。注意不要在回调里释放对象会死锁。4.5 坑五Item ID 格式因服务器而异现象同一份代码连施耐德服务器能读到数据连西门子服务器全是 Bad。原因不同 OPC 服务器的 Item ID 命名规则不同。施耐德 OFS 用PLC1.Tag1西门子用S7:[S7 connection_1]DB1,INT0Kepware 用Channel1.Device1.Tag1。解决没有通用格式必须查对应服务器的文档或用客户端工具浏览地址空间。代码里把 Item ID 配置化不要硬编码。调试时先用同步读验证单个 Item确认格式对了再批量加。5. 从 DA 到 UA 的平滑迁移与源码改造技巧5.1 什么时候该把 DA 客户端改成 UA如果你的项目满足以下任意一条建议考虑迁移到 OPC UA需要跨平台部署Linux 上位机、需要跨网段/跨防火墙通信、需要信息建模不只是读值还要读结构、新采购的 PLC 原生支持 UA。反过来如果现场全是老设备、只在 Windows 内网跑、只读几个寄存器值那 DA 够用迁移成本不划算。迁移的常见做法不是重写而是在中间加一层。用OPC DA 转 UA 网关比如 Kepware、Prosys、开源的 open62541 配合 DA 包装把 DA 服务器暴露成 UA 端点上位机代码从调OPCDAAuto.dll改成调 UA SDK。这样老设备不用动新代码走 UA过渡平滑。5.2 用 UA SDK 替换 OPCDAAuto.dll 的代码对照以 OPC Foundation 的 .NET Standard UA SDK 为例读一个节点的代码和 DA 差异很大// OPC UA 读取节点对比 DA 的 SyncRead var endpoint new Uri(opc.tcp://192.168.1.100:4840); var session await Session.Create(config, endpoint, false, , 60000, null, null); var readValue new ReadValueId { NodeId new NodeId(ns2;sPLC1.Tag1), AttributeId Attributes.Value }; DataValueCollection results await session.ReadAsync(null, 0, TimestampsToReturn.Both, new ReadValueIdCollection { readValue }); Console.WriteLine(results[0].Value); // 值 Console.WriteLine(results[0].StatusCode); // 质量码Good/Bad 语义类似逻辑说明UA 的NodeId用命名空间索引 标识符比 DA 的字符串地址规范。StatusCode对应 DA 的 QualityGood 表示有效。UA 原生支持异步await写法比 DA 的回调更直观。参数怎么改endpoint是 UA 服务器地址默认端口 4840session超时 60000ms 可按网络质量调。5.3 源码改造的验证方法用模拟服务器做回归改完代码怎么验证不要直接连现场 PLC风险高。用 OPC 模拟服务器做回归测试。Kepware 自带模拟驱动或者用开源的OPC DA Simulator。模拟服务器里建几个 Item值随机变化质量码可切换 Good/Bad用来测试你的客户端在各种边界条件下的表现。验证清单连接成功、枚举 ProgID、添加 Item、同步读、订阅回调、质量码判断、断线重连、COM 释放。每一项都过一遍再上现场。我一般还会写一个简单的压力测试模拟 1000 个 Item 同时订阅看内存和 CPU 占用提前发现性能瓶颈。5.4 一个具体技巧用 ClientHandle 做数据路由源码里常见的问题是回调里用 Item ID 字符串匹配来分发数据效率低且容易出错。正确做法是用ClientHandle做路由。添加 Item 时给每个 Item 分配唯一整数句柄回调里直接拿句柄查字典// 用字典做 ClientHandle 到业务逻辑的映射 private Dictionaryint, Actionobject, short handleMap new Dictionaryint, Actionobject, short(); // 添加 Item 时注册 int handle clientHandle; handleMap[handle] (value, quality) { if (quality 192) { /* 更新 UI 或写数据库 */ } }; items.AddItem(tag, handle); // 回调里直接分发 private void OnDataChange(...) { for (int i 1; i NumItems; i) { int h (int)ClientHandles.GetValue(i); if (handleMap.TryGetValue(h, out var action)) action(ItemValues.GetValue(i), (short)Qualities.GetValue(i)); } }逻辑说明ClientHandle是客户端自己维护的服务器只负责原样回传所以可以自由分配。用字典映射比字符串匹配快一个数量级而且解耦了 Item ID 和业务逻辑。参数怎么改handleMap的值可以是任意委托读值、写库、推消息队列都行。这个技巧我在多个项目里用过回调分发从几百行 switch 缩到十几行。最后说个习惯每次改完 OPC 客户端代码我都会先在模拟服务器上跑一遍断线重连——手动禁用网卡再启用看程序能不能自动恢复订阅。现场网络抖动是常态没有重连机制的客户端上线就是定时炸弹。这个习惯帮我省了至少三次半夜被叫去现场的麻烦。希望帮到你。本文还有配套的精品资源点击获取