C#上位机与倍福PLC通信：TwinCAT.Ads.dll实例详解

简介面向工控开发者的C#与倍福PLC通信实例源码基于TwinCAT.Ads.dll库实现上位机与PLC的数据读写交互适合新手了解ADS通信流程也为有经验人员提供可直接改造的工程模板。压缩包共61个文件约1.51MB核心包含12个C#源文件、3个DLL动态库和3个EXE可执行程序附带docx技术文档、PLC程序文件DFR/SDB/TPY等以及sln/csproj/settings等项目配置目录结构清晰便于按源码、文档、PLC侧分层学习。资源内有两份通讯说明文档分别讲解TwinCAT ADS通讯原理与WINCE系统下的C#实现方式同时PLC侧提供变量表、程序备份等文件配合C#读写示例可深入理解通信细节。已有1519人学习下载适合需要快速搭建C#与倍福PLC通信环境、进行项目二次开发或排查通信问题的工控技术人员。1. TwinCAT.Ads.dll用 C# 上位机跟倍福 PLC 通信比想象中简单做上位机的人迟早会碰到倍福设备上用 Beckhoff PLC 做运动控制上位机这边要读状态、写参数、采数据。很多人第一反应是 OPC UA但现场工程师更常用的其实是 ADS——也就是 TwinCAT.Ads.dll 这套原生通信库。我最初也以为要配一堆路由和证书结果发现 C# 里引用一个 DLL、填对 AMS NetId 和端口号几十行代码就能把所有变量读上来。这份实例源码解决的就是这件事用 C# 通过 TwinCAT.Ads.dll 跟倍福 PLC 通信覆盖连接、读写、通知和断线重连适合刚接触倍福的 C# 上位机开发也适合老手拿来当通信层模板。2. 先把地基打牢ADS 协议选型、引用 DLL 与连接三要素2.1 为什么是 ADS 而不是 OPC UA 或 Modbus倍福的 TwinCAT 系统对外通信不止一条路Modbus TCP 简单但只能读写寄存器OPC UA 跨平台能力强但配置重而 ADSAutomation Device Specification是倍福的“母语”——它直接跑在 AMS 路由器上能访问 PLC 变量、NC 轴、系统状态甚至实时任务吞吐和延迟都优于 Modbus。我一般的原则是如果上位机就在同一台 IPC 上或者只在厂区局域网内、不涉及多品牌设备统一采集直接用 ADS 最省事。它不需要在 PLC 里额外加功能块只要 TwinCAT 的 Router 在跑变量就能被外部读到。而且 TwinCAT.Ads.dll 直接暴露给 .NET底层 Native 调用被封好了C# 里用起来跟操作普通类库没区别。有个容易忽略的点ADS 通信的数据类型是强绑定的。你读一个变量C# 这边的类型必须和 PLC 侧严格对应否则读出来的值就是乱的。这一点后面第 5 章会专门讲。2.2 引用 TwinCAT.Ads.dll两种方式别混着用第一种是通过 NuGet适合新工程。Visual Studio 里打开包管理器搜索并安装dotnet add package TwinCAT.Ads装完后确认引用里多出了TwinCAT.Ads这个程序集命名空间是TwinCAT.Ads核心类是TcAdsClient。NuGet 版本会跟随 TwinCAT 版本迭代比如 TwinCAT 3 对应 4.x 以上的包接口变化不大。第二种是手动引用 DLL——老工程师更习惯这种方式因为现场电脑可能没外网。倍福安装 TwinCAT 后在安装目录下能找到TwinCAT.Ads.dll一般路径类似于C:\TwinCAT\AdsApi\TwinCAT.Ads.dll把它复制到项目目录然后在解决方案里右键“添加引用”→“浏览”选到这个 DLL。需要注意如果目标框架是 .NET Framework 4.x老版本 DLL 直接能用如果是 .NET Core 或 .NET 5建议优先走 NuGet手动引用的 DLL 可能缺少 Runtime 兼容层。引用完成后的第一步先创建一个客户端实例验证能 new 出来using TwinCAT.Ads; // 创建 ADS 客户端 TcAdsClient client new TcAdsClient(); // 验证版本 Console.WriteLine(TwinCAT.Ads 版本: typeof(TcAdsClient).Assembly.GetName().Version);这里有个小坑TcAdsClient内部封装了 Native 层在 x64 系统上如果项目编译成 AnyCPU运行时可能加载不了 32 位版 Native 组件。我一般直接把项目编译目标设为 x86或者统一用 x64 的新版 NuGet 包千万别在同一个进程里混用两套 DLL。2.3 连接三要素AMS NetId、端口号和路由表跟普通 Socket 通信不一样ADS 连接不是填 IP 加端口那么简单它要求三个参数AMS NetId、目标端口、以及本机到目标机的 AMS 路由关系。AMS NetId 类似一台机器的“身份证”格式是六个数字例如192.168.1.1.1.1。在 TwinCAT 3 里打开 System Manager或者 TwinCAT XAE 的 “TwinCAT”→“System”→“Real-Time”可以找到当前 IPC 的 AMS NetId。如果是虚拟 PLCNetId 可能与 IP 不同要去看 TwinCAT 的路由配置。端口号决定了你访问的是 PLC 里的哪个 Runtime。默认常用端口如下目标端口号说明PLC Runtime 1851TwinCAT 3 最常见PLC Runtime 2852第二个 PLC 实例System Service10000访问系统状态TwinCAT 2 PLC801老项目的默认端口连接的最小代码是// 本机连接 client.Connect(127.0.0.1.1.1, 851); // 远程 IPC 连接 // client.Connect(192.168.1.10.1.1, 851);注意远程连接不是填 IP 而是填 AMS NetIdIP 地址本身只用于路由发现。本机调试经常用127.0.0.1.1.1这个固定 NetId指向 TwinCAT 在本机的 ADS 服务。路由表是第三个隐性条件。AMS 路由不通代码写得再对也连不上。TwinCAT 3 里要在“Tasks”或“Router”中 “Add Route”填入目标机的 AMS NetId 和 IP。对于本机连接路由通常是自动存在的远程连接没配路由会直接报0x10060超时。这个坑现场很常见我在第 5 章会专门演示排查方式。3. 读写变量的三种姿势ReadSymbol、ReadAny 与通知回调3.1 先理解 TwinCAT 符号表机制ADS 读写不是按地址而是按符号名。PLC 程序里声明过的全局变量比如MAIN.nSpeed、MAIN.bRunning只要在 TwinCAT 环境里激活了配置符号表就生成了。C# 这边通过符号名直接访问不用关心变量在内存里的具体地址也不用管 PLC 是否重新编译过。但有一个前提PLC 程序在线变更之后符号表的句柄Handle会变。如果上位机缓存了句柄需要在每次重连或者检测到 Online Change 后重新获取。这一点新手容易忽略表现出来就是连上了但读不到数据或者报“符号未找到”。3.2 ReadSymbol按符号名直接读最简单的方式是ReadSymbol传变量名进去返回object再强转成对应类型。读一个 INT 变量示例// 读取 PLC 变量 MAIN.nSpeed类型 INT object raw client.ReadSymbol(MAIN.nSpeed); short speed (short)raw; Console.WriteLine($当前速度: {speed});ReadSymbol内部会自动查句柄、读值、再释放句柄。优点是代码短、好懂适合低频读取缺点是每次调用都要走一遍符号查找和句柄分配高频轮询时性能不够好。高频场景我一般改用ReadAny它接受一个Type参数返回强类型对象// 使用 ReadAny 读取减少一次强制转换 short speed (short)client.ReadAny(MAIN.nSpeed, typeof(short), new int[] { });第三个参数new int[] { }是给数组或结构体用的维度信息标量类型传空数组就行。如果读的是数组比如MAIN.arrData是一个ARRAY[0..9] OF INT写法变成int[] dims new int[] { 1, 10 }; // 第一维长度 10 ushort[] data (ushort[])client.ReadAny(MAIN.arrData, typeof(int), dims);这里typeof要和 PLC 的数组元素类型对应PLC 的INT在 C# 里是shortWORD是ushort。下表是我常用的映射关系PLC 类型C# 类型字节数注意事项BOOLbool1不能直接读成 byteBYTEbyte1WORDushort2无符号INTshort2有符号易错DINTint4REALfloat4注意精度LREALdouble8STRING(n)stringn1要匹配长度3.3 写变量WriteSymbol 与 WriteAny写变量同样分两种。低频率、图省事用WriteSymbol// 写入一个 INT 变量 client.WriteSymbol(MAIN.nTargetSpeed, (short)1200);写入频率高或者要写数组用WriteAnyshort[] targets new short[] { 100, 200, 300 }; client.WriteAny(MAIN.arrTargets, targets, new int[] { 3 });写变量时最容易翻车的点是类型不匹配比如 PLC 变量是INT你在 C# 里传了int底层数据宽度不同写入后 PLC 侧看到的可能是错的甚至写越界。建议每次写之前先看 PLC 变量声明类型再对应 C# 类型不要“看着像就写”。3.4 通知回调不想主动轮询时的替代方案轮询的代价是 CPU 和网络包占用高。如果只是监控几个关键变量可以用 ADS 的 Notification 机制让 PLC 侧在变量变化时主动推给上位机。// 创建通知监控 MAIN.nSpeed值变化且超过 1ms 时触发 TcAdsNotification notification client.CreateNotification( MAIN.nSpeed, // 符号名 typeof(short), // 数据类型 1, // 通知周期ms TcAdsNotificationMode.ValueChange // 触发模式 ); notification.Notification OnSpeedNotification;回调函数里拿到的数据和轮询一样但不要在里面做耗时操作private void OnSpeedNotification(object sender, TcAdsNotificationExEventArgs e) { // e.Data 是强类型数据 short speed (short)e.Data; Console.WriteLine($通知回调速度: {speed}); }注意CreateNotification有重载部分 DLL 版本里类名是NotificationClient在 4.x 版本中统一为TcAdsNotification。通知周期设得太小比如 1ms而 PLC 刷新周期又达不到会出现大量重复通知用TcAdsNotificationMode.ValueChange模式可以挡掉连续同值的情况。4. 一个可落地的通信实例连接、心跳、断线重连与 UI 刷新4.1 工程结构与线程模型源码包里的实例是一个 WinForms 工程文件组织大致是AdsDemo/ ├── AdsDemo.sln ├── MainForm.cs // 主界面 显示逻辑 ├── AdsClientManager.cs // 通信封装连接、读写、心跳、重连 └── app.config // 配置 AMS NetId、端口号WinForms 里最忌讳在 UI 线程里做耗时网络操作。我一般把 ADS 连接和轮询丢到后台线程UI 只负责显示。这样即使 PLC 断开界面也不会卡死。核心通信封装类AdsClientManager的骨架如下public class AdsClientManager { private TcAdsClient _client; private readonly string _netId; private readonly int _port; private System.Threading.Timer _heartbeatTimer; private bool _isConnected; public event Actionbool ConnectionChanged; public event Actionshort SpeedUpdated; public AdsClientManager(string netId, int port) { _netId netId; _port port; _client new TcAdsClient(); } public bool Connect() { try { _client.Connect(_netId, _port); _isConnected true; StartHeartbeat(); ConnectionChanged?.Invoke(true); return true; } catch (Exception ex) { ConnectionChanged?.Invoke(false); return false; } } }Connect方法里_client.Connect是同步阻塞的超时大约 5~10 秒。界面调用时应该放到 Task 里否则点击“连接”按钮后界面会假死。4.2 封装心跳与自动重连ADS 连接有一个特点物理断开后客户端对象并不知道要等下次读写才报异常。所以我加了一个 3 秒一次的“心跳”读操作读一个几乎不变的变量比如MAIN.bReady读失败就触发重连。private void HeartbeatTick(object state) { if (!_isConnected) return; try { // 读一个轻量级状态变量做健康检查 bool ready (bool)_client.ReadSymbol(MAIN.bReady); if (!ready) { // PLC 可能处于停止状态不需要断线但记录日志 Console.WriteLine(PLC 未准备就绪); } } catch (Exception) { _isConnected false; ConnectionChanged?.Invoke(false); // 触发重连 Reconnect(); } }Reconnect要做几件事先Dispose旧客户端重新 new 一个再次Connect成功后通知界面更新状态。重连间隔建议至少 5 秒不要写成死循环否则 TwinCAT Router 会被频繁的连接请求刷出日志报错。private void Reconnect() { Task.Run(async () { await Task.Delay(5000); try { _client.Dispose(); _client new TcAdsClient(); bool ok Connect(); Console.WriteLine(ok ? 重连成功 : 重连失败等待下轮); } catch (Exception ex) { Console.WriteLine(重连异常: ex.Message); } }); }4.3 UI 线程刷新与数据绑定后台读到的数据要安全地更新到界面。最简单的方式是 Control 的BeginInvokepublic void UpdateSpeedUI(short speed) { if (this.InvokeRequired) this.BeginInvoke(new Action(() labelSpeed.Text speed.ToString())); else labelSpeed.Text speed.ToString(); }高频刷新时BeginInvoke会把委托排队导致界面反应越来越慢。解决方法是设一个刷新节流比如积攒 5 个值再刷一次或者只在值变化超过阈值时刷。我的习惯是数据采集显示用BindingSource 定时刷新通信数据只写内存UI 每秒取一次快照。这样 CPU 占用可以从 30% 降到 5% 以下界面也不会抖。实例工程里默认读取的是MAIN.nSpeed和MAIN.bRunning这两个变量你拿到源码后先改成自己 PLC 里的变量名再改 AMS NetId 和端口就能跑通。整个通信层和 UI 是分离的直接替换到你的工控项目里也过得去。5. 避坑ADS 通信常见的五个翻车现场以下每条都是我在现场或办公室实际踩过的坑按“现象→原因→解决”整理。5.1 连接超时0x10060或10060现象调用Connect等待十几秒后抛异常错误码是10060英文提示 “Timeout”。原因绝大多数是 AMS 路由没配对不是代码问题。解决用 TwinCAT 3 的“Add Route”功能把上位机的 IP 和 AMS NetId 添加到目标 IPC 的路由表里。工控领域有个偏“玄学”的经验先把两台机器在 Windows 防火墙里放行 TwinCAT 相关端口比如 48898再用命令pingAMS NetId 验证连通性最后才回去查代码。5.2 读出来的值是 0 或者完全不对现象代码没报错但读到的数值和 PLC 侧不一致比如 PLC 里是 100C# 读到的是 0 或 25600。原因数据类型不匹配。PLC 的INT在 C# 里对应short如果强转成int高 16 位补零或截断值自然不对。解决读之前先确认 PLC 变量类型对照第 3 章的映射表选 C# 类型。如果实在不确定先读成object再打印GetType()看一眼实际运行时类型。5.3 符号未找到0x710/ Error 1808现象原来能跑的代码Online Change 之后突然报符号未找到。原因PLC 程序在线变更后符号表的 Handle 被重建但TcAdsClient内部缓存的 Handle 没更新。解决不要长期持有ReadAny的句柄返回值。如果用了client.GetHandleByComment或ReadByHandle要在每次重连后重新获取句柄。最简单的办法是老老实实用ReadSymbol/WriteSymbol让库内部每次自动查符号表性能损失在高频场景之外可接受。5.4 Notification 回调不触发现象CreateNotification成功但回调一次都没有。原因最常见的是通知周期没对齐、目标 Runtime 没启动、或者变量没有变化。ADS 的 Notification 在变量不变时不会触发这是设计行为另外部分版本里TcAdsNotificationMode.ValueChange要求在 TwinCAT 侧打开 ADS 相应的 Notify 选项。解决先用轮询方式确认变量确实有变化再检查通知周期单位是 ms不能为 0最后把模式改成Cyclic试试。如果 Cyclic 能触发、ValueChange 不触发就是变量刷新周期比通知周期还大把通知周期拉大到 2 倍于 PLC 任务周期即可。5.5 建了多个 TcAdsClient 实例导致 Router 卡顿现象程序开了多个窗口每个窗口一个TcAdsClient运行一段时间后 PLC 端点响应变慢。原因每个客户端都会在 TwinCAT Router 里建立一个独立会话会话数太多会占用资源另外部分客户端没有释放连接泄漏。解决整个进程尽量只维护一个TcAdsClient全局实例所有窗口共享它每次Dispose后把引用置 null。检查有没有泄漏可以看 TwinCAT 的“Router → Connections”面板连接数会明显超标。6. 进阶把通信层封装成可复用的服务类当项目超过三四个设备时裸写TcAdsClient就不可维护了。我习惯在实例源码基础上再包一层IAdsService把连接配置、心跳、重连、日志统一收口业务代码只关心接口。public interface IAdsService { bool Start(); void Stop(); T ReadT(string symbolName); void WriteT(string symbolName, T value); IObservableT ObservableT(string symbolName, int cycle); }这样的好处是上层代码不直接触碰 ADS单元测试时可以注入 mock 实现。真实采集逻辑全部走接口换协议栈时不用改业务代码只是换一个实现类。验证这层封装是否靠谱我通常不直接连 PLC而是用 TwinCAT XAE 里的“符号表监控”功能把变量先强制改几个值观察上位机是否收到、耗时多少。再配合代码里的日志时间戳能清楚看到轮询周期是否稳定。有一个我自己的铁律每次改完 PLC 程序上位机这边必须重启通信层一次不重启就会踩 5.3 的符号未找到坑。从那以后我每次现场调试都会在界面上留一个“重置通信”按钮任何诡异问题第一件事先点它而不是反复断点调试。希望这招对你有用——这份源码里的封装思路和读写方式拿到手改动即可用。本文还有配套的精品资源点击获取