做倍福TwinCAT上位机开发的几乎都绕不开ADS通讯。不管是老牌的.NET Framework还是后来的.NET Core/.NET 5只要用C#跟PLC交换数据TwinCAT.Ads这套库基本就是标配。Beckhoff官方提供了一整套ADS示例工程从Sample01一路排下来覆盖连接、读写、通知、句柄调用等各种场景其中Sample11这个以删除句柄为唯一主题的例子看起来最不起眼却恰恰是很多人工作了三五年才真正读懂的。我第一次跑官方示例时注意力全放在CreateVariableHandle怎么建句柄、ReadAny和WriteAny怎么读写上到了Sample11看到就那么几行DeleteVariableHandle觉得没什么可学的。直到后来在客户现场遇到一台设备连续运行两天后PLC侧报句柄表溢出程序重启才恢复我才回头看这几行代码意识到句柄资源的管理从来不是小事。这篇文章就把Sample11讲透先说清楚句柄到底是什么、为什么必须手动删除再逐段拆解官方示例的标准写法最后结合我排查过的泄漏故障整理一套从现象到根治的完整方法。无论你是刚接触倍福ADS的新手还是已经写完一版能跑但不敢长期跑的上位机程序的老手这篇都值得花十分钟看完。1. 为什么官方要把删除句柄单独拎出来做一个Sample1.1 官方示例序列里的关键一课Beckhoff的ADS示例工程是一套编号非常清晰的学习路径先创建一个TcAdsClient连接再读取变量、写入变量、注册通知、创建句柄、异步读写一步一步往上叠。Sample11排在这个位置说明你前面已经创建过句柄、用句柄读写过变量了官方在这里特意补上归还资源这一课。有人会问删除句柄不就是一行DeleteVariableHandle吗顺手写在创建句柄的示例里不就行了为什么单独出一个Sample我的理解是官方恰恰要通过单独成章来强调句柄的创建和删除是两件分量相等的事甚至删除比创建更需要纪律。创建是需求驱动的你自然记得删除是责任驱动的很容易被程序马上要退出了下次运行会重新建之类的念头搪塞过去。单独出一个Sample就是要你把用完要还养成肌肉记忆。1.2 一个真实故障句柄表被写满之后我在现场遇到过这么一次故障。客户现场是一台做圆周分度的设备上位机是C#写的负责每100毫秒向PLC的轴控制功能块写一次目标位置。程序里有个循环每个循环周期都调用CreateVariableHandle创建新句柄用完又不删。前几个小时一切正常跑了一天多以后程序开始随机抛异常报的错误码是0x809设备句柄表溢出。重启程序之后又好了过一段时间又犯。最后查出来就是句柄只建不删把PLC侧句柄表给撑爆了。这个案例里最坑的一点是故障不是立刻爆发的而是随着时间推移慢慢逼近上限表现成一种间歇性、随机性的异常。这比直接报错更难排查。如果你在做的项目是7x24小时连续运行的产线设备句柄泄漏的问题几乎必然会在某个深夜爆发而且大概率是在你睡得最香的时候。2. ADS句柄的真实身份符号名与通知机制的中转站2.1 从字符串到内存地址的翻译过程在深入代码之前先搞清楚句柄到底是什么。当你写下GVL.nCounter这样一个字符串的时候TwinCAT的PLC运行时并不能直接拿这个字符串去读写内存它要在符号表Symbol Table里做一次查找把这个字符串翻译成一串数字——具体的IndexGroup索引组和IndexOffset索引偏移。这个翻译过程是有代价的字符串匹配、符号遍历、运行时内部锁每次查询都要走一遍。句柄就是把这套翻译结果缓存下来的产物。CreateVariableHandle(GVL.nCounter)执行一次符号表查询然后返回给你一个整数句柄。之后你用ReadAny(handle, typeof(int))去读变量的时候底层实际是用IndexGroup0xF005、IndexOffset句柄值去访问设备完全绕开了字符串查询速度快了一个数量级。打个比方字符串寻址就像每次都要从C盘根目录一层一层点进文件夹去找文件句柄寻址则是你提前把文件的快捷方式放在了桌面上。第一次找文件花了点时间之后就一直都是双击快捷方式的效率。2.2 句柄是在谁的内存里分配的这里有个容易混淆的地方CreateVariableHandle是在你的.NET程序里调用的但它分配的内存并不在你的进程里而在PLC的ADS设备也就是TwinCAT运行时里。你调用TwinCAT.Ads库时底层通过ADS协议给PLC发了一条创建句柄的命令PLC在自己的句柄表里分配一个条目再把句柄号返回给你。这就直接推出一个结论你的.NET程序退出、连接断开并不会自动把PLC侧已经分配出去的句柄回收掉。虽然TwinCAT在连接断开时确实会尝试清理该连接相关的句柄和通知但尝试不等于保证尤其当程序是崩溃退出的、网络是异常断开的时候清理逻辑可能根本没机会执行。把句柄的生命周期管理完全托付给系统收尾是非常冒险的习惯。2.3 句柄寻址与符号名寻址的取舍很多时候你会发现官方提供的ReadSymbol这类API也能按变量名字符串直接读写代码写起来还更短。那为啥还要先创建句柄对比维度符号名寻址句柄寻址每次调用开销每次执行符号表字符串匹配直接用整数索引访问典型APIReadSymbol(GVL.nCounter)ReadAny(handle, typeof(int))持久资源占用无PLC侧句柄表条目适用场景启动初始化、低频访问高频周期读写、性能敏感我的实测经验是在100毫秒周期里读几十个变量两种方式在普通工控机上差别不算大但是把周期压到1毫秒、变量量到几百个符号名寻址的开销就非常可观了。再加上句柄方式能保证每次访问的地址是稳定且经过校验的出错概率更低。这也是官方示例里高频访问一律走句柄的原因。2.4 句柄的边界不要跨连接、不要持久化句柄本质上是某个ADS连接上下文里的临时资源。同一个变量你这次连接创建的句柄和下次连接创建的句柄数值可能完全不同。所以千万不要把句柄值写进配置文件或者数据库里持久化下次启动直接拿过来用——这几乎一定会踩坑。正确的做法是每次连接建立后重新创建句柄用完删除绝不长期保存。还有一种情况要注意如果你的程序里同时开了多个连接比如一个连PLC、一个连NC轴模块每个连接都有自己的句柄空间A连接创建的句柄不能拿到B连接上去用。把连接对象和句柄的对应关系搞混也是排查半天找不到原因的高频问题。3. Sample11代码逐段拆解从Connect到DeleteVariableHandle3.1 环境准备.NET Framework版本与现场部署Sample11的工程是基于.NET Framework的。TwinCAT.Ads.dll在.NET Framework 2.0/3.5时代就已经定型后来也兼容到4.5/4.8。如果你用的是老版本ADS库项目属性里目标框架选.NET Framework 4.x基本通吃。这里多说一句部署的事情很多现场工控机是精简版Windows甚至离线环境装.NET Framework 3.5经常要折腾半天。如果客户机器上没装对应版本的.NET Framework程序双击根本起不来这跟ADS通讯代码怎么写没关系。我习惯把.NET Framework离线安装包和程序放同一个目录到了现场用离线安装程序直接装省得到处找网络。TwinCAT.Ads.dll本身也要跟着程序一起分发别指望客户机器上装着的TwinCAT版本一定和你编译用的类库版本兼容。3.2 连接对象与端口先连对才能谈句柄句柄是依附在连接上的所以第一步永远是连接。这里要分清楚两个默认端口TwinCAT 2的PLC Runtime 1默认是801TwinCAT 3的PLC Runtime 1默认是851。如果你用851去连TwinCAT 2、用801去连TwinCAT 3报的会是找不到设备的错误跟句柄没关系但很容易让人误判方向。连接分本地和远程两种写法// 连接本机TwinCAT的PLC Runtime 1 client.Connect(851); // 连接指定AMS NetId的远程设备例如工控机IP对应的NetId client.Connect(192.168.1.10.1.1, 851);远程连接时除了AMS NetId要写对还要保证TwinCAT路由配置里能互相访问。现场排查时我最常犯的错就是把NetId里的最后一段看漏建议把这串东西复制到记事本里逐段核对别用肉眼扫。3.3 创建、读写、删除的完整闭环下面这段代码就是Sample11的骨架我按可运行的标准还原了完整流程using System; using TwinCAT.Ads; namespace Sample11_DeleteHandle { class Program { private const string SYM_COUNTER GVL.nCounter; private const string SYM_ENABLE GVL.bEnable; static void Main(string[] args) { TcAdsClient client new TcAdsClient(); int hCounter 0; int hEnable 0; try { // TwinCAT 3 的 PLC Runtime 1 默认端口是 851 // TwinCAT 2 默认是 801按实际环境修改 client.Connect(851); // 创建句柄 hCounter client.CreateVariableHandle(SYM_COUNTER); hEnable client.CreateVariableHandle(SYM_ENABLE); // 用句柄读取 int nCounter (int)client.ReadAny(hCounter, typeof(int)); bool bEnable (bool)client.ReadAny(hEnable, typeof(bool)); Console.WriteLine(nCounter{0}, bEnable{1}, nCounter, bEnable); // 用句柄写入 client.WriteAny(hCounter, nCounter 1); } catch (Exception ex) { Console.WriteLine(ADS通讯异常: ex.Message); } finally { // 无论上面是否抛出异常这里都会执行 if (hCounter ! 0) { client.DeleteVariableHandle(hCounter); hCounter 0; } if (hEnable ! 0) { client.DeleteVariableHandle(hEnable); hEnable 0; } client.Dispose(); } Console.WriteLine(Sample11 执行完毕按任意键退出。); Console.ReadKey(); } } }官方示例的精髓不在创建句柄-读写-删除句柄这个顺序而在于把删除动作放进了finally块。这个细节如果漏掉一旦前面的ReadAny或WriteAny抛异常后面的删除代码就永远不会执行句柄照样泄漏。你可能会说我程序正常跑不会抛异常啊。问题是异常恰恰最容易出现在变量不存在、PLC重启、通讯超时这些非正常时刻而这些时刻也正是你最需要保护资源的时刻。判断句柄是否创建成功的时机也要把握好。老版本TwinCAT.Ads创建句柄失败会直接抛AdsException所以hCounter拿到返回值就说明创建成功了后面的ifhCounter ! 0只是防御性写法不是核心逻辑。真正要记得的是CreateVariableHandle返回的句柄在变量被从PLC工程里删除或PLC重新激活配置后可能会变得不可用这时候继续读写就会报0x808。3.4 删除句柄的两种错误处理形态这里要提一个版本差异。老版本的TwinCAT.Ads4.x系列就是.NET Framework时代最常用的那版里DeleteVariableHandle返回的是一个int0表示成功非0表示ADS错误码。新版本的Beckhoff.TwinCAT.Ads6.x系列里这个方法可能会直接抛出AdsException。所以写代码之前先确认你引用的是哪个版本错误处理策略要跟着版本走。老版本建议把返回值打日志便于排查新版本就包一层try/catch把错误码记录下来。不管哪种都不要在删除句柄时报错了还不理会——删除失败意味着PLC侧句柄可能还残留在表里这种残留是最隐蔽的泄漏来源。4. 句柄泄漏实战现象、定位与检测方法4.1 泄漏的典型症状与错误码识别句柄泄漏的现场表现通常不是一下子直接报错而是渐进式的症状说明运行越久读写越慢句柄表膨胀后PLC内部查找和内存占用都在增加偶发0x809错误句柄表写满新句柄创建失败偶发0x808错误使用了一个已经被回收或过期的句柄程序重启后恢复重启清空了句柄表掩盖了真正的根因0x808和0x809是设备侧的ADS错误码含义分别是设备句柄无效和设备句柄表溢出。如果在你的上位机日志里看到这两个码基本可以直接把句柄管理列为头号嫌疑对象。注意0x750这种客户端侧的句柄错误通常指的是.NET这侧的ClientHandle不是PLC变量句柄别混为一谈否则会往错误方向排查。4.2 简单可靠的检测手段想知道自己的程序有没有泄漏其实不需要复杂的工具。我在代码里加一个静态计数器每次CreateVariableHandle成功就加1每次DeleteVariableHandle成功就减1定期打印出来。正常程序这个数应该是一条平稳的直线如果它随时间线性上升那就是句柄泄漏实锤了。这套方法笨但有效而且完全不需要侵入PLC侧。如果需要PLC侧的准确数据可以在TwinCAT XAE里查看PLC实例的在线诊断信息或者用TwinCAT Router的诊断视图观察句柄表使用量。实测下来静态计数器法对绝大多数.NET上位机项目已经够用PLC侧诊断更多是在追程序已退出但句柄还占着这类跨进程残留问题时才需要。4.3 根治方案用IDisposable封装句柄生命周期排查只是第一步根治才是目的。与其在每个业务方法里手写try/catch/finally不如直接封装一个句柄持有类public sealed class AdsHandle : IDisposable { private readonly TcAdsClient _client; private int _handle; public AdsHandle(TcAdsClient client, string symbolName) { _client client; _handle client.CreateVariableHandle(symbolName); } public int Id { get { if (_handle 0) { throw new ObjectDisposedException(AdsHandle); } return _handle; } } public void Dispose() { if (_handle ! 0) { _client.DeleteVariableHandle(_handle); _handle 0; } } }使用的时候using (AdsHandle hCounter new AdsHandle(client, GVL.nCounter)) using (AdsHandle hEnable new AdsHandle(client, GVL.bEnable)) { int nCounter (int)client.ReadAny(hCounter.Id, typeof(int)); bool bEnable (bool)client.ReadAny(hEnable.Id, typeof(bool)); } // 出了using块句柄一定被删除不需要记得手动调用这个模式的优点是业务代码里根本不需要关心删除动作using块结束就自动清理可读性和健壮性同时提升。我把所有上位机项目里的句柄访问都改成这个模式之后句柄泄漏类问题再没出现过。如果你的项目里同时使用了Autofac、Unity这类依赖注入容器还可以把AdsHandle注册成单例之外的生命周期作用域对象让容器帮忙管理释放效果一样。5. 更进一步的资源管理通知句柄与整体连接生命周期5.1 Notification句柄也要删和变量句柄容易混淆的还有一类句柄通知句柄Notification Handle。当你用AddNotification订阅一个变量变化时方法同样会返回一个句柄用于后续的DeleteNotification调用。如果项目里大量使用通知订阅却只在程序退出时统一注销平时反复订阅、取消订阅同样会造成句柄表逐渐膨胀。int hNotify client.AddNotification(GVL.nCounter, OnCounterChanged, 100, NotificationMode.AmsPort); // 业务结束时必须调用删除通知 client.DeleteNotification(hNotify); hNotify 0;这里有个经验通知句柄和变量句柄是两套资源别搞混。变量句柄用DeleteVariableHandle删除通知句柄用DeleteNotification移除。写日志的时候把两类操作分开记录排查起来会快很多。另外通知回调里不要再去做同步阻塞操作ADS的通知线程是很宝贵的资源卡住一次可能会拖垮整个通知链路。5.2 连接断开时的自动清理到底可不可靠前面说过TwinCAT在连接断开时确实会尝试回收该连接创建的句柄和通知但我不建议依赖它理由有三个第一正常Dispose时ADS客户端会发送释放命令PLC按顺序清理这个流程通常没问题但程序崩溃、网络闪断时优雅释放流程可能中断PLC侧的句柄条目会残留到下一次连接甚至更久。第二即使系统能回收周期也是不确定的在回收完成前你重连并创建同名句柄可能会撞上句柄还在的尴尬。第三把资源释放的主动权握在自己手里代码的确定性最好也最容易在代码评审时跟同事讲清楚。所以在封装TcAdsClient的时候我会额外做一个ClearAllHandles方法在Dispose之前把所有已登记句柄和通知统一删除而不是依赖TcAdsClient内部的析构逻辑。你自己掌握主动权和让系统替你兜底是完全不同的两种心态。5.3 从Sample11延伸出的三条代码纪律看完Sample11我给自己定过几条纪律分享出来供参考所有句柄相关操作必须在单一线程内完成创建和删除不要在多个线程里交叉操作同一个句柄避免不可预期的竞态。每次CreateVariableHandle必须配对一次DeleteVariableHandle这个配对关系写进代码评审清单里Reviewer重点检查。句柄创建失败时不要把句柄值当成有效值继续往下传立刻抛异常并记录变量名方便现场定位到底是哪个符号的问题。这三条纪律看着简单真正坚持下来之后ADS通讯相关的疑难杂症少了一大半。再说一个我踩过几次坑之后的体会Sample11教的不只是删除句柄这一行代码而是资源从哪里来就必须到哪里去的工程习惯。ADS通讯里除了句柄还有连接对象、通知回调、数据流缓冲区全都是同样的套路。把这一课吃透你写出来的上位机程序才敢说能在产线上7x24小时扛得住。
