简介：一套由工控老马出品的C# OPC通讯实例程序源码，专为工业自动化领域的开发人员及入门新手设计，解决C#客户端通过OPC服务器与PLC进行实时数据读写交互的实操难题。源码包含完整的Visual Studio解决方案，涵盖项目文件、窗体界面、核心业务逻辑及资源文件，界面精美且交互友好，可直接编译运行或按需改造。压缩包共计30个文件，主要类型包括6个cs源程序文件、3个exe可执行程序、1个DLL依赖库、2个PDB调试符号、2个PNG界面截图以及doc说明文档等，整体大小仅1.19MB，结构紧凑，便于携带与分发。目前已有848人浏览学习，适合希望快速掌握OPC客户端开发流程、理解服务器连接与数据读写机制的读者。通过源码可学习OPC客户端初始化、服务器连接配置、PLC数据点读写操作等关键实现细节，配合界面截图和文档对照，能显著降低学习门槛，是工业通信编程实战入门的优选参考资料。
1. OPC通讯实例是什么：C#通过OPC连接PLC读写数据，先解决"能不能通"再谈性能
看到标题里的“OPC通讯实例”，很多人第一反应是找现成源码抄。真正做过C#上位机的人会明白，这份“程序源码”值钱的不是那几行连接代码，而是后面一连串协议选择和环境配置。OPC在工控里的角色是“中间人”：PLC侧是西门子、三菱、汇川这些私有协议，上位机侧是C#、Java各种语言，OPC服务器负责把两头翻译成一个统一接口。这个标题的核心，就是用C#写一个OPC客户端，把PLC里的温度、转速、标志位读进内存，也能把设定值写下去。适合谁？做C#上位机、SCADA二次开发，或者实验室里想用PLC做数据采集的工程师。先别急着抄代码，把OPC DA和OPC UA的差异搞清楚，这程序才跑得起来。
2. C#上位机用OPC DA还是OPC UA：先搞清COM/DCOM和证书这两件事
OPC不是一份库，是一套协议体系。标题里的“OPC通讯实例”落到C#代码面前，实际有两条路线：老牌的OPC DA和新一代的OPC UA。很多刚开始做C#上位机的人，习惯从网上拷一段OPCDAAuto互操作代码，把工程平台改成x86，折腾半天接上了；换一台电脑再接，又连不上，就开始怀疑是玄学。其实不是玄学，是DCOM权限、位数、账号配置没对齐。另一个极端是一上来就引OPC UA的NuGet包，结果被证书认证和ApplicationConfiguration配置折腾到怀疑人生。所以第一步不是写代码，是把项目该走哪条路线定下来。
2.1 OPC DA：COM/DCOM老协议，好用但“挑机器”
OPC DA诞生时的定位是把OLE for Process Control做成Windows上的统一接口。PLC侧的S7协议、三菱MC协议、Modbus TCP，都被各自的OPC Server翻译成“组+项”模型。C#客户端要做的，就是连上这台OPC Server，把项读出来。这个模型对上位机来说非常友好：你不用关心PLC品牌，只关心服务器ProgID和项名称，比如Channel1.Device1.Tag1，连上就能读写。
坑通常在环境而不是代码。OPC DA基于COM/DCOM，跨机器访问需要配DCOM权限。本地连接时相对省心，一旦要让几台电脑里的C#客户端去读同一台OPC服务器，就得到服务器上给用户或匿名账号开权限，配置错一环，客户端就报“拒绝访问”。另一个坑是位数：COM组件分32位和64位，OPCDAAuto.dll这类传统互操作库在x64进程里调用经常抛异常，所以我一般要求组态工程把客户端也编成x86。听起来落伍，但存量工厂里这种系统非常多，新项目我很少再选这块。
2.2 OPC UA：跨平台、证书加密、地址空间建模
OPC UA常被说成OPC DA的升级版，更准确的说法是一次重写。它不再依赖COM/DCOM，改用TCP二进制协议，默认端口4840，也可以映射到HTTPS。服务器和客户端都能跑在Linux上，C#这边有OPC基金会维护的.NET Standard库，跨平台部署成了顺带的事。更重要的是，UA把“数据模型”也标准化了：服务器里可以用对象、变量、方法描述PLC的DB块、结构体、报警，客户端通过节点ID定位数据，而不是只看到一个扁平的项列表。
安全模型是证书加加密，第一次连接需要互相信任证书。这个证书机制劝退了不少新手，因为它不像DCOM权限那样报一个笼统的“拒绝访问”，而是直接告诉你证书不受信任。测试环境可以临时把AutoAcceptUntrustedCertificates设成true，生产环境我强烈不建议这么做，一是审计过不去，二是哪天服务器IP换了或者证书重签，客户端会静默连错目标。选型上，只要是新建项目或者有跨平台诉求，我一般直接上OPC UA；只有维护老系统才继续用DA。
两类协议对比存放下面这张表里，方便组会时跟同事对齐：
| 对比项 | OPC DA | OPC UA |
|---|---|---|
| 底层协议 | COM/DCOM | TCP 4840 / HTTPS |
| 跨平台 | 仅Windows | Windows/Linux |
| 安全 | 依赖DCOM用户权限 | 证书 + 加密 |
| C#常用方案 | OPCDAAuto互操作 | OPCFoundation.NetStandard.Opc.Ua |
| 适合场景 | 存量旧系统 | 新建、跨平台项目 |
2.3 免费OPC服务器和SCADA链路：本地模拟比接真PLC更快
做C#上位机，不一定要先碰真PLC。常见做法是先装一个免费的OPC服务器模拟器，比如Prosys OPC UA Simulation Server或Matrikon OPC Simulation。前者面向UA，自带一批实时变化的模拟标签，用来验证客户端读写逻辑最合适；后者是经典DA教学工具，很多老资料里都拿它做演示。这类模拟器就是标题里最常见的“免费的OPC服务器”，把它们跑起来，等于有了一个永远不会停机的假PLC。
如果需要对标真机，西门子环境会用S7-PLCSIM Advanced启动虚拟PLC，再通过SIMATIC NET或Kepware把地址空间暴露出来；CODESYS系（汇川、倍福等）的运行时通常自带OPC UA Server，在工程设置里勾选启用，上位机就能直接连。整条链路就是：PLC程序 → PLC厂家协议 → OPC Server → 标准接口 → C#客户端。SCADA如何与PLC连接，走的也是这条链路，只不过SCADA把客户端做成了组态界面。先拿免费模拟器把代码跑通，再到真机上按点位表逐个核对，这是我认为最稳妥的推进顺序。
3. 本地跑通第一个OPC通讯实例：免费OPC服务器和最小C#代码
环境准备好后，就该写代码了。我不建议一上来就封装什么“OPC帮助类”，先用最小代码跑通“连接→读→写→断连”这个循环，确认环境和服务器都没问题，再谈封装。这一章给两个版本：一个OPC UA，一个传统OPC DA，分别对应前面选型里说的两条路线。
3.1 OPC UA客户端最小代码：连接、读一个节点、关闭
以Prosys OPC UA Simulation Server为例，启动后默认监听opc.tcp://127.0.0.1:4840。控制台项目里安装NuGet包OPCFoundation.NetStandard.Opc.Ua，然后写下面的代码：
// 最小 OPC UA 客户端：连接、读、写、关闭 // NuGet 包：OPCFoundation.NetStandard.Opc.Ua // 目标框架：.NET 6 或 .NET 8 控制台项目 using Opc.Ua; using Opc.Ua.Client; using Opc.Ua.Configuration; string endpointUrl = "opc.tcp://127.0.0.1:4840"; var config = new ApplicationConfiguration { ApplicationName = "CSharpOpcClient", ApplicationType = ApplicationType.Client, SecurityConfiguration = new SecurityConfiguration { // 测试环境自动信任服务器证书；生产环境必须改成显式信任 AutoAcceptUntrustedCertificates = true }, TransportQuotas = new TransportQuotas { OperationTimeout = 60000 }, ClientConfiguration = new ClientConfiguration { DefaultSessionTimeout = 60000 } }; var endpoint = new ConfiguredEndpoint(null, new EndpointDescription(endpointUrl)); var session = await Session.Create( config, endpoint, false, "CSharpOpcClientSession", 60000, null, null); // 读一个节点：ns=2 是命名空间索引，s= 表示字符串标识 var nodeId = new NodeId("ns=2;s=Channel1.Device1.Tag1"); DataValue dv = await session.ReadValueAsync(nodeId); Console.WriteLine($"值={dv.Value}, 质量={dv.StatusCode}, 时间戳={dv.SourceTimestamp}"); // 写入：Variant 内部类型要和服务器标签类型匹配 var writeValue = new DataValue(new Variant(1200)) { StatusCode = StatusCodes.Good, SourceTimestamp = DateTime.UtcNow }; var writeCollection = new WriteValueCollection { new WriteValue { NodeId = nodeId, AttributeId = Attributes.Value, Value = writeValue } }; var writeResults = await session.WriteAsync(writeCollection); if (writeResults.Results[0].Code == StatusCodes.Good) { Console.WriteLine("写入成功"); } session.Close();这段代码的逻辑分四段：先创建ApplicationConfiguration，里面管着客户端名称、证书策略、超时时间；再用Session.Create建立会话，这个方法是整个UA连接的入口；接着通过NodeId定位要读写的标签，读取返回DataValue，里面同时带值、质量码和时间戳；最后写值时把要写的内容包成WriteValueCollection发给服务器。
参数方面需要关注两点：OperationTimeout和DefaultSessionTimeout都设成60000毫秒，可以避免服务器偶发卡顿时客户端立即超时；AutoAcceptUntrustedCertificates只是测试用，如果连着真PLC，我建议改成证书目录显式信任，否则哪天服务器地址变了，客户端会在你没有察觉的情况下重新协商。
3.2 传统OPC DA（COM）客户端：OPCDAAuto互操作写法
如果公司存量系统还在跑OPC DA，你需要另一种写法。它依赖Windows下的COM组件OPCDAAuto.dll，用C#直接new COM对象。写这个代码的前提是OPC Core Components已经安装，服务器ProgID要提前确认，比如Kepware通常是Kepware.OPC.Simulation。
// 经典 OPC DA 客户端：适合老项目 // 需要安装 OPC Core Components，并添加 OPCDAAuto.dll 的 COM 引用 // 注意：工程生成平台必须选 x86，x64 下 COM 互操作很容易出问题 var server = new OPCServer(); // 第一个参数是服务器 ProgID，第二个是机器名，空字符串表示本机 server.Connect("Kepware.OPC.Simulation", "", ""); var group = server.OPCGroups.Add("Group1"); // AddItem 的第二个参数是客户端自定句柄，不要和别的项重复 int itemHandle = group.OPCItems.AddItem("Channel1.Device1.Tag1", 1); Array values, errors, qualities, timestamps; // OPC_DS_DEVICE 表示从设备读，而不是读服务器缓存 group.SyncRead( (short)OPCDataSource.OPC_DS_DEVICE, 1, new int[] { itemHandle }, out values, out errors, out qualities, out timestamps); Console.WriteLine($"读到的值: {((object[])values)[0]}"); // 写入：数组长度和条目数一致，类型要和服务器一致 object[] writeData = { 100 }; group.SyncWrite(1, new int[] { itemHandle }, ref writeData, out errors); server.Disconnect();这段代码是典型的“三步走”：连服务器，建组，加项。加项时拿到的itemHandle是后面所有读写操作的身份凭证，注意它和客户端句柄是两个概念。SyncRead和SyncWrite是同步调用，线程会阻塞到服务器返回结果，所以一般不在UI线程里直接调，而是放到后台任务里。
OPC DA的坑集中在工程属性里。项目平台必须选x86，.NET 6以上的项目默认AnyCPU，在64位系统上会以64位进程跑，COM互操作很容易失败。如果报“未注册”之类的错误，先用管理员权限运行regsvr32 OPCDAAuto.dll，再检查服务器ProgID是否正确。跨机器访问还要在组件服务里配置DCOM权限，这部分我会在避坑章节展开。
3.3 代码之后的参数说明：证书、线程模型与位数
两个版本跑通后，有几个参数要按项目调，不能直接抄。
证书是UA最常见的坑。ApplicationConfiguration里可以指定ApplicationCertificate的存储路径，也可以用SecurityConfiguration自动生成证书。测试场景图省事把AutoAcceptUntrustedCertificates设成true，但服务器换IP后旧证书会失效，客户端又会重新弹证书信任对话，这在无人值守的上位机上是灾难。我一般会在正式环境维护一个客户端证书目录，把服务器证书导出来放进去，同时在服务器端把客户端证书加入信任列表。
Session.Create中间有个参数叫required的Boolean，代表是否需要加密会话。很多仿真器支持无加密连接，Session.Create填false可以先用起来；真要对接工业现场的UA服务器，通常要求SecurityMode为SignAndEncrypt，证书环节跑不掉。
DA的线程模型也有讲究。COM组件调用要求线程是STA（Single-Threaded Apartment）模式，控制台程序的Main方法要标[STAThread]，否则某些机器上OPCServer.Connect会直接崩溃或卡住。这个坑在Windows 10上比老服务器少，但一旦线上遇到，就是“时而好时而坏”的诡异问题。做这块的工程师常把它叫“血泪经验”，今天多写一句，能省后人半天时间。
4. 读写PLC数据的核心逻辑：从NodeId到DataValue再到字节序
连接跑通只是开始，真正让PLC数据稳定进上位机，得把读写逻辑吃透。这一章不讨论“怎么连上”，讨论“读上来的数据怎么变成能用的值，写下去的值怎么真正落进PLC”。
4.1 读数据：批量读取和DataValue里的隐藏信息
只读一个节点，性能看不出问题，但真实上位机一屏要读几十个温度、压力、速度值。如果每个点都走一次ReadValueAsync，网络往返次数会拖垮刷新率。所以要做批量读取：
// 批量读取：一次调用传多个节点，减少网络往返 ReadValueIdCollection readValueIds = new ReadValueIdCollection { new ReadValueId { NodeId = new NodeId("ns=2;s=Channel1.Device1.Tag1"), AttributeId = Attributes.Value }, new ReadValueId { NodeId = new NodeId("ns=2;s=Channel1.Device1.Tag2"), AttributeId = Attributes.Value } }; DataValueCollection results = await session.ReadAsync(readValueIds, 0, TimestampsToReturn.Both); for (int i = 0; i < results.Count; i++) { var result = results[i]; if (StatusCode.IsGood(result.StatusCode)) { Console.WriteLine($"Tag{i} 值={result.Value}, 质量={result.StatusCode}"); } else { Console.WriteLine($"Tag{i} 读取失败: {result.StatusCode}"); } }ReadAsync的第二个参数是maxAge，单位毫秒。传0表示强制读设备，不读缓存；传一个正数比如200，服务器可以在时间窗口内返回缓存值，高频采集时能显著降低PLC通讯负载。这个参数就是很多工程师说的“C#读取PLC频率多少合适”的答案之一：如果PLC通讯周期是100ms，客户端没必要每20ms请求一次设备，用订阅或合理maxAge更稳。
DataValue里的StatusCode要看，不只是成功失败。OPC UA里BadNodeId、BadWaitingForInitialData、BadDataTypeIdUnknown都是具体的错误码，日志里必须把状态码打出来，而不是只打一个“读失败”。老OPC DA里叫Quality，0到192之间的一个整数，经验法则是把Quality >= 192视为好值，现场经常出现质量管理不到位导致坏值入库的情况。
4.2 写数据：布尔、整数、浮点，分别怎么落
写入比读取更敏感，因为写错一个值可能就让设备动一下。我习惯把写入封装成一个带类型校验的通用方法，避免每个业务逻辑都去拼WriteValueCollection：
// 封装写入：类型必须匹配，服务器才会当作好值处理 await WriteNode(session, new NodeId("ns=2;s=Channel1.Device1.StartFlag"), new Variant(true)); await WriteNode(session, new NodeId("ns=2;s=Channel1.Device1.TempSet"), new Variant(36.5f)); await WriteNode(session, new NodeId("ns=2;s=Channel1.Device1.Counter"), new Variant(100)); static async Task WriteNode(Session session, NodeId nodeId, Variant value) { var wv = new DataValue(value) { StatusCode = StatusCodes.Good, SourceTimestamp = DateTime.UtcNow }; var writes = new WriteValueCollection { new WriteValue { NodeId = nodeId, AttributeId = Attributes.Value, Value = wv } }; var result = await session.WriteAsync(writes); if (result.Results[0].StatusCode.Code != StatusCodes.Good) { throw new InvalidOperationException($"写入失败: {result.Results[0].StatusCode}"); } }写入失败最常见的原因不是网络掉线，而是类型不匹配。服务器上标签是Real类型，客户端却传了double，某些服务器会拒绝，某些会把高位截断后写个0，后一种情况最坑，因为客户端看到的返回码是Good。所以封装里一定要把Variant的原始类型暴露出来，至少能在日志里看到写的是什么类型。
另外要注意PLC程序侧的刷新机制。很多PLC程序每个扫描周期都会把某个DB块的值重新计算、覆盖，上位机写入成功了，但一秒钟后就被PLC逻辑改回去。这不是OPC问题，是PLC程序逻辑问题。现场排查时先把PLC里对应地址的读写属性、程序里是否有赋值语句列出来，再判断是不是OPC链路的问题。
4.3 C#读取PLC频率与订阅刷新：轮询vs订阅的取舍
老一代上位机喜欢开一个后台线程，while(true)循环里Thread.Sleep(50)然后读一批点。这种方法简单直观，但在点数一多、服务器吞吐有限时，容易把CPU跑满，还可能出现队列堆积。OPC UA提供了订阅机制，客户端订阅节点后，服务器按PublishingInterval周期推送变化值，比客户端主动轮询更省资源：
// 订阅推送：替代 while + Thread.Sleep 轮询 var subscription = new Subscription(session.DefaultSubscription) { PublishingInterval = 500, // 服务器推送周期，单位 ms LifetimeCount = 100 }; var monitor = new MonitoredItem(subscription.DefaultItem) { StartNodeId = new NodeId("ns=2;s=Channel1.Device1.Tag1"), SamplingInterval = 500, // 客户端采样周期 QueueSize = 2 }; monitor.Notification += (item, args) => { if (args.NotificationValue is MonitoredItemNotification dp) { Console.WriteLine($"订阅收到: {dp.Value} | 状态: {dp.StatusCode}"); } }; subscription.AddItem(monitor); session.AddSubscription(subscription); subscription.Create();这里的PublishingInterval是服务器下发数据的周期，SamplingInterval是服务器采集PLC数据的周期。现场调试时，一般先从1000ms开始，确认链路稳定后再往下压。不要追求极端速度，OPC只是传输协议，真正速度上限取决于PLC通讯周期和服务器采集周期。如果看到“C#读取PLC频率多少合适”这类问题，答案永远是：不小于PLC通讯周期，且用订阅优先于轮询。
对老OPC DA，订阅模型同样存在，group.OPCItems可以加入多个项，然后通过group.DataChange事件接收变化。只不过DA事件模型用的是COM事件接收器，要小心引用泄漏，断线重连时旧事件订阅要及时释放，否则内存会悄悄涨。
5. OPC通讯避坑：连接被拒、BadNodeId、写入不生效的排查记录
这一章是给现场调试用的。我尽量按“现象→原因→解决”来写，每一条都是真实项目里见过很多次的。
5.1 OPC服务器在运行，C#客户端却提示连接被拒
现象：服务器软件打开了，用UaExpert能连上，但C#代码里Session.Create一直报超时或连接被拒。
原因分三类：第一是防火墙没放行4840端口；第二是服务器绑定地址不对，很多仿真服务器默认只监听127.0.0.1，局域网其他机器连不上；第三是UA服务器开启了匿名访问限制，客户端证书不被信任时，协议握手阶段就直接断开。
解决：先在服务器本机用telnet 127.0.0.1 4840验证端口通不通，再用UaExpert从另一台电脑连接，排除网络问题。如果UaExpert能连而C#代码连不上，重点查两端证书配置。Prosys这类服务器会在界面上显示“拒绝连接”的具体原因，直接看服务器日志比猜快得多。端口通了但连不上，我再去看证书和时间戳，时间差太多也会握手失败。
5.2 节点ID抄了半天，结果还是BadNodeId
现象：从UaExpert地址空间里看到一个节点叫Channel1.Device1.Tag1，照着填进NodeId就报BadNodeId。
原因：OPC UA的节点ID不只是名字，还有命名空间索引。UaExpert里显示的ns=2;s=Channel1.Device1.Tag1，这个ns=2对应服务器配置里的一个命名空间URI，只抄后半段等于没抄全。更常见的坑是，OPC DA里的Item IDChannel1.Device1.Tag1和OPC UA里的节点标识不是一回事，服务器不会把DA的路径自动翻译成UA节点ID。
解决：先在UaExpert里右键节点，选择“Copy NodeId”，把完整字符串粘到代码里。读节点时可以先试ns=0;s=Server_ServerStatus_StartTime这类标准节点，如果能读到，说明连接和会话没有问题，问题出在自定义节点ID上。实在找不到正确节点，就在程序里遍历服务器地址空间，把匹配到的节点全部打印出来，虽然粗暴但管用。
5.3 写入返回成功，PLC里数值却没变化
现象：session.WriteAsync返回StatusCode.Good，PLC监控画面里对应的数据纹丝不动。
原因：先排除类型问题，前面讲过的double写Real截断不是报错，而是写了个不匹配或超范围的值。再看PLC程序，很多逻辑会把输入映射到输出后立刻覆盖，比如PID指令每个周期都写内部变量，上位机写入的设定值只在某一瞬间生效，下个周期就被控制逻辑覆盖了。还有一个隐蔽原因：西门子DB块如果勾选了“优化的块访问”，外部OPC只能按符号名访问，不能按绝对地址写，写操作可能被忽略。
解决：先改PLC程序，把上位机能写的设定值单独放到一个专用DB或保持变量里，确保程序不会在周期末尾覆盖它；再检查DB块属性，取消“优化的块访问”或正确使用符号名；最后在服务器端工具里手动写一次这个节点，排除C#客户端封装问题。顺序一定是先PLC后OPC，因为OPC链路出问题通常不会返回假Good。
5.4 S7-PLCSIM Advanced的PLC实例启动不了
现象：用S7-PLCSIM Advanced V5.0做西门子S7-1500仿真，点启动实例时提示错误，有时候连日志都没有，直接“无法启动”。
原因：最常见的是实例名称和TIA Portal项目里的PLC名称不一致，或者TIA项目没下载到仿真器；其次是多个实例之前没有退出干净，仿真器状态卡在旧实例上；另外这个软件对操作系统用户权限很敏感，普通用户启动时有时不报错但会失败。
解决：我的排查顺序是：先用管理员身份运行S7-PLCSIM Advanced，再检查仿真器项目里注册的实例名是否和TIA设备名称完全一致，然后停掉所有残留实例，最后重新下载TIA项目到仿真器。PLC实例启动不了这个问题，八成出在“名称不匹配”或“残留实例冲突”上，和OPC客户端代码没有直接关系，但它是整个仿真链路的老大难，先把它救活，后面OPC UA测试才有条件做。
6. 用最小OPC程序跑通后，怎么扩成SCADA式采集
6.1 先把验证顺序固定下来，再谈封装架构
我不会一上来就写大而全的采集框架，而是把验证顺序定成一套固定动作。第一步用免费的OPC服务器模拟器启动一个假PLC，确认点位能上报；第二步用UaExpert这类通用客户端连一次，能浏览到地址空间；第三步才写C#最小代码，跑连接、读、写、断连四个动作；第四步把最小代码里的连接参数抽到配置文件，把点位表抽到一个List<NodeId>里，循环采集。这个过程走完，整个方案的技术可行性就有了定论，剩下的是业务界面和历史存储的问题。
6.2 我看过太多翻车案例后的个人习惯
我的习惯是，所有OPC读上来的数据，先统一转成带Quality和时间戳的DataPoint结构体，再交给上层。不管是存数据库还是画趋势图，只要源头有坏值，后面做再多的滤波也意义不大。另一个习惯是，第一次到现场联调，不写任何业务代码，先写一个能连接、能读5个点、能断线重连的探路程序，放在现场跑10分钟，盯着日志看有没有异常。这个习惯帮我挡掉过好几次返工——有一次就是PLC节点类型跟点位表完全不符，探路程序打印出的类型一眼暴露了问题。还有一次是服务器端口通但证书不被信任，日志里反复出现握手失败，提前暴露了部署环境问题。这些坑，等正式功能上线后再暴露，成本要高一个量级。
做OPC通讯这件事，绕不开协议选择也绕不开环境排查，代码反而只是最后落笔的动作。我把这些经验写出来，希望帮到你。
本文还有配套的精品资源，点击获取
