简介这是一套C#通过OPC连接PLC读写数据的完整实例源码由工控老马出品面向工控领域入门及进阶开发者解决上位机与PLC之间通过OPC协议进行实时数据交互与读写的核心需求。程序包含带精美实用界面的可运行客户端涵盖工程搭建、配置文件与关键实现代码可直观了解整体通讯流程。压缩包共30个文件以6个cs源码文件、2个exe可执行程序为主体辅以dll、resources资源文件、png界面截图、sln/csproj工程文件及doc说明文档总大小1.19MB结构紧凑且便于对照学习。已有848人学习使用。资源价值在于不仅提供了可直接运行的客户端exe程序还附带软件界面截图与Word文档说明读者可据此快速理解C#连接OPC服务器的通讯流程、读写数据的具体实现方式并将其应用到实际PLC项目中。适合新手按文档逐步搭建环境也适合有经验者直接借鉴代码框架进行二次开发。1. 先弄清楚C#上位机连PLC为什么绕不开OPC做了几年C#上位机最常被问到的一个问题是上位机读PLC数据为什么不能直接用PLC的驱动非要绕一圈走OPC真到现场就明白了——产线控制层往往已经有了一台OPC Server在跑不管是西门子Simatic NET、Kepware还是组态王PLC里的变量已经被统一采集到了一个OPC空间里。这时候C#要读写PLC数据与其绕过OPC去写S7或Modbus驱动不如顺着OPC客户端这条路走。本文说的“OPC通讯实例”就是这么一回事C#作为OPC客户端通过OPC DA或OPC UA协议连上Server再间接读写PLC变量。适合做设备监控、MES数据采集、产线信息化上位机的开发者。重点不是协议背得多熟而是能跑通、能稳定跑、坏了知道去哪查。2. 选型先于编码OPC DA还是OPC UA两代协议的差异与选型判断2.1 OPC DA老产线最常见DCOM依赖是第一个坑很多老产线的数据采集系统是十年前甚至更早搭的打开控制柜一看PLC的通讯模块或者工控机上跑着一个OPC Server变量以“通道.设备.标签”的形式暴露出来。这种场景下C#上位机要做的事情很简单把自己做成OPC DA客户端连上Server然后读写Server暴露的标签。OPC DA也叫OPC Classic底层依赖COM/DCOMWindows平台上自带支持但它有两个天生问题第一DCOM配置非常敏感权限、身份、防火墙稍有不对远程连接就失败这块在全国各地现场坑过无数人第二它只能走WindowsLinux和跨平台场景基本用不了工厂想上物联网平台时往往被卡在这。从通讯模型上看OPC DA的核心是三层结构OPCServer、OPCGroup、OPCItem。Server代表一个OPC服务器实例Group是数据采集的容器Item对应一个PLC变量标签。理解这个结构对后面写代码很重要因为C#连接时的所有操作都围绕这三个对象展开。OPC DA最大的优点是兼容性极好老设备控制系统里几乎都有它的身影最大的缺点是安全模型薄弱通讯数据没有加密身份校验依赖Windows的DCOM配置换一台机器就能让你在配置上耗掉半天。选型上的判断标准是如果OPC Server就在本机或者同一域内的Windows机器上且产线已经稳定运行多年用OPC DA是改动最小的方案如果要把数据传到不同网段的服务器或者新写一套系统OPC DA会逼着你花大量时间在处理“连接不上”而不是业务逻辑上。2.2 OPC UA跨平台、加密、信息模型新项目首选OPC UA是新一代标准彻底摆脱了DCOM基于TCP或HTTPS传输自带加密和证书认证还定义了比DA丰富得多的信息模型。从C#开发者的角度看OPC UA最大的好处是不需要在操作系统里做任何DCOM配置用一个NuGet包就能把客户端写出来开发体验接近写一个HTTP客户端。现在西门子S7-1500、倍福、汇川、台达等主流PLC都直接带OPC UA Server不再需要额外的OPC Server软件哪怕是老一些的设备也可能通过固件更新支持了UA。OPC UA另一个很实用的特点是“自描述”——客户端可以在线浏览服务器里的节点树看到有哪些变量、什么类型、什么单位。这在调试阶段非常省事我用UAExpert这个客户端工具扫一遍现场服务器变量路径直接抄下来就能写进代码不用找电气工程师问半天“变量到底叫什么名字”。相比之下OPC DA的标签路径完全靠工程师手动维护文档多一个点少一个点都容易出问题。安全性上OPC UA默认支持证书校验和消息签名虽然首次配置证书也有一点学习成本但比DCOM那种“权限怎么配都玄学”的体验好得多。新项目只要PLC支不支持UA都应该优先考虑UA方案。2.3 针对标题场景的选型建议我把常见场景列了一张对比表方便直接判断。现场情况推荐协议理由老产线已有OPC Server只做数据采集OPC DA改动最小服务器端不动新项目PLC自带OPC UA ServerOPC UA免DCOM、免中间软件、更安全跨平台或跨网段部署C#服务OPC UA摆脱Windows COM依赖不确定PLC支持情况先查型号和固件主流新型号基本都带UA如果现场既有老OPC Server又有新PLC常见做法是先用OPC UA把新设备接进来老的继续用DA中间在数据服务层做统一不要来回切换协议。协议选错后面写客户端代码都是白搭。这也是我后面两章分别给DA和UA代码的原因——两种协议在C#里的实现方式差别很大混着写会让项目越来越难维护。3. C#连接OPC DA读PLC最小可运行源码与参数拆解3.1 依赖准备引入OPCDAAuto.dll的两种方式OPC DA自动化接口最常见的组件是OPCDAAuto.dll一般由OPC基金会发布的OPC Core Components安装包提供很多OPC Server安装的时候也会顺手注册这个组件。第一种引入方式是在Visual Studio里添加COM引用项目右键“添加引用”选COM选项卡找到“OPC Automation 2.0”添加后系统会自动生成Interop.OPCAutomation.dll。第二种方式是运行时动态绑定用Type.GetTypeFromProgID(OPC.Automation)拿到类型再创建对象好处是不需要设计期引用坏处是没有智能提示调试时比较费劲。我一般建议用COM引用代码写起来直观后面排查类型转换问题也方便。如果安装OPC Server之后打开“组件服务”看到OPC.Automation没有注册可以在命令行里手动注册regsvr32 C:\Windows\SysWOW64\OPCDAAuto.dll逻辑说明这条命令把OPC自动化接口组件注册到Windows的COM目录里之后C#才能通过ProgID找到它。有些机器上是64位和32位两个版本需要注意项目平台目标选x86还是x64否则会报“找不到OPC.Automation”或“类未注册”。参数说明路径里的SysWOW64表示64位系统上存放32位组件的目录如果你的OPC Server是64位的组件可能注册在System32里以实际安装路径为准。注册时要用管理员权限打开命令行否则会提示写入注册表失败。3.2 建立连接与读取单个变量的核心代码先写一个最小的连接和读取流程目标是把一个标签的值读出来using OPCAutomation; // 1. 创建 OPC Server 对象 var server new OpcServer(); string progId Kepware.OPC.Server; // 按现场 OPC Server 实际 ProgID 填写 object host localhost; // 本机连接跨机器写 IP 或机器名 try { // 2. 建立连接这一步会触发 DCOM 安全检查 server.Connect(progId, host); Console.WriteLine($已连接到 {server.ServerName}); } catch (Exception ex) { Console.WriteLine($连接失败: {ex.Message}); return; } // 3. 在服务器下添加一个组 var group server.OPCGroups.Add(ReadGroup); group.UpdateRate 500; // 数据更新周期单位毫秒 group.IsActive true; group.IsSubscribed false; // 先用同步读 // 4. 在组里添加要读取的标签 string[] itemIds { Channel1.Device1.Tag1, Channel1.Device1.Tag2 }; var clientHandles new object[] { 1, 2 }; group.OPCItems.AddItems( itemIds.Length, ref itemIds[0], ref clientHandles[0], out Array serverHandles, out Array errors); // 5. 同步读取设备数据 group.SyncRead( (short)OPCDataSource.OPCDevice, out Array values, out Array qualities, out Array timestamps); // 6. 输出结果 for (int i 0; i values.Length; i) { Console.WriteLine($Tag: {itemIds[i]}, value{values.GetValue(i)}, quality{qualities.GetValue(i)}); }逻辑说明上面这段把OPC DA客户端的完整调用链走了一遍——连接Server、添加Group、添加Item、同步读值。之所以先加组再加项是因为OPC DA的读写粒度是“组”组决定了采样周期和订阅行为单个Item没有独立的读写周期。SyncRead的第一个参数OPCDataSource.OPCDevice表示强制从设备读如果换成OPCDataSource.OPCCache读出来的是服务器缓存可能不是最新值。参数说明ProgID必须和现场OPC Server保持一致常见的有Kepware.OPC.Server、Matrikon.OPC.Simulation.1、Siemens.SimaticNet.OpcServer等不确定时用UAExpert或其他OPC扫描工具确认。UpdateRate设为500毫秒适合大多数设备监控场景如果PLC通讯周期本身是1000毫秒设太小反而增加服务器压力设太大又会让数据看起来“卡顿”。这里特别提醒AddItems的调用方式。OPC DA Automation接口的AddItems要求传ref string和ref object所以必须先建好数组再传首元素引用。很多网上的旧代码写成直接传数组在VB.NET里能跑在C#里会编译报错或者运行时抛异常。这属于写OPC DA最容易踩的坑之一。3.3 批量读写与订阅把轮询改成事件驱动同步读适合“按一下读一次”的场景但做上位机监控界面时更希望数据一变就能通知我。OPC DA通过组的事件机制实现这一点本质上就是C#里的委托事件。把上面代码中IsSubscribed改成true再订阅DataChange事件即可group.IsSubscribed true; group.DataChange OnDataChange;对应的回调方法签名必须和组件定义的一致private void OnDataChange( int transactionID, int numItems, ref Array clientHandles, ref Array values, ref Array qualities, ref Array timestamps) { for (int i 0; i numItems; i) { int handle Convert.ToInt32(clientHandles.GetValue(i)); object value values.GetValue(i); Console.WriteLine($[Handler {handle}] value{value}); } }逻辑说明DataChange是OPC DA Automation接口定义的组级事件只要组内有任何Item的值发生变化服务器就会回调这个委托收到的是一个批次的变化数据。把clientHandles和values按索引对应就能定位到具体标签。注意这里必须用ref Array因为组件内部要复用这块内存去掉ref会导致签名不匹配或运行时错误。不同版本Interop生成的委托签名可能有细微差别以你项目里“对象浏览器”看到的签名为准。批量写的方式和读是对称的用SyncWrite一次写多个Itemobject[] writeValues new object[] { 12.5f, true }; group.SyncWrite( writeValues.Length, ref serverHandles, ref writeValues, out Array writeErrors);逻辑说明SyncWrite向组内所有Item写入数据serverHandles是加Item时返回的服务端句柄必须和写入顺序一一对应writeValues的类型要和PLC变量类型匹配写错会出现类型转换失败。参数说明写入的数据类型要特别小心。Bool类型在OPC DA里通常用short0或非0表示浮点用float或double整数用short/int/long类型对不上时不会立刻报错而是等到PLC侧解析出错误。所以上位机最好缓存一份“变量类型表”写入前先查类型再转换。4. C#连接OPC UA读PLC用OPCFoundation库打通现代OPC Server4.1 引入NuGet包与端点配置新项目的首选协议是OPC UAC#侧用得最多的是OPCFoundation开源的.NetStandard.Opc.Ua包。这个包同时包含客户端SDK和服务器SDK我们做客户端场景只需要引用其中一部分。安装方式Install-Package OPCFoundation.NetStandard.Opc.Ua逻辑说明这个NuGet包是OPC基金会官方维护的开源实现支持.NET Framework 4.6.1和.NET Core及以上版本。装上它之后连接OPC UA服务器需要先准备一份ApplicationConfiguration里面要声明应用名称、证书存储位置、信任策略和传输参数。这比OPC DA复杂但对安全是有意义的——UA默认要求双向证书信任服务器的证书要能被客户端验证客户端的证书也要让服务器接受。最少配置可以这样写var config new ApplicationConfiguration { ApplicationName MyCSharpOpcUaClient, ApplicationUri urn:MyCSharpOpcUaClient, SecurityConfiguration new SecurityConfiguration { ApplicationCertificate new CertificateIdentifier { StoreType Directory, StorePath ./pki, SubjectName CNMyCSharpOpcUaClient }, AutoAcceptUntrustedCertificates true }, TransportQuotas new TransportQuotas { OperationTimeout 10000 }, ClientConfiguration new ClientConfiguration { DefaultSessionTimeout 60000 } }; await config.ValidateAsync();逻辑说明ApplicationCertificate用于生成或加载客户端证书AutoAcceptUntrustedCertificates在开发阶段可以省去很多证书认证的麻烦但生产环境必须关闭否则服务器的安全策略会被轻易绕过。TransportQuotas里的OperationTimeout是单次请求的超时时间单位毫秒SessionTimeout是会话断开前的最大空闲时间。参数说明StorePath里的./pki是相对路径程序运行时会在这个目录下自动生成证书文件。如果服务器要求双向认证还需要把客户端证书导出并加入服务器的信任列表。用DirectoryStore是最简单的Windows上也可以改用X509Store类型但要注意不同操作系统下路径写法不同。4.2 读、写、浏览节点的最小代码配置准备好之后连接服务器并按节点读写的代码量比OPC DA还少var endpointUrl opc.tcp://192.168.0.10:4840; var endpoint new Uri(endpointUrl); // 建立会话最后一个参数null表示匿名登录 var session await Session.Create( config, endpoint, false, CSharpClient_Session, 60000, new UserIdentity(), null); // 读单个节点 var nodeId new NodeId(ns2;sChannel1.Device1.Tag1); DataValue dataValue session.ReadValue(nodeId); Console.WriteLine($value{dataValue.Value}, quality{dataValue.StatusCode}, ts{dataValue.SourceTimestamp}); // 写单个节点 var writeValue new WriteValue { NodeId nodeId, AttributeId Attributes.Value, Value new DataValue(new Variant(42)) }; var results await session.WriteAsync( new WriteValueCollection { writeValue }); if (results[0].Code StatusCodes.Good) { Console.WriteLine(写入成功); }逻辑说明Session.Create是建立OPC UA会话的标准入口内部自动完成端点选择、安全策略协商和握手。ReadValue是同步读底层走UA的Read服务WriteAsync是异步写返回的服务结果里Code等于StatusCodes.Good才表示写入被服务器接受。注意这里的“接受”只代表UA服务器成功接收不代表PLC侧一定执行成功PLC内部的错误要通过PLC本身的诊断去查。参数说明NodeId是UA世界里定位变量的核心常见的格式是ns2;sChannel1.Device1.Tag1。ns是命名空间索引由服务器的信息模型决定不能随便填s表示变量名是字符串格式也有i表示数字ID。不确定节点路径时用UAExpert客户端连上去浏览或者直接在代码里调用浏览接口枚举。浏览节点的最小写法var browser session.CreateBrowser(); browser.BrowseDescription.NodeId NodeId.ObjectsFolder; var refs browser.Browse(); foreach (var r in refs) { Console.WriteLine(${r.DisplayName} - {r.NodeId}); }逻辑说明Browser对象会从指定的NodeId开始向下枚举子节点把ObjectsFolder下面的对象和变量一层层展示出来。这段代码在对接陌生PLC时非常有用相当于程序自己“问”服务器有哪些可读可写的变量比翻手册找路径高效得多。4.3 数据变化订阅UA版的DataChangeUA订阅在结构上和DA类似也是创建订阅、添加监视项、触发回调但API更清晰var subscription new Subscription(session.DefaultSubscription) { PublishingInterval 500, // 发布周期毫秒 KeepAliveCount 10 }; session.AddSubscription(subscription); subscription.Create(); var monitoredItem new MonitoredItem { StartNodeId nodeId, AttributeId Attributes.Value, SamplingInterval 500, // 采样周期毫秒 QueueSize 1 // 每个通知只保留最新值 }; monitoredItem.Notification (_, e) { var val e.NotificationValue.Value; Console.WriteLine($DataChange: {val}); }; subscription.AddItem(monitoredItem); subscription.ApplyChanges();逻辑说明这里的核心概念是PublishingInterval和SamplingInterval两个周期。发布周期决定服务器多久推送一次通知采样周期决定服务器多久从PLC那边采一次值。这两个值配合不好要么通知太频繁拖垮网络要么数据变化延迟大。QueueSize设成1表示服务器只通知最新值避免积压一堆旧数据。参数说明如果PLC变量的正常变化频率在几百毫秒级两个周期都设500即可。对于快速变化的变量可以把SamplingInterval设到100毫秒PublishingInterval设成200毫秒但要确认PLC和网络负载扛得住否则订阅会变成整个系统的瓶颈。5. 避坑清单OPC通讯最常见的五个翻车现场5.1 远程连接OPC DA报“拒绝访问”现象OPC DA客户端在本机连接正常换到另一台机器连同样的Server就报“拒绝访问”或“服务器运行失败”有时干脆超时。原因OPC DA基于DCOM远程连接时Windows会对服务器进程做身份验证。最常见的情况是OPC Server进程是以某个用户身份启动的而客户端机器上的调用身份在服务器上没有权限其次是Windows防火墙拦截了DCOM的135端口和动态端口范围。解决在服务器上运行dcomcnfg定位到对应的OPC Server把“身份标识”设为“交互用户”或者指定一个有权限的服务账号在“安全”选项卡里给启动和访问权限加上Network Service账户再关闭防火墙或者给DCOM放行。这个过程极其烦琐也是我坚持新项目优先选OPC UA的原因。5.2 连接成功但读出来的值一直是Null或乱码现象SyncRead返回值是DBNull或某些字符串变量读出来是乱码。原因字符串变量在OPC DA自动化接口里返回的可能是BSTR或Variant类型如果C#项目平台目标x86/x64和OPC Server不一致会导致Variant封送失败值变成Null乱码一般是代码页不一致。解决确定现场OPC Server是32位还是64位把C#项目平台目标改成一致对字符串统一按Unicode处理读完整批数据后先检查quality是不是Good质量不佳的值直接丢弃不要参与业务计算。5.3 DataChange事件不触发或触发延迟严重现象IsSubscribed设了trueDataChange却一次都不回调偶尔回调延迟好几秒。原因Group的IsActive是false或UpdateRate和PLC的采集周期不匹配。有些老旧OPC Server要求IsSubscribed必须在AddItems之前设好否则组内的Item不会进入订阅状态。解决把Group.IsActive和Group.IsSubscribed都在AddItems之前设为trueUpdateRate设成PLC通讯周期的1/2到1倍之间如果还是不行在OPC Server上开诊断日志确认服务器到底在不在发布变化。5.4 写入成功但PLC侧没有任何动作现象SyncWrite返回成功上位机也不报错但现场设备没有任何反应。原因写入的变量路径是“通道.设备.变量”结构但OPC Server里有些变量是只读的写“成功”只是Server接收成功更常见的是类型不匹配比如PLC侧定义的是intC#这边写的是floatServer做了静默转换后PLC端解析失败。解决写之前先用SyncRead读一次目标变量确认类型在Server端把变量设置为可写写完后通过读同一个变量的值回验或者让PLC程序把收到的值写到另一个寄存器里回显。5.5 OPC UA首次连接证书不受信任现象用OPC UA客户端连服务器SDK抛“证书不受信任”或“安全性校验失败”的异常试了几次都进不去。原因OPC UA默认启用证书校验服务器的证书没有被客户端信任或者客户端的证书没有被服务器信任。很多开源的UA Server默认安全策略只接受受信任客户端。解决开发阶段把AutoAcceptUntrustedCertificates设为true生产环境把客户端的公钥证书导出登录到服务器上把它加入信任列表。注意Windows和Linux服务器放证书的位置不一样具体路径要看服务器配置。如果服务器那边是别人的系统最稳妥的是给他们提供客户端证书指纹让他们加到白名单里。6. 最后一层把OPC通讯封装成数据服务层换协议不用改UI把前面两章的最小代码跑通只是第一步。真正做上位机项目时UI、历史存储、报警逻辑都依赖数据层如果它们直接引用OPC对象后面换协议、换通讯方式会让整个项目返工。我的做法是加一层数据服务层对外暴露三个方法读、写、订阅内部再根据配置选OPC DA还是OPC UA。接口可以非常小public interface IPlcDataService { object Read(string tag); void Write(string tag, object value); void Subscribe(string tag, Actionstring, object onChanged); }OPC DA实现类只需要把第3章的代码套进这三个方法OPC UA实现类把第4章的代码套进去。UI只依赖接口不关心底层是DA还是UA。这个习惯让我在好几个项目里躲过了“现场突然把OPC Server换掉”这种事故——底层换协议上层代码一行都不用动。订阅方法里还有一个重要细节事件回调发生在底层通讯线程不是UI线程直接更新WPF或WinForm控件会抛跨线程异常。我一般会把onChanged回调包装成线程安全的事件再用SynchronizationContext切回UI线程这也算C#上位机的血泪经验了。要是当初只顾跑通Demo拿到现场做72小时稳定性测试大概率会翻车。数据服务层设计好之后还可以顺手把变量名映射表做成配置文件用“逻辑名→实际Tag”的方式替换硬编码的NodeId。现场调整Tag路径时不用改代码改一行配置重启就好。这个做法配合UAExpert在线浏览节点基本能应对九成以上“为什么值读不对”的排查需求。希望帮到你。本文还有配套的精品资源点击获取