我在车间里被问得最多的一个问题就是怎么用C#把PLC里的数据读出来显示到电脑屏幕上。标准答案五花八门有说串口的有说Modbus TCP的还有说直接抓PLC内存区的。但要说通用性最强、省心程度最高的一种方式我还是首推OPC通讯。这篇博文就围绕“C#上位机连接PLC的通用OPC通讯方式源码及学习资料”这个主题把我这些年做上位机集成时积累的OPC通讯经验、源码、踩坑记录全部整理出来给正在做上位机开发、或者打算入门的兄弟一个可以直接照抄的参考。先说清楚这篇东西适合谁看你手头有一台或者多台PLC西门子、三菱、欧姆龙都行你想在PC上用C#写个上位机去读写PLC数据但你不想为每一款PLC都单独学一套通讯协议或者你就是想知道OPC DA和OPC UA到底怎么选、代码怎么写、环境怎么配。看完这篇至少你能独立跑通一个“C#上位机 OPC PLC”的最小Demo并且知道后续怎么扩展。1. 为什么是OPC上位机与PLC通讯的选型逻辑1.1 常见的通讯方式对比上位机和PLC之间的通讯历史上经历过好几个阶段。我见过不少项目还在用最原始的方式用串口线直接连PLC的编程口然后按照PLC厂商的私有协议一个字节一个字节地拼报文。好处是零成本坏处是——换一个PLC型号代码基本重写。后来流行起Modbus它至少算是个半公开的协议。Modbus RTU走串口Modbus TCP走以太网很多PLC尤其是第三方设备都支持。你直接发功能码、寄存器地址就能读写数据。这个方案在简单场景下确实好用我现在做小型项目时也常会直接撸一个Modbus TCP客户端几十行代码就能搞定单台设备的读写。但当你面对的情况是“车间里有20台PLC型号还各不相同上位机要把所有数据汇总到一个SCADA系统里”Modbus就有局限了你得为每一款PLC单独做一套驱动处理各自的字节序、数据类型、地址映射规则。这个时候OPC的价值就出来了。OPC的全称是OLE for Process Control早期是基于Windows的COM/DCOM技术实现的它把不同厂商的PLC统一成了一个标准的接口模型。OPC服务器负责和底层PLC通讯OPC客户端也就是你的C#上位机程序只跟OPC服务器对接。这样一来你的上位机代码只需要面向OPC标准接口编写至于底下是西门子还是三菱跟你没关系。这就是“通用”二字的真正含义一次编写到处对接。1.2 OPC DA与OPC UA怎么选选型是避不开的第一个问题。市面上你能接触到的OPC协议主要是OPC DA和OPC UA两代外加可能遇到的OPC HDA历史数据。OPC DA是基于Windows COM/DCOM的古老技术诞生于90年代末。它的优点是很成熟大量老设备、老系统还在用缺点是出了名的难配置。DCOM需要设置很多安全权限而且只能跑在Windows平台上跨不了网段防火墙一开就各种连不上。我早期做项目时光配DCOM权限就能耗掉半天。OPC UAUnified Architecture统一架构是后出的标准它彻底抛弃了COM/DCOM改用基于TCP/IP的二进制协议也可以走HTTPS跨平台、内置加密认证、信息模型更丰富。最关键是很多新款PLC比如西门子S7-1200/S7-1500、倍福、欧姆龙NJ系列本身就能直接做OPC UA服务器电脑上连额外的OPC服务器软件都不用装。我给你的选型建议很直接场景推荐方案全厂MES/SCADA系统集成数据点几百上千个OPC UA优先老产线改造PLC较老已有OPC DA服务器如Kepware、SIMATIC NETOPC DA但考虑用网关转换升级新上项目PLC支持OPC UA无脑用OPC UA数据要跨网段、跨平台比如传到云服务器OPC UA既然本文标题写的是“通用OPC通讯方式”我会把OPC DA和OPC UA两条路都讲清楚因为现实项目中它们俩你都会遇到。2. 环境准备先把地基打好2.1 需要安装的核心组件在写代码之前先把运行环境梳理清楚。很多新手连不上服务器其实是环境装漏了。我们分两套来说。走OPC DA路线电脑上需要装的东西有OPC Core Components Redistributable也就是OPC核心组件运行库。这是OPC基金会提供的运行库里面包含了OPC DA Automation接口需要的dll。常见版本有2.0、3.0还有带.x64后缀的64位版本。注意这个库分为“OPC Core Components Redistributable (x86)”和“(x64)”两种如果你的上位机是64位程序但OPC服务器是32位的就会遇到一个很经典的系统兼容性问题后面我会细讲。OPC服务器软件。比如Kepware现在叫KEPServerEX、西门子SIMATIC NET、或者Matrikon OPC Simulation Server。新手练习时强烈推荐装一个仿真服务器比如Matrikon OPC Simulation它不仅自带模拟数据还能模拟各种错误状态是调试上位机的好工具。Visual Studio用来写代码和编译。走OPC UA路线环境准备就简单得多。你几乎不用在系统层面装任何OPC运行库只需要在Visual Studio里通过NuGet引用OPC Foundation提供的官方库即可。若PLC自带OPC UA服务器或者你用UaExpert等仿真器电脑端装个能跑代码的.NET环境就行。2.2 DCOM权限配置OPC DA的必经之坑如果你走的是OPC DA路线DCOM配置这一关是躲不掉的。这是一个让无数人血压升高的环节但我可以帮你理清步骤确保少踩坑。在Windows上按WinR输入dcomcnfg回车打开组件服务。然后依次展开“组件服务 - 计算机 - 我的电脑 - DCOM配置”在列表里找到你用的OPC服务器组件。常见的有OpcEnumOPC枚举器负责在网络里找可用的OPC服务器。Matrikon OPC Simulation.1如果你装了Matrikon仿真。Kepware.KEPServerEX.V6Kepware服务器。右键这些组件进入属性在“安全”选项卡下把启动和激活权限、访问权限、配置权限都改成“自定义”然后添加用户交互式用户、NETWORK SERVICE、Administrators确保你的当前账号在Administrators组里权限都设为“允许”。还有一处容易被忽略在“我的电脑”上右键 - 属性 - “COM安全”选项卡里同样要给上述用户开放“启动和激活权限”和“访问权限”。这一步不做客户端连接时十有八九会报“拒绝访问(0x80070005)”。提示如果是两台电脑通过网络访问OPC服务器还涉及Windows防火墙放行135端口和DCOM动态端口默认动态分配的规则以及“分布式 COM”的网络访问权限。这一步建议在调试的时候可以把两台机器的防火墙先临时关闭仅限内网测试环境等确认功能正常再逐步收紧防火墙规则。说实话DCOM配置牵扯到系统登录方式、组策略等细节不同Windows版本界面差异还大这也是我强烈建议新项目直接走OPC UA的最重要原因——OPC UA把DCOM这一套折磨人的配置彻底干掉了。3. C#源码实现一条龙搞定OPC DA与UA3.1 准备阶段NuGet包与引用先解决“引什么库”的问题。这步做对了后面的代码就是按部就班。OPC DA的C#方案常见有两种使用OPC Foundation官方的OpcDaClient库在NuGet上可以搜到版本较老。使用OPCAutomation接口也就是在VS里添加对Interop.OPCAutomation.dll的引用。这个dll在你安装OPC Core Components时就会生成在系统中。第二种我用得比较多代码比较简单易读示例多。下面会基于它讲解。OPC UA的C#方案推荐直接用OPC Foundation官方库OPCFoundation.NetStandard.Opc.Ua核心库。OPCFoundation.NetStandard.Opc.Ua.Client客户端库。OPCFoundation.NetStandard.Opc.Ua.Configuration配置管理库。在VS里用NuGet包管理器搜索OPCFoundation安装这三个包即可。它们支持.NET Framework 4.6.1和.NET Core/.NET 5用起来很顺手。未来如果是全新项目我的建议是不折腾直接OPC UA。接下来两套代码我都给出来你按需取用。3.2 OPC DA方式核心源码以OPCAutomation接口为例实现一个最简单的“连接服务器 - 读取一个点位数据”的控制台程序。using System; using OPCAutomation; class OpcDaDemo { static void Main(string[] args) { // 1. 创建OPC服务器对象 OPCServer opcServer new OPCServer(); // 2. 连接到本机的OPC服务器 // 连接前可以先用 GetOPCServers 枚举本机或远程主机上可用的服务器 // 这里以Matrikon仿真服务器为例 opcServer.Connect(Matrikon.OPC.Simulation); Console.WriteLine(已连接OPC服务器: opcServer.ServerName); Console.WriteLine(服务器版本: opcServer.MajorVersion . opcServer.MinorVersion); // 3. 添加一个组 OPCGroup opcGroup opcServer.OPCGroups.Add(OpcGroup1); // 4. 在组中添加一个标签项这里使用仿真服务器的随机数标签 // 注意不同OPC服务器的标签路径不同可以在UaExpert或服务器自带的客户端里查 OPCItem opcItem opcGroup.OPCItems.AddItem(Random.Int1, 1); // 5. 同步读取 object value null; object quality null; object timestamp null; opcItem.Read((short)OPCDataSource.OPCDevice, out value, out quality, out timestamp); Console.WriteLine(标签值: value); Console.WriteLine(质量: quality); Console.WriteLine(时间戳: timestamp); // 6. 清理 opcGroup.OPCItems.RemoveItem(1); opcServer.OPCGroups.Remove(OpcGroup1); opcServer.Disconnect(); } }这段代码逻辑很直白连上服务器、建组、建Item、Read一把。你运行后会看到输出一个随机整数。如果是连真实PLC只要把服务器名和Item路径换成实际的即可。Item路径一般在OPC服务器配置里能看到比如西门子S7-300通过Kepware暴露的标签可能是Channel1.Device1.DB1.FLOAT0这种格式。3.3 OPC UA方式核心源码再给一套OPC UA的示例这是当前及未来的主流方式。以下代码基于OPC Foundation官方库创建一个会话Session读取节点信息演示读写操作。using System; using System.Threading.Tasks; using Opc.Ua; using Opc.Ua.Configuration; using Opc.Ua.Client; class OpcUaDemo { public static async Task Main(string[] args) { // 1. 创建应用的配置信息 var application new ApplicationInstance { ApplicationName CsharpOpcUaClient, ApplicationType ApplicationType.Client }; // 2. 加载或创建应用配置默认会生成一个证书 var config await application.LoadApplicationConfiguration(OpcUaClientConfig.xml, silent: false); // 3. 检查并更新证书 await application.CheckApplicationInstanceCertificates(false, 0); // 4. 创建UAClient对象封装了Session管理 var uaClient new UAClient(); uaClient.Connect(opc.tcp://127.0.0.1:4840); // 5. 读取一个节点 var nodeId new NodeId(ns2;sSimulation/Random, 2); var value uaClient.ReadValue(nodeId); Console.WriteLine($读取到值: {value}); // 6. 写入一个节点 // 注意可写节点取决于OPC服务器地址空间定义 uaClient.WriteValue(new NodeId(ns2;sSimulation/WriteValue, 2), 123); // 7. 断开 uaClient.Disconnect(); } }这里我用了UAClient这样一个封装好的类是官方示例库中的标准做法。OpcUaClient内部通过Session与服务器交互代码比OPC DA的看起来“啰嗦”其实是因为OPC UA把安全、证书、会话管理都显式地暴露出来了。这样的设计虽然提升了一点使用门槛但是一旦跑通稳定性远超OPC DA。官方仓库里有一个完整的UAClient实现建议直接去GitHub搜UA-.NETStandard找到SampleApplications下的UAClient示例读一遍它的源码你会对OPC UA客户端模型有非常清晰的认识。3.4 一个更省事的封装思路如果只是做简单的上位机代码可以稍微封装一下。我自己的习惯是写一个OpcHelper类把连接、读取、写入、订阅的代码各包成一个方法这样界面层只需要调用一两行代码就能完成数据交换。这个封装思路大致是public class OpcUaHelper { private Session _session; private ApplicationConfiguration _configuration; public bool Connect(string endpointUrl, string userName null, string password null) { // 创建配置、加载证书、建立Session // 支持匿名连接和用户名密码认证 } public DataValue ReadNode(string nodeId) { // 根据字符串NodeId构造NodeId对象 // 调用_session.ReadValue } public void WriteNode(string nodeId, object value) { // 根据字符串NodeId写入 } public void SubscribeNode(string nodeId, int samplingInterval, ActionDataValue callback) { // 创建Subscription注册MonitoredItem回调通知 } }封装成Helper类后你的WinForm/WPF界面里只需要写var helper new OpcUaHelper(); helper.Connect(opc.tcp://192.168.1.10:4840); var temp helper.ReadNode(ns2;sDB1.Temperature); helper.SubscribeNode(ns2;sDB1.Temperature, 1000, value this.BeginInvoke(new Action(() label1.Text value.ToString())));这一下就把复杂度隔离了。项目真正要维护的只有点位映射表NodeId列表和业务逻辑。4. 实操过程从零到读到一个真实PLC点位4.1 连接前的检查清单代码写好了但在点“运行”之前有一个检查清单建议逐条过一遍能帮你省掉大量无意义的调试时间。检查项具体操作网络连通性ping一下PLC或OPC服务器的IP确认物理链路通OPC服务器状态服务器软件是否已启动授权是否过期点位路径标签路径是否真实存在能不能在服务器自带的Quick Client里读到值证书信任OPC UA模式下客户端和服务器是否已互相信任证书用户权限OPC UA用户名密码是否正确匿名访问是否开放防火墙规则135端口、4840端口是否放行这个清单是我无数次现场调试总结出来的60%以上的连接失败都可以归结到“网络不通、点位写错、证书不信任”这三类问题上剩下的才需要靠抓包分析。4.2 最小Demo跑通流程假设我们现在要连接一台西门子S7-1500 PLC它自带的OPC UA服务器已经启用电脑和PLC用网线直连PLC的IP是192.168.0.1OPC UA服务器端口默认4840。第一步在PLC侧TIA Portal或者面板上确认OPC UA服务器已激活并建好一个DB块里面有变量TemperatureReal类型。记下它的DB块编号和偏移量比如DB1偏移0。OPC UA节点的NodeId通常可以写成ns3;sDB1.Temperature之类的形式具体命名空间索引ns的值要看你PLC的OPC UA服务器定义可以在UaExpert里浏览地址空间确认。第二步在UaExpertOPC UA的免费调试客户端工具里连接一下opc.tcp://192.168.0.1:4840确认能读到DB1.Temperature的值。这一步意义重大它把问题域缩小到了“服务器是否有数据”这一层等UaExpert能读到值了再上我们自己的C#代码。第三步用上面第三节的OPC UA客户端的代码把EndpointUrl换成opc.tcp://192.168.0.1:4840把NodeId换成实际节点运行控制台打印出温度值。至此你的C#上位机与PLC的OPC通讯就走通了。4.3 数据订阅别用定时器轮询新手最容易犯的错就是一拍脑袋写个Timer每隔几百毫秒去读一次点。这在点位少的时候没什么问题点位一多比如100个以上效率立刻拉胯还会给PLC和网络带来不必要的负载。OPC协议本身是支持**订阅Subscription**机制的客户端订阅某个点位后服务器会在数据变化时主动推送过来或者按你设置的采周期周期性地推送。这样一来网络流量和CPU占用都会大幅降低数据实时性还更好。以OPC UA为例订阅的核心代码在UAClient里封装为// 创建订阅 var subscription new Subscription(_session) { PublishingInterval 1000, // 发布周期毫秒 }; // 在订阅中注册监视项 var monitoredItem new MonitoredItem(subscription.DefaultItem) { StartNodeId nodeId, SamplingInterval 500, // 采样周期 QueueSize 1, DiscardOldest true, }; // 数据变化时的回调 monitoredItem.Notification OnDataChanged; subscription.AddItem(monitoredItem); _session.AddSubscription(subscription); subscription.Create();private void OnDataChanged(MonitoredItem monitoredItem, MonitoredItemNotificationEventArgs e) { var notification (MonitoredItemNotification)e.NotificationValue; Console.WriteLine($节点 {monitoredItem.StartNodeId} 新值为: {notification.Value.WrappedValue}); }如果你是做WinForm/WPF界面刷新记得在回调里用Invoke/BeginInvoke回到UI线程再更新控件直接跨线程更新控件会抛异常。5. 踩坑实录常见问题与排查技巧5.1 连接失败的几大元凶这些年遇到的连接问题我总结成一个速查表你可以直接照着排查报错信息或现象根本原因解决办法0x80070005 拒绝访问DCOM权限不足常见于OPC DA检查dcomcnfg中的启动/访问权限添加用户并允许0x80004005 未指定错误OPCServer名称写错、服务器未运行确认服务器ProgID用OpcEnum枚举一下找不到OPC服务器OPCEnum服务未启动、32/64位不匹配启动OpcEnum服务统一32位或64位程序与dllBadCertificateUntrustedOPC UA证书不被信任把客户端证书导入服务器信任列表反之亦然BadNodeIdUnknownNodeId写错节点不存在在UaExpert里浏览确认正确NodeId连接超时网络不通、防火墙拦截、端口错误ping测试检查防火墙确认端口暂时关闭防火墙测试64位程序连不上32位OPC DA服务器系统注册表重定向问题让程序以x86模式编译或者把OPC服务器也换成64位版本5.2 我印象最深的一个DCOM坑有一次实施现场设备厂商给了一台工控机预装的OPC DA服务器是32位的我自己写的上位机在开发机上跑得好好的拷过去怎么都连不上报0x80070005。搞了很久最后发现是Windows系统的“分布式COM”默认权限策略在作怪而且这台工控机是Windows Server系统系统默认的匿名访问限制比普通Win10严格得多。解决办法是在dcomcnfg的“我的电脑”属性 - “COM安全”选项卡里把“启动和激活权限”和“访问权限”的默认限制都改一下加入当前运行上位机的账户并给予“本地启动”“本地激活”“本地访问”权限。这里强调一个细节你要改的是“默认限制”和“用户限制”两处而不仅仅是单个组件的自定义权限。把这步做完问题才真正解决。5.3 关于32位和64位的老问题OPC DA很多工业软件只提供32位版本比如某些老的Kepware驱动、老的SIMATIC NET。这时候如果你的C#上位机编译成了AnyCPU或者x64调用32位的COM组件是会出问题的。表现是编译通过运行时new OPCServer()就抛CLSID没有注册之类的异常。解决办法有三条路可选把C#项目平台目标改成x86和32位OPC服务器匹配。简单粗暴绝大多数场景有效。用OPC UA网关比如Kepware本身也支持UA或单独部署UA网关软件把DA数据转换成UA接口你的程序走UA访问。找64位版本的原生OPC DA服务器很多大厂已经提供了新版本。最省事的是方法1但缺点是你整个上位机程序都只能是32位将来内存用量大时会受限。所以现在我在新项目里只要设备支持一定用OPC UA这套问题直接从根上消失。5.4 证书信任的常见误区OPC UA的安全机制是好事但在调试期也容易让人抓狂。最常见的情况是你的客户端程序第一次连接服务器服务器发来一个证书客户端弹窗提示“是否信任”如果你点了“否”之后每次连接都会被拒。实际项目里两个方向都要处理客户端要信任服务器证书服务器也要信任客户端证书。通过ApplicationInstance.CheckApplicationInstanceCertificates会自动生成并注册客户端证书然后你需要把客户端证书导出来放到PLC或UA服务器信任的证书目录里。西门子S7-1500的OPC UA服务器信任列表是在TIA Portal或者PLC的面板里管理的。如果只是调试可以直接在连接前把服务器的证书校验模式设为Noneconfig.SecurityConfiguration.ServerCertificateValidator new CertificateValidator(); config.CertificateValidator.TrustedIssuerCertificates.StoreType CertificateStoreType.Directory;或者更粗暴一点在建立Session时把SecurityMessageMode设为None、SecurityPolicyUri设为None也就是匿名不加密连接。这个做法只推荐在封闭的工厂内网调试时使用生产环境强烈建议开启安全模式。6. 学习资料与进阶路线6.1 值得收藏的官方资料聊完实操说点学习资料的推荐。很多人问我“OPC要怎么学”我给的建议其实很朴素先看官方示例代码再上手跑一个Demo最后才是啃规范文档。OPC UA的官方GitHub仓库是OPCFoundation/UA-.NETStandard里面不仅有核心库源码还有完备的客户端、服务器示例。我建议你重点看SampleApplications/Workshop包含了一个最简单的客户端和服务器示例很适合入门。SampleApplications/UAClient更完整的客户端支持浏览地址空间、读写、订阅是写上位机的好参考。Stack/Opc.Ua.Core核心协议栈实现想看底层的从这里看。另外OPC基金会的官网opcfoundation.org有大量技术白皮书特别是那本《OPC Unified Architecture》规范虽然是厚厚一本但不用全读只看Part 1概述、Part 3地址空间模型、Part 4服务就够了。新手直接啃规范容易劝退建议先跑代码回头再看规范查漏补缺。6.2 上手练习的路线图我给新人的练习路线是这样安排的第一阶段用Matrikon OPC Simulation Server或者UaExpert仿真器在本地跑通OPC DA的读取、写入。Roslyn修修复就算了。这个阶段只求“能连上、能读到值”不用管具体PLC。第二阶段找一个支持OPC UA的PLC西门子S7-1500、1200或者倍福、欧姆龙都行用UaExpert浏览它的地址空间手动读写一两个点位把PLC侧的安全证书配置搞清楚。第三阶段用C#写一个最小客户端连上你刚才用UaExpert测过的PLC完成读写。第四阶段做一个小WinForm/WPF界面显示几个实时数据加上报警变化记录。到这里一个最基础的上位机框架就搭起来了。第五阶段参考官方UAClient代码自己封装一个OpcUaHelper类集成到正式项目里加上日志、断线重连、点位配置化等功能。这套路线我亲自带过几个人基本两到四周能走完。前提是别跳步特别是前两个阶段不能省那是建立“点位到底是什么”这种感觉的关键时期。6.3 C#上位机开发的其他学习建议最后顺带说一点OPC通讯只是上位机开发里的一环真正完整的上位机系统还包括数据存储SQLite/SQL Server/时序数据库、界面交互WPF绑定、多线程刷新、通讯可靠性心跳、断线重连、数据缓存等。C#基础要扎实尤其是委托、事件、多线程、async/await这些它们直接决定了你写上位机时界面卡不卡、数据刷新时灵不灵。很多新手在订阅回调里写UI控件不是报错就是界面假死根源就是对线程模型不熟悉。学习资料方面C#入门推荐《C#高级编程》和微软官方文档learn.microsoft.com看官方教程比看二手博客效率高得多。上位机相关的专项书市面上有《C#上位机开发实战指南》之类质量参差不齐我的建议是先把官方示例啃透比买十本书都强。我个人在实际操作中还有一个习惯每接触一个新协议或新设备先花一下午的时间把官方示例跑起来再动手改代码。不要一上来就想直接开发完整的上位机那样遇到问题你会分不清是环境问题、协议问题还是代码问题。“示例代码能跑通”本身就是一条极好的分界线它能帮你把问题隔离开来。7. 两个补充技巧调试利器与项目扩展建议调试OPC通讯光靠写代码打日志是很低效的。我日常调试工具箱里有两个利器一个是前面反复提到的UaExpert它不仅是OPC UA的测试客户端也可以浏览服务器地址空间查看节点的元数据、读写属性、订阅数据基本是OPC UA开发者的必备工具。另一个是Wireshark抓包工具当你怀疑OPC UA通讯层面的问题时用opcua过滤规则抓包能直观看到握手、证书协商、读请求/响应、订阅发布的整个过程。我曾经排查过一个“订阅偶尔断流”的问题靠抓包才发现是服务器端发布间隔设置太小导致网络拥塞后来把发布间隔从100毫秒调到500毫秒就稳定了。在项目扩展上如果你觉得纯OPC UA的学习成本还是有点高也可以考虑用一些现成的组态软件如Ignition、WinCC等作为OPC UA客户端直接对接PLC然后通过它们的接口把数据暴露给你的C#程序。不过这样一来你就引入了第三方依赖和“自己写上位机”的初衷不同适合对开发周期要求极端的项目。还有一个很多人在问的扩展方向如果PLC不支持OPC UA只有Modbus TCP怎么办。这时候不必强上OPC UAC#里直接用EasyModbus或者自己封装一个Modbus TCP客户端读写寄存器就行。很多情况下Modbus TCP配合PLC的MODBUS TCP服务器功能块已经能覆盖90%的数据采集需求。OPC和前文讲的Modbus并不是二选一的对立关系它们是可以共存的底层数据源用Modbus采集上层数据汇聚用OPC UA做标准接口这样既兼容老设备又满足了新系统的标准化需求。8. 最后说几句实在话做上位机开发这行表面上是写代码实际上拼的是对通讯本质的理解和排查问题的耐心。OPC这套东西说难不难说简单也不简单难点其实不在协议本身而在于行业里积累了太多老系统的历史包袱DCOM权限、32/64位混用、各家服务器的地址空间命名风格不同。你把这些坑一个个趟过去再有新项目就会觉得“不过如此”。我用OPC DA和OPC UA做过不少项目回头来看最大的感悟就是别跟技术草较劲能用新标准就用新标准。如果你手头完全没有历史包袱直接学OPC UA省下来的时间去做点业务逻辑或者学学波形报表不香吗。这篇帖子把C#上位机连接PLC的OPC通讯从选型、环境、代码到排查讲了一遍源码部分也给出了可以跑通的最小示例。你要是照着做一遍还卡在某个环节大概率是我上面那个检查清单里的某一项网络、点位、证书、权限四个里面必有其一。祝调试顺利。