简介这是一份由工控老马出品的 KEPServer 与 PLC 通讯的 C# 程序示例源码面向工控上位机开发人员也适合刚接触 OPC 协议的新手快速上手。服务端采用 KEPServerEX V5客户端使用 C# 与 WinForms 编写完整演示了从服务器连接、创建组与添加项到 PLC 变量实时读取与写入的通讯链路。资源共 33 个文件压缩包约 148KB主要包含 9 个 C# 源码文件、Visual Studio 解决方案与工程配置、可执行程序及调试符号另附界面图片、资源文件和运行配置文件目录结构清晰便于对照学习。目前已有 917 人学习下载。通过源码可以重点理解 OPC 客户端初始化、服务器连接、数据读写回调等关键实现配合 KEPServerEX 模拟通道即可在本地验证通讯效果示例中还保留了界面设计代码和程序入口读者能快速定位连接配置、数据监控与读写操作等模块的对应实现方便二次开发与改造为后续对接西门子、三菱等常见品牌 PLC 打下扎实基础。1. 为什么PLC数据要绕一道KEPServerOPC网关选型与这套C#源码解决的痛点车间里最不缺的就是“各说各话”的设备西门子S7-1200走S7协议三菱走MC协议ABB变频器走Modbus RTU还有些数控机床、传感器只留一个串口或以太网口协议五花八门。你要做C#上位机、SCADA大屏或者给MES喂数据不可能每个协议都自己写解析包——写一个S7驱动就得折腾好一阵子更别说还要处理不同PLC的字节序、功能码和断线重连。KEPServerEX这个OPC网关的作用就是把这些异构设备统一收编成一张标签表然后让你的C#程序只面对一个接口OPC DA或者OPC UA。“工控老马”这套KEPServer OPC与PLC通讯的C#示例源码价值正在于此——它给你的是一个最小可运行的客户端框架连上KEPServer、读写PLC变量、处理数据变化而不是让你从零去和PLC裸协议搏斗。适合正在做C#上位机、设备数据采集、SCADA系统对接或者刚接触OPC想找一份能抄作业的源码的人。你不需要理解S7协议里那些复杂的TSAP参数只需要知道标签名和数据类型剩下的事情交给KEPServer和下面要讲的这套代码。2. 先把OPC的底摸清KEPServerEX的通道配置与OPC DA/UA地址模型2.1 OPC网关在工控架构里的位置从PLC寄存器到上位机的数据路径OPC是一套接口标准不是具体的通讯协议。它的核心逻辑是“Server把设备数据变成统一的标签Client只管按名字读写标签”。在这套架构里KEPServerEX是ServerPLC是数据源你的C#程序是Client。数据流向是PLC的寄存器或者DB块 → KEPServer里的设备驱动Siemens TCP/IP、Modbus TCP、三菱MC等 → KEPServer内部的标签表 → OPC接口 → C#程序。我一般会把KEPServer比喻成“翻译官数据仓库”翻译官负责把各种协议的报文翻成统一的标签值数据仓库负责缓存一部分最近的值让多个客户端同时读数据时不至于把PLC通讯口打满。这就是为什么不少项目里C#程序、SCADA、看板系统同时从KEPServer取值PLC那边的负载也不会明显上升。搞清楚这个位置关系很重要因为后面所有排错思路都围绕它连不上先查通道和驱动读不到标签先查设备状态值不对先看标签地址。你如果跳过KEPServer直接拿C#去连PLC那等于放弃了这一层的缓冲能力虽然也能通但你要自己做协议解析、权限管理和多客户端竞争维护成本高一个量级。2.2 KEPServerEX通道/设备/标签三级配置以S7和Modbus TCP为例KEPServerEX的配置结构是固定的三层理解它你才知道代码里那些字符串到底指向哪里。第一层是通道Channel通道里必须指定一个驱动Driver比如Siemens TCP/IP Ethernet、Modbus TCP、Mitsubishi Ethernet一个通道可以理解成“一类协议的实例”。第二层是设备Device挂在通道下对应一台实际PLC需要填IP地址、通讯参数有的协议还要填机架号、插槽号。第三层是标签Tag挂在设备下对应PLC里的一个具体地址比如DB1.DBD0或者40001。拿西门子S7-1200/1500举例用Siemens TCP/IP Ethernet驱动建通道后设备参数里必填的几项大概是下面这些参数常见取值说明IP地址192.168.1.10PLC的网口IP机架号Rack0S7-1200/1500一般填0插槽号Slot1S7-300/400常见Slot 2S7-1200/1500常见Slot 1通讯超时5000ms掉线判断时间别设太短扫描周期100-1000ms请求数据的间隔越小越占用通讯资源这三层配置完还要确认设备图标是不是绿色。KEPServer的管理界面里设备图标如果变成灰色或者带感叹号说明通讯没建立这时候代码写得再漂亮也没用。我习惯在配置完第一遍后用KEPServer自带的QuickClient工具先手动读一次该标签确认值能出来再写C#代码。这一步能帮你把“KEPServer与PLC的问题”和“C#与KEPServer的问题”分开后面排错少走弯路。标签的地址写法也有讲究S7驱动里DB块地址要写成“DB1.DBD0”或者“DB1.DBW0”这种格式Modbus驱动写“40001”需要按驱动手册来不能靠猜。老马这套源码一般会提供一个标签名常量类或者配置文件就是让你把这一层和代码解耦别把标签字符串写死在业务逻辑里。2.3 OPC DA和OPC UA选哪个同一套标签两种读法KEPServerEX同时暴露OPC DA和OPC UA两种接口C#程序接入时你的第一个选择就是走哪一条。OPC DA基于微软COM/DCOM技术有二三十年的历史特点是轻量、简单、在Windows单机上几行代码就能连上对应前面的OPC DA 2.0 Automation接口。OPC UA是新一代标准基于TCP而不是DCOM跨平台、自带加密和证书认证、不用配置DCOM权限但首次建连要处理证书信任代码量明显大一些。对比项OPC DA 2.0OPC UA传输基础COM/DCOMTCP默认端口常为49320防火墙穿透麻烦要开一堆DCOM端口只开一个TCP端口跨平台仅WindowsWindows/Linux都行安全性基本没有证书签名加密C#接入成本低引用COM组件稍高要配置证书适用场景单机演示、老项目新项目、跨机器部署我的建议是老项目维护用DA新项目直接上UA。尤其你的上位机要和MES、数据库服务器分开部署时UA一个端口就搞定不用去和IT吵DCOM的端口范围。OPC UA的NodeId看起来像“ns2;sChannel1.Device1.Tag1”比DA的字符串形式多了一层命名空间的概念但指向的是同一张标签表。KEPServer配置好之后两种协议读到的数据是一样的只是“外包装”不同。3. 用C#实现OPC客户端从DLL引用到读写PLC变量的最小代码3.1 让C#拿到OPC DA接口OpcDaAuto注册与64位编译的提前处理OPC DA Automation接口在Windows里对应的是OpcDaAuto.dll这个COM组件属于OPC Core Components的一部分。你需要在开发机上先注册它把OpcDaAuto.dll放到一个固定目录然后以管理员身份打开命令提示符运行regsvr32 C:\Windows\System32\OpcDaAuto.dll。之后在C#工程里添加COM引用找到“OPC DA Automation 2.0”这个组件IDE会自动生成Interop.OpcDaAuto.dll。这里有个提前要说的坑OpcDaAuto是32位COM组件如果你的C#工程编译目标平台是“Any CPU”且运行在64位系统上进程会以64位运行COM注册信息里找不到对应的32位组件结果就是创建OPC服务器对象时报“类未注册”。我一般直接把工程平台改成x86虽然听起来老土但这是OPC DA最简单的稳定路线。如果公司强制64位进程那就改用OPC UA不要和COM组件较劲。注册完组件后不管你是自己写代码还是拿老马这套源码来改都要确认KEPServer电脑上的ProgID。常见的是Kepware.KEPServerEX.V6具体后缀跟KEPServer版本走。你看示例源码里连接串写的就是这个自己落地时可以在KEPServer安装目录或者注册表里查准确的ProgID。3.2 用OPC DA读一个PLC变量SyncRead的完整流程先看老马这类示例源码里最核心的一段读操作我用C#给你还原一遍调用链using OpcDaAuto; // 1. 创建OPC服务器对象并连接KEPServer OPCServer server new OPCServer(); server.Connect(Kepware.KEPServerEX.V6, localhost); // 2. 添加一个OPC组并开启订阅 OPCGroup group server.OPCGroups.Add(DataGroup); group.IsActive true; // 组必须激活 group.IsSubscribed true; // 订阅模式数据变化时触发事件 group.UpdateRate 1000; // 组更新周期单位毫秒 // 3. 向组内添加要读取的标签 OPCItem item group.OPCItems.AddItem(Channel1.Device1.Tag1, 1); // 4. 同步读取读设备原始值绕过OPC缓存 object values null, errors null, qualities null, timestamps null; group.SyncRead((short)OPCDataSource.OPCDevice, 1, out values, out errors, out qualities, out timestamps); Array vals (Array)values; Array quals (Array)qualities; Console.WriteLine($值{vals.GetValue(0)}质量{quals.GetValue(0)});这段代码的逻辑分四步先Connect连上KEPServer再建组组里加标签最后一次性读出来。OPCDataSource.OPCDevice表示直接去设备侧读原始值而OPCDataSource.OPCCache是读KEPServer缓存。调试时我用Device模式因为能确认现场数据正式采集为了降低PLC压力我会改成Cache模式并且把UpdateRate调大一点。UpdateRate是组的更新周期单位毫秒。设1000就是每秒向设备要一次数据。这个值不是越小越好设太小可能把PLC通讯口打满导致KEPServer里其他设备跟着超时。我的经验是先按500ms起步看PLC的通讯负载曲线再往下压。质量参数Quality是OPC体系里很重要的字段192表示“好”64表示“不确定”0表示“坏”后面避坑章会专门说它。3.3 从轮询到事件用订阅把“定时读”变成“变化才通知”如果只用SyncRead你就要自己写个定时器每100ms读一次这在标签不多时没问题标签一多效率就低了。老马源码里一般会放一个基于事件订阅的版本代码核心是给组挂一个数据变化回调// 组的数据变化事件值变化时才触发 group.OnDataChange Group_OnDataChange; static void Group_OnDataChange(int transactionId, int numItems, ref object clientHandles, ref object values, ref object qualities, ref object timestamps) { Array handleArr (Array)clientHandles; Array valArr (Array)values; Array qualArr (Array)qualities; for (int i 0; i numItems; i) { int handle (int)handleArr.GetValue(i); object val valArr.GetValue(i); int quality (int)qualArr.GetValue(i); Console.WriteLine($句柄 {handle} 的值{val}质量{quality}); } }这个事件的交易模型是KEPServer组里注册的标签值发生变化时自动把变化的数据推给C#端不需要你主动读。clientHandles就是你在AddItem时传进去的第二个参数我一般用它来标识“这个值属于哪个设备或者哪个工艺参数”在回调里用if或switch分发给不同业务处理函数。订阅模式的坑是回调运行在COM的线程池上不要在回调里直接操作UI控件否则界面会卡死甚至闪退。正确做法是回调里用Invoke切到UI线程或者把数据塞进一个线程安全的队列由UI线程自己取。数据量大的采集场景队列方案更稳。3.4 改用OPC UA一段能跨机器部署的最小客户端代码如果你的场景换成“C#上位机在A电脑KEPServer运行在B电脑”强烈建议用OPC UA不用纠结DCOM权限。先通过NuGet把OPC Foundation的Opc.Ua.Client和Opc.Ua.Core装进工程然后看这段最小示例using Opc.Ua; using Opc.Ua.Client; // 1. 建立应用配置 ApplicationConfiguration config new ApplicationConfiguration(); config.ApplicationName OpcPlcClient; config.ApplicationType ApplicationType.Client; config.SecurityConfiguration new SecurityConfiguration(); // 2. 从地址里选一个端点并建立会话 string endpointUrl opc.tcp://192.168.1.10:49320; EndpointDescription endpoint CoreClientUtils.SelectEndpoint(endpointUrl, false); Session session Session.Create(config, endpoint, false, C# OPC UA 客户端, 60000); // 3. 按标签名读一个节点值 // 命名空间索引2只是KEPServer常见值实际要读Server的NamespaceArray确认 NodeId nodeId new NodeId(Channel1.Device1.Tag1, 2); DataValue value session.ReadValue(nodeId); Console.WriteLine($UA读取结果{value.Value}质量{value.StatusCode});SelectEndpoint的第二个参数是false表示不启用安全连接适合内网开发环境调试。生产环境我会建一个本地证书配置里指定证书路径和信任列表代码量会多出四五十行但换来的是通讯加密和防篡改。Session.Create的最后一个参数60000是会话的超时毫秒数现场网络抖动时这个值设太小会出现莫名掉线。OPC UA读取时更要注意NodeId的命名空间索引。KEPServer的UA服务对每个驱动会注册一个命名空间索引和驱动顺序有关不一定是2。我一般会在程序启动时读一遍NamespaceArray把标签名对应的命名空间索引动态算出来而不是写死。写回变量也简单session.WriteValue(nodeId, new DataValue(new Variant(88)))一行就能把值写到PLC前提是你有写入权限而且PLC地址允许写。4. 这套示例源码的架构价值三层拆分与接入自己PLC的改写路径4.1 示例工程里的三层结构把OPC代码横向拆开“工控老马”这套源码如果只当成“能跑通的参考”去复制粘贴其实浪费了它大半价值。正常这类示例会按三层结构组织界面层负责显示数据和接收用户操作业务层负责逻辑判断比如温度超过阈值就报警通讯层负责封装OPC连接、读写、订阅向上层暴露类似bool Connect()、object ReadTag(string tagName)这样的方法。我拿到手第一件事是看通讯层封装成了什么样子。理想的框架是上层代码完全不出现OPCServer、OpcGroup这些对象全部收敛在通讯层的OpcClient类里。这样将来从OPC DA切换到OPC UA影响面只有通讯层业务层不用动。老马源码里如果这个边界清楚你直接沿用如果耦合在一起我建议先花半天把接口拆出来后面所有改动都会轻松很多。这套拆分在工控项目里尤其重要因为现场需求永远在变今天只读温度明天要写频率后天要对接MES的上传。只要通讯层封装得好每个新需求都是加一个方法的问题而不是重写一遍连接逻辑。4.2 接你自己的PLC三个必改的配置点与验证顺序把示例跑通之后接入现场PLC大多数人翻车在这三个地方。第一处是KEPServer的驱动选择你的PLC是西门子驱动选Siemens TCP/IP Ethernet是Modbus设备驱动选Modbus TCP是三菱FX系列驱动选Mitsubishi Ethernet。驱动选错后面标签地址全部对不上。第二处是设备参数IP、机架号、插槽号、通讯超时改完必须看到设备图标变绿。第三处是C#代码里的连接标识和标签路径DA用的是ProgIDUA用的是opc.tcp://IP:端口标签路径必须和KEPServer里建的通道、设备、标签三层结构完全一致。我建议按这个顺序验证先在KEPServer里写一个测试标签用QuickClient读到值证明“PLC→KEPServer”通了再运行示例源码把连接参数改成你的KEPServer地址读同一个测试标签证明“KEPServer→C#”通了最后才把业务标签一个个替换上去。这个顺序能让你每次出问题都能立刻判断是哪一端的问题不会两头瞎猜。标签路径里的大小写也不能抄错。KEPServer的通道名、设备名、标签名是严格区分大小写的channel1.device1.tag1和Channel1.Device1.Tag1是两回事。我遇到过一次现场连不上设备排查半天发现是KEPServer管理员把通道名改成了大写代码里还是小写。4.3 从“能读值”到“能上线”日志、断线重连与数据质量判断示例源码跑通只是开始真正上线要补三块东西日志、重连、数据质量判断。日志至少要有连接成功、连接失败、读值异常、写值异常这几个节点格式里带时间戳和标签名方便现场排查是通讯层问题还是业务逻辑问题。断线重连是工控系统的基本素养KEPServer和PLC之间断开时C#程序要能感知并自动尝试重新Connect而不是直接抛异常退出。数据质量判断是很多源码里偷懒的地方直接读value不看quality。在OPC体系里值本身只是半个答案质量位告诉你这个值是否可信。PLC断电瞬间OPC Server会把最后的值缓存在标签表里如果只看值你会觉得“数据正常”但质量位已经变成“Bad”。我现在写的采集程序一律先看质量质量非Good的数据不进数据库、不参与业务计算这条规则能帮你避免大量脏数据。5. OPC通讯C#开发避坑指南连不上、掉线、数据跳变的排查记录5.1 KEPServer设备图标变灰、QuickClient读不到值通道没通先查这三处现象是KEPServer管理界面里设备图标不是绿色QuickClient里读标签一直超时或者弹错。原因是通道或设备参数配置不正确常见于IP地址写错、机架号插槽号不对、PLC的以太网口没启用。解决办法是按顺序查三处先用ping确认电脑和PLC之间网络通不通不通查网线和IP网段再确认KEPServer驱动里选的协议与PLC支持的协议一致西门子S7-1200如果固件较新可能需要勾选S7-1500驱动兼容模式最后核对机架号和插槽号这个参数错最容易让人忽略因为它不报错只是通讯失败。排查这类问题我通常把过程录屏或者写成文档交底因为这类拖到现场再查的配置问题半小时能解决但也可能因为一个数字错误耗掉一下午。QuickClient的价值就是让你在写代码前先把这层问题排除干净。5.2 OPC DA在64位进程中报“类未注册”COM组件位数错位现象是代码运行到new OPCServer()时抛COMException提示类未注册或者找不到CLSID。原因是OpcDaAuto注册的是32位COM组件而你的程序按64位进程跑了。解决办法有三个最简单的是把工程平台目标改成x86其次是注册64位版本的OpcDaAuto注意系统里要区分System32和SysWOW64两个目录各自放对应位数的DLL再或者干脆放弃DA改用OPC UA。这个坑在开发机上往往不出现因为开发环境可能装过OPC Core Components64位注册表也有记录。打包给客户部署到新机器时这个问题就会集中爆发。我现在给客户发程序都会在部署说明里专门标一句“OPC DA客户端必须以X86模式运行”省了很多售后电话。5.3 PLC回包越来越慢最后通讯超时轮询频率与扫描周期互相打架现象是程序运行半小时后OPC读写速度越来越慢最后设备转灰。原因是多个OpGroup的UpdateRate都设成极小值比如10ms而PLC本身的扫描周期是几十毫秒KEPServer的请求队列被堵满设备驱动来不及处理就报超时。解决办法是把组的UpdateRate放到100ms以上高频信号的标签单独建组低频参数建另一个组不要所有标签挤在一个组里。另一个手段是把KEPServer设备属性里的扫描周期调大一点比如500ms让驱动批量取数而不是每条都单独请求。这种问题有个玄学特征重启KEPServer就恢复跑一阵又卡。其实是因为请求队列在长时间高负载后堆积重启只是清空了队列。真正治本的是降低请求频率并利用OPC的缓存机制没必要所有数据都实时轮设备。5.4 值跳变、数据曲线有毛刺误把质量位为Bad的值当成有效数据现象是采集到的数据偶尔出现一个巨大的异常值比如温度一下从20跳到200然后又恢复。这在OPC DA里很常见原因要么是PLC通讯瞬间故障导致服务器返回了旧缓存值要么是标签的数据类型映射不对比如把16位无符号整数按32位浮点数解析。解决办法是每次读值后先判断质量位非Good直接丢弃同一时间戳的数据要保留方便回查。数据类型映射问题是另一个容易翻车的点KEPServer里标签类型和C#里声明的变量类型必须一致。比如PLC里是DINT32位整数你在C#里用Convert.ToInt32接就没事用Convert.ToInt16就会溢出或得到错值。我一般在建标签时就约定好类型清单写到接口文档里避免上游改类型下游不知道。5.5 订阅回调不触发或者界面卡死回调线程和UI线程冲突现象是OPC DA订阅模式下界面上的数值一直不更新但用SyncRead能读到值或者程序运行一会界面无响应。原因是IsSubscribed属性没有设为true导致事件不触发或者回调里直接访问UI控件COM的回调线程和UI线程不同步操作了非线程安全的控件。解决办法是检查组里的IsActive和IsSubscribed两个属性必须同时为true回调里的事件处理只做数据收集通过Control.BeginInvoke把UI更新塞回UI线程或者用生产者消费者队列。订阅还有一种隐蔽情况标签值本身变化太小比如小数点后第五位在变OPC默认的死区设置把它过滤了表现就是“事件不触发”。这时要在组的属性里把死区设为0或者调小让所有变化都能推送上来。新手容易把这两个问题混在一起排查时先看事件有没有进来再分析为什么事件次数少。6. 从演示代码到采集服务分组读写、重连状态机与验收标准6.1 高频信号和低频参数分开建组别用一个组拖死所有数据采集点多的项目我会按数据变化频率分成两组甚至三组。温度、压力这类模拟量隔几百毫秒变一次开一个组UpdateRate设500ms设备启停、故障信号这类状态量变化很快开一个高速组UpdateRate设50ms到100ms。再有一个低频组用来写操作像电机转速设定值这种根本不需要实时回读10秒一次足够。组与组之间互不干扰某个组负载过高也不会拖慢其他组。分组还有利于定位问题如果某个组超时只要看那组对应的标签列表就能定位到具体设备和地址。如果是用老马那套源码改造建议把组的创建和标签分配写成一个配置文件由工程人员在现场按清单改不用每次重新编译。配置驱动的设计对工控软件来说比代码写得巧更实用。6.2 断线重连状态机从“报错退出”改成“自动恢复”现场通讯中断是常态可能是PLC重启、网线松动、或者KEPServer服务被误杀。我会在通讯层维护一个简单的状态机正常连接、连接中断、等待重连、重连成功四个状态。正常运行时周期检查心跳可以每10秒读一次系统标签或者一个稳定的PLC寄存器读取失败就进入等待重连状态用指数退避的方式尝试重新Connect比如第一次失败等5秒第二次等10秒最长等60秒避免高频重试打挂KEPServer。重连成功后要主动刷新一边原有组的订阅因为旧的订阅关系在Session断了之后可能已经失效。这步逻辑在源码里一般不会写得很好反而是需要重点改造的部分。我做这行最深的体会就是稳定性不是靠加班守出来的是靠这种状态机在无人值守时自动把问题扛下来。6.3 验证方法用QuickClient做三步对拍确认值和时间戳一致最后验收我会把程序输出和KEPServer自带的QuickClient并排对比选一个模拟量标签连续观察30分钟。先看值是否一致数值对不上优先怀疑类型映射和字节序再看质量位是否同步变差比如拔掉PLC网线后两边质量位应该同时变成Bad最后看时间戳摆动范围如果C#端时间戳和KEPServer端相差超过一个UpdateRate周期说明缓存读取路径有问题。三项都通过这套采集程序才算真正可以交付。我现在做OPC采集项目习惯先把质量位打出来宁可让用户看到一堆带质量标记的数据也不给他一个看起来正常实际是脏数据的结果。这个习惯帮我挡掉了很多半夜的“数据不对”电话。如果你准备拿老马这套源码起步建议从第3章的代码跑通开始然后按第4章的架构拆一遍再补上第5章里你躲不掉的那几个坑最后用本章的对拍方法收尾。希望帮到你。本文还有配套的精品资源点击获取