简介这是一份面向工业自动化与.NET开发者的OPC客户端C#完整源码适合希望掌握OPC通信编程、从零搭建上位机数据采集程序的初中级开发者。资源围绕OPC服务器连接、数据浏览、读写订阅、事件通知、异常处理与线程安全等核心环节展开并涉及UI集成与调试思路可作为理解OPC .NET API实际用法的参考范例。压缩包共3个文件以xml配置与关系描述文件为主另有rels关系文件整体约1.52MB体量轻便便于快速解压查阅项目结构与配置信息。目前已有156人学习下载说明其在同类学习资料中具备一定参考价值。读者可借此梳理OPC客户端从建立连接到数据交互的完整逻辑理解配置与关系文件在项目中的作用并对照源码学习多线程同步、错误恢复与实时监控的实现方式为后续开发或调试工业数据采集应用提供可复用的思路。1. OPC 客户端到底在解决什么问题从一次产线数据对接翻车说起产线数据采不上来十有八九不是网络问题而是 OPC 客户端这一层没写对。很多做上位机、MES 对接、设备数据采集的开发者第一次接触 OPC 时都会遇到同一个场景现场有 PLC、DCS、称重仪表、扫码枪厂商说“支持 OPC”但真到自己写代码去读要么连不上要么读出来全是Bad质量码要么跑两天就断线。OPC 客户端C# 完整源码这个标题讲的正是用 C# 把 OPC 服务端的数据稳定读进自己系统这件事。它适合三类人一是做工业上位机、需要把设备数据落到数据库的开发者二是做 MES、SCADA、能源管理需要从多个 OPC Server 汇聚点位的工程师三是手里已经有一份源码但跑不通、读不到值、不知道怎么改的人。核心要解决的不是“能不能连”而是“连上之后怎么稳定读、批量读、断线自愈、质量码怎么判”。下面按选型、连接、读写、订阅、避坑、进阶的顺序把一份能落地的 C# OPC 客户端讲透。2. 选型先定死DA、UA 还是 AEC# 里各用什么库动手写代码之前选型错了后面全是白干。OPC 不是单一协议常见的有 OPC DA经典基于 COM/DCOM、OPC UA跨平台基于 TCP/HTTPS、OPC AE报警与事件。标题里没写具体哪一种但工业现场存量最大、C# 源码最常见的还是 OPC DA其次是 OPC UA。这一章先把选型理由和依赖库讲清楚再给最小连接代码。2.1 OPC DA 与 OPC UA 的取舍现场存量决定技术栈OPC DA 诞生早大量老 PLC、老 DCS、老仪表只支持 DA它的通信依赖 Windows 的 COM/DCOM 机制。这意味着你的 C# 客户端必须跑在 Windows 上而且客户端和服务端之间的 DCOM 配置极其容易出问题——这是后面避坑章节的重点。优点是生态成熟C# 里用OpcNetApi、OpcNetApi.Com这类封装库几行代码就能连上。OPC UA 是后来者不依赖 DCOM跨平台自带安全策略和证书支持复杂数据类型和订阅。C# 里主流用OPCFoundation.NetStandard.Opc.Ua官方栈或者Workstation.UaClient这类轻量封装。如果你的现场设备新、要跨平台、要上云优先 UA如果对接的是十年前的老系统DA 跑不掉。判断方法很简单拿到服务端的 ProgID 或 URL。形如Kepware.KEPServerEX.V6、Matrikon.OPC.Simulation的是 DA形如opc.tcp://127.0.0.1:4840的是 UA。选型定错后面代码全要重写。2.2 用 OpcNetApi 连 OPC DA 的最小可运行代码下面这段是 DA 客户端连接和读单个点位的最小骨架用OpcNetApi.Com实现。注意OpcNetApi有多个分支版本选OpcNetApi.Com才能走 DCOM 连远程 DA Server。using Opc.Da; using System; class OpcDaClientDemo { public static void Main() { // 服务端 ProgID现场换成实际注册的 ProgID string progId Matrikon.OPC.Simulation.1; // 远程时填服务端 IP本机测试用 localhost string host 127.0.0.1; // 创建工厂Url 指向目标机器 OpcCom.Factory factory new OpcCom.Factory(); Opc.URL url new Opc.URL($opcda://{host}/{progId}); // 连接第二个参数 true 表示保持连接 Server server new Server(factory, url, null); server.Connect(); // 构造要读的点位ItemName 必须和服务端地址空间完全一致 Item item new Item { ItemName Random.Real8 }; ItemValueResult[] results server.Read(new Item[] { item }); foreach (var r in results) { // 质量码和质量时间戳是判断数据可信的关键 Console.WriteLine($值{r.Value} 质量{r.Quality} 时间{r.Timestamp}); } server.Disconnect(); } }逻辑说明OpcCom.Factory是 DA 的 COM 工厂Opc.URL的格式是opcda://主机/ProgID这是 DA 寻址的固定写法。server.Connect()触发 DCOM 握手这一步失败基本就是 DCOM 或权限问题。Read返回的是ItemValueResult数组里面Value是值Quality是质量码Timestamp是服务端时间戳。参数说明progId必须和服务端注册表里HKEY_CLASSES_ROOT下的 ProgID 完全一致大小写敏感host本机测试用127.0.0.1远程填 IP但远程必须两端都配 DCOMItemName是服务端地址空间里的路径不是随便起的名字写错会返回Bad而不是抛异常这点最容易骗人。2.3 用官方 UA 栈连 OPC UA 的最小可运行代码UA 的写法完全不同走的是会话和订阅模型。下面用OPCFoundation.NetStandard.Opc.Ua连一个 UA Server 并读一个节点。using Opc.Ua; using Opc.Ua.Client; using System; using System.Threading.Tasks; class OpcUaClientDemo { public static async Task Main() { // 端点地址UA 用 opc.tcp 协议 string endpointUrl opc.tcp://127.0.0.1:4840; // 使用无安全策略做本地测试生产必须换成 SignAndEncrypt var endpointDescription CoreClientUtils.SelectEndpoint(endpointUrl, useSecurity: false); var endpointConfiguration EndpointConfiguration.Create(); var endpoint new ConfiguredEndpoint(null, endpointDescription, endpointConfiguration); // 建立会话 var session await Session.Create( configuration: null, endpoint: endpoint, updateBeforeConnect: false, sessionName: CSharpOpcUaClient, sessionTimeout: 60000, identity: new UserIdentity(), preferredLocales: null); // 构造读请求NodeId 是 UA 的寻址方式 var readValueId new ReadValueId { NodeId new NodeId(ns2;sDemo.Static.Scalar.Double), AttributeId Attributes.Value }; var response session.Read(null, 0, TimestampsToReturn.Both, new[] { readValueId }); foreach (var dv in response.Results) { Console.WriteLine($值{dv.Value} 状态{dv.StatusCode} 时间{dv.SourceTimestamp}); } await session.CloseAsync(); } }逻辑说明UA 先通过SelectEndpoint拿到端点描述再创建Session。Read请求里NodeId是核心格式ns命名空间索引;s字符串标识或ns2;i数字标识。StatusCode对应 DA 的质量码Good才是有效数据。参数说明useSecurity: false只用于本地调试生产环境必须开安全策略并配证书否则很多 UA Server 直接拒绝sessionTimeout单位毫秒太小会频繁掉线一般 60000 起NodeId的命名空间索引ns2不是固定的要用 UA 客户端工具浏览地址空间确认。3. 把读写做扎实批量读、写值、订阅三种模式的落地连上只是第一步真正决定客户端好不好用的是读写模式。单点轮询在点位数上百之后性能会崩必须上批量读和订阅。这一章把三种模式的代码和参数讲清楚。3.1 批量读一次请求读上百个点位DA 的Read支持传数组UA 的Read也支持多ReadValueId。批量读的关键是把点位分组每组控制在服务端单次请求上限内常见 500 左右具体看服务端。// DA 批量读把点位按 200 个一组切分 var allItems new ListItem(); foreach (var tag in tagList) // tagList 是配置里的点位名集合 { allItems.Add(new Item { ItemName tag }); } int batchSize 200; for (int i 0; i allItems.Count; i batchSize) { var batch allItems.Skip(i).Take(batchSize).ToArray(); ItemValueResult[] results server.Read(batch); foreach (var r in results) { // 只有 Good 才入库Bad 要单独记录排查 if (r.Quality Quality.Good) SaveToDb(r.ItemName, r.Value, r.Timestamp); else LogBadQuality(r.ItemName, r.Quality); } }逻辑说明Skip/Take做分片避免单次请求过大导致服务端超时。质量码判断是重点Quality.Good才写库Bad要单独落日志否则数据库里会混入大量无效值。参数说明batchSize不是越大越好200 是常见稳妥值点位多、网络差就降到 50r.Quality是枚举除了Good还有Bad、UncertainUncertain表示值可能过期是否入库看业务容忍度。3.2 写值写之前先确认点位可写写值比读值危险写错点位可能触发设备动作。DA 用WriteUA 用WriteRequest写之前最好先读一次确认点位存在且可写。// DA 写值先构造 ItemValue再调用 Write var writeValue new ItemValue(new Item { ItemName Demo.SetPoint }); writeValue.Value 42.5; IdentifiedResult[] writeResults server.Write(new ItemValue[] { writeValue }); foreach (var wr in writeResults) { // ResultID 为 S_OK 才算写成功 if (wr.ResultID ! ResultID.S_OK) Console.WriteLine($写入失败: {wr.ItemName} 错误{wr.ResultID}); }逻辑说明ItemValue同时携带点位和值Write返回IdentifiedResult通过ResultID判断成败。写失败常见原因是点位只读、类型不匹配、权限不足。参数说明writeValue.Value的类型必须和服务端点位定义一致写double点位传int可能被拒ResultID是 COM 的 HRESULT 封装S_OK是成功其他值要查对应错误码。3.3 订阅让服务端主动推数据而不是你轮询订阅是 OPC 的精髓服务端数据变化时主动通知客户端省掉轮询开销。DA 用SubscriptionSubscriptionCallbackUA 用SubscriptionMonitoredItem。// DA 订阅100ms 扫描周期变化超过 0.1 才上报 var subscription new Subscription(server, new SubscriptionState()); subscription.State.UpdateRate 100; // 毫秒 subscription.State.Deadband 0.1f; // 死区抑制微小波动 subscription.AddItems(new Item[] { new Item { ItemName Random.Real8 }, new Item { ItemName Random.Int4 } }); // 数据变化回调 subscription.DataChanged (handle, request, values) { foreach (ItemValueResult v in values) { Console.WriteLine($变化: {v.ItemName}{v.Value} 质量{v.Quality}); } }; subscription.ModifyState((int)StateMask.Active, new SubscriptionState { Active true });逻辑说明UpdateRate是服务端扫描周期Deadband是死区只有变化量超过死区才上报能大幅降低回调频率。DataChanged是异步回调里面不要做耗时操作否则会阻塞后续通知。参数说明UpdateRate设太小如 10ms会压垮服务端一般 100~1000msDeadband对模拟量有用对开关量无效回调里建议只做入队落库交给独立线程。4. 避坑与排查DCOM、质量码、断线这三类问题怎么定位OPC 客户端的坑高度集中在三处DA 的 DCOM 配置、质量码误判、长时间运行断线。这一章按「现象 → 原因 → 解决」逐条讲都是血泪经验。4.1 现象本机能连远程连不上报 0x80070005原因这是 DCOM 权限问题不是代码问题。DA 走 DCOM客户端和服务端两端都要配。常见缺失是服务端 DCOM 没给客户端账号启动和访问权限或者防火墙挡了 135 端口和动态端口。解决两端都运行dcomcnfg在「组件服务 → 计算机 → 我的电脑 → DCOM 配置」里找到对应 OPC Server 的 ProgID设置「身份验证级别」为「无」或「连接」「位置」勾选「在下列计算机上运行」并填服务端 IP。安全选项卡里给客户端运行账号加「本地启动」「本地激活」「远程启动」「远程激活」权限。防火墙放行 135 和 DCOM 动态端口范围。改完重启服务端 OPC Server 和客户端机器。4.2 现象读出来全是 Bad但服务端工具里看是好的原因ItemName写错、命名空间索引不对、或者读的时机太早。DA 的ItemName必须和服务端地址空间完全一致多一个空格都返回Bad。UA 的NodeId里ns索引不是固定的不同服务端不一样。解决先用服务端自带的客户端工具或第三方浏览工具把点位路径原样复制出来不要手敲。UA 用浏览功能确认ns索引。读的时机上Connect之后不要立刻读等 200~500ms 让会话稳定。批量读时如果部分Bad先单独读那一个点位确认路径。4.3 现象跑几小时或几天后断线重连失败原因DCOM 连接有超时和回收机制长时间空闲会被服务端或系统回收UA 会话有sessionTimeout超时后不重连就废了。另外网络抖动、服务端重启都会导致断线。解决加心跳和重连。DA 定时如 30 秒读一个固定点位做心跳失败就Disconnect再Connect重连要带退避别死循环。UA 监听Session.KeepAlive事件断线后重建Session。重连逻辑要幂等避免重复订阅。// DA 心跳 重连骨架 private void Heartbeat() { try { var r server.Read(new[] { new Item { ItemName Random.Real8 } }); if (r[0].Quality Quality.Bad) throw new Exception(心跳质量异常); } catch { // 退避重连避免频繁冲击服务端 Thread.Sleep(3000); try { server.Disconnect(); } catch { } server.Connect(); RebuildSubscriptions(); // 重连后必须重建订阅 } }逻辑说明心跳读一个稳定点位质量异常或抛异常就触发重连。重连前先Disconnect释放旧连接重连后必须重建订阅否则订阅句柄失效。参数说明心跳间隔 30 秒较稳妥太短增加服务端负担退避时间 3 秒起连续失败可递增到 30 秒RebuildSubscriptions要清空旧订阅再新建避免句柄泄漏。4.4 现象订阅回调里落库跑一段时间内存暴涨原因回调是服务端推送线程触发的在回调里做数据库写入、文件 IO 等耗时操作会阻塞推送线程消息堆积导致内存上涨。解决回调里只把数据放进ConcurrentQueue另起消费线程批量落库。队列要设上限满了丢弃并计数避免无界增长。4.5 现象UA 开了安全策略后连不上报证书错误原因UA 的安全策略要求客户端和服务端互相信任证书。客户端证书没被服务端信任或服务端证书没被客户端信任都会握手失败。解决把客户端证书导出导入服务端的信任列表把服务端证书导入客户端的信任列表。开发阶段可临时用useSecurity: false生产必须配好证书否则数据裸奔。5. 进阶把客户端做成能长期跑的服务几个关键技巧前面把连接、读写、订阅、避坑都过了一遍最后落到一个具体问题怎么让这份 C# OPC 客户端从「能跑」变成「能长期跑」。我自己的习惯是把客户端做成 Windows 服务或后台常驻进程配合配置化点位、健康检查和优雅退出。先说配置化。点位不要写死在代码里用 JSON 或数据库存字段至少包含ItemName、DataType、Group、Enable、Deadband。启动时按Group分组建订阅改点位不用重新编译。下面是一个配置结构示例。{ server: { type: DA, progId: Matrikon.OPC.Simulation.1, host: 127.0.0.1, heartbeatIntervalMs: 30000 }, tags: [ { itemName: Random.Real8, dataType: double, group: fast, enable: true, deadband: 0.1 }, { itemName: Random.Int4, dataType: int, group: slow, enable: true, deadband: 0 } ] }逻辑说明server段描述连接方式tags段是点位清单。group用来分组订阅fast组用 100ms 扫描slow组用 1000ms避免所有点位一个周期。enable控制启停deadband按点位单独设。参数说明heartbeatIntervalMs和订阅扫描周期分开心跳是连接健康检查订阅是数据推送dataType用于写值时的类型校验读值时可做转换deadband对开关量设 0对模拟量按量程的 0.1%~1% 设。再说健康检查。除了心跳还要监控订阅回调频率、队列长度、落库失败数。回调频率突然归零说明订阅断了队列持续增长说明消费跟不上。这些指标暴露出来问题能在用户投诉前发现。最后是优雅退出。进程退出前要Disconnect、关闭订阅、把队列里剩余数据落库。直接杀进程会导致订阅句柄残留服务端可能一段时间内拒绝重连。用Console.CancelKeyPress或服务的OnStop做清理。我踩过最深的一个坑是早期把重连逻辑写成while(true)死循环服务端一挂客户端疯狂重连把服务端打得更起不来。后来改成指数退避并且重连前先探测服务端端口才稳下来。另一个习惯是任何Bad质量码都落日志哪怕不入库因为质量码是现场问题的第一手线索丢了就成黑匣子了。这套东西值不值得做如果你的系统要对接多个厂商设备、要长期无人值守跑值得。把连接、订阅、重连、配置化这四块做扎实后面接多少种设备都是套模板。希望帮到你。本文还有配套的精品资源点击获取