做倍福PLC的项目开发尤其是上位机用C#通过ADS跟TwinCAT通讯的同学一定绕不开官方那套经典的Sample示例。我在一个新项目的上位机模块里要用到写入PLC结构体这个功能就把官方Sample02整个重新啃了一遍。这个示例看着不起眼但它其实是ADS通讯里从读单个变量走向写复杂数据类型的关键台阶涉及.NET Framework环境下TcAdsClient的连接建立、结构体内存布局映射、符号句柄的创建与释放再加上PLC侧类型对应关系每个点都能单独拎出来讲半小时。这篇笔记就是把Sample02从代码到原理给你完整拆开适合刚接触ADS通讯、或者已经跑通了Sample01读数但写结构体时反复踩坑的人。我会尽量按我在实际项目里验证过的思路来写很多细节是官方文档里不会直接告诉你的。1. Sample02在官方示例里的位置它比读写单个变量更接近真实项目1.1 从读变量到写结构体跨度在哪里先理清Beckhoff官方ADS示例的基本排列。通常Sample01负责从PLC读取简单变量比如读一个INT、读一个数组让你跑通连接—读取—断开的最小链路。Sample02则反其道而行专门演示向上位机向PLC写入数据而标题里的重点落在写入PLC结构体。为什么官方要把结构体单独拿出来做示例因为实际项目里几乎没有哪个上位机只写一个单独的数字就完事。常见场景是一台设备上位机要把一整套工艺参数下发到PLC比如目标转速、温度设定、启停标志、设备名称。如果每个变量都单独写一次代码又碎又难维护连接开销也大。更合理的做法是把这些参数定义成一个结构体上位机构造好整个结构体一次ADS通讯写过去PLC侧的结构体变量直接就更新到位。这里也体现了一个心态转变Sample01读数据时你只需要搞清楚从PLC内存哪个位置读、读多少字节。但Sample02写结构体时你手上是一堆不同类型的字段它们按什么顺序排列、每个字段占几个字节、有没有对齐补齐全都会影响写入结果。搞懂这个基本就等于掌握了ADS通讯里最有含金量的一块。1.2 跑通示例需要的环境依赖官方示例通常是以.NET Framework 4.x为基础的Windows工程引用TwinCAT.Ads.dll。当前主流的TwinCAT 3环境里这个DLL可以从C:\TwinCAT\AdsApi\TwinCAT.Ads.dll找到也可以直接通过NuGet安装TwinCAT.Ads包。我用的是NuGet方式省去手动注册和版本不匹配的问题。除了ADS库本身本机PC或工控机上还得保证两件事一是.NET Framework运行库要装好二是TwinCAT系统的Router服务必须跑着。前者听着简单但在市面上很多离线工控机上常出幺蛾子后面会专门讲。后者就是TwinCAT Runtime的ADS路由器它是上位机请求和PLC响应之间的中转站没有它你根本连不上PLC。值得多说一句的是TwinCAT.Ads.dll在.NET Framework 4.x下是兼容的老示例工程只要引用的路径和版本对几乎不用改代码。但如果你是新建的.NET Core/.NET 5以上项目那要注意使用新版ADS NuGet包比如TwinCAT.Ads 6.x接口有些差异。我这次按照标题里的环境要求全程基于.NET Framework控制台工程来复现。2. 写结构体之前必须搞懂三个底层参数AMS NetId、端口号、变量句柄2.1 AMS NetIdPLC在ADS网络里的“门牌号”ADS通讯不是走IP直连而是通过AMS协议。每台参与通讯的设备都有一个AMS NetId它由6个字节组成写法通常像这样192.168.0.77.1.1注意它虽然长得像IP地址但不是IP地址。前四段往往取自设备的IP地址但后面的1.1是AMS路由的额外编号。你可以理解成IP地址是快递员的投递路线AMS NetId是小区里每户人家的门牌号。跨网段通讯时IP变了可能不影响AMS通讯只要NetId不变路由关系就还能维持。获取目标PLC的AMS NetId最直接的方法是打开TwinCAT开发环境在系统托盘的TwinCAT图标上右键找到Router对话框查看或者在System Manager的AMS NetId设置里复制。调试开发机连本机运行时有时可以直接用AmsNetId.Local这种写法不过固定项目里最好还是显式写字符串方便以后把程序部署到别的机器上。有个常见的误解把目标IP地址填进去就万事大吉。实际ADS连接时如果NetId填错哪怕IP是对的也会报找不到目标设备。我第一次做跨网段连接时就遇到这个问题改了半天防火墙才发现是AMS NetId里的后两位写错了当时记成了1.10实际设备是1.1。2.2 端口号851代表哪个PLC运行时AMS端口号用来区分同一台设备上不同的ADS服务。对PLC项目来说记住下面几个就够用端口号服务10000TwinCAT系统服务851PLC1运行时老版本TwinCAT 3和TwinCAT 2都用这个852PLC2运行时500NC轴控制服务官方Sample02写结构体目标只要是PLC1端口就是851。少数情况下TwinCAT 3新版本在PLC实例配置里会对应852甚至853这个以你在开发环境里看到的实例端口为准。判断方法很简单在TwinCAT开发环境里打开PLC实例属性能看到AMS Port号或者直接在在线监视里看符号地址。端口填错的因素我在一个老项目里碰到过现场PLC配置了第二个运行时实例把程序跑在PLC2上上位机仍然按照851去连结果ADS连接能建立因为851上还有一个空壳运行时但变量路径全部报错。所以连接前第一件事永远是确认当前激活的PLC实例是哪一个端口号就对哪一个。2.3 变量句柄为什么官方示例偏爱CreateVariableHandle连接建立之后写入结构体有两种常见路径一种是直接按符号名写比如WriteSymbol(MAIN.stMachineData, data)另一种是先CreateVariableHandle拿到一个整数句柄再按句柄写。为什么Sample02官方推荐句柄方式因为按符号名写入每次都要让ADS路由器去解析一遍符号路径底层要做一次符号表查找。句柄则是连接建立后只解析一次后续每次写入都直接用这个短整数引用目标变量效率和稳定性都高不少。特别是周期性下发数据的场景节省的那点开销在长时间运行里能明显感受到。句柄还有一个隐藏优势它绕开了路径字符串编码之类的坑。你只要在创建句柄时保证变量路径正确后续写入不用再关心路径问题。这也意味着句柄是有上限的用完必须释放否则长时间运行会慢慢耗尽PLC侧的句柄资源导致后面CreateVariableHandle报错。实际调试中这种资源泄漏很难一眼看出来但现象非常典型程序刚启动一切正常跑几小时后开始偶发句柄创建失败。3. 核心代码逐段拆解从连接到写入的完整链路3.1 连接建立与C#侧结构体定义先把PLC侧的一个简单结构体亮出来后面所有映射都围绕着它。在TwinCAT里定义这样一段IEC ST代码TYPE ST_MachineData : STRUCT bEnable : BOOL; // 启停标志 nTargetSpeed : INT; // 目标转速 fTemperature : REAL; // 温度设定 strName : STRING(80); // 设备名称 END_STRUCT END_TYPE VAR_GLOBAL stMachineData : ST_MachineData; END_VAR然后C#侧定义一个镜像结构体。这里最核心的一行是StructLayout特性它直接决定C#结构体在非托管内存里的排列规则using System; using System.Runtime.InteropServices; using TwinCAT.Ads; namespace Sample02_WriteStruct { [StructLayout(LayoutKind.Sequential, Pack 1, CharSet CharSet.Ansi)] public struct ST_MachineData { public byte bEnable; // 对应 BOOL用 byte 模拟 0/1 public short nTargetSpeed; // 对应 INT public float fTemperature; // 对应 REAL [MarshalAs(UnmanagedType.ByValTStr, SizeConst 81)] public string strName; // 对应 STRING(80)含终止符共81字节 } class Program { static TcAdsClient _client; static void Main(string[] args) { _client new TcAdsClient(); try { _client.Connect(192.168.0.77.1.1, 851); int hVar _client.CreateVariableHandle(MAIN.stMachineData); var data new ST_MachineData { bEnable 1, nTargetSpeed 1500, fTemperature 48.5f, strName Line_A_Speed_01 }; _client.Write(hVar, data); _client.ReleaseVariableHandle(hVar); Console.WriteLine(Write OK); } catch (Exception ex) { Console.WriteLine(Error: ex.Message); } finally { _client.Dispose(); } } } }这段代码看着不长但它把ADS写入结构体的三条主线都串起来了连接参数、符号句柄、数据映射。下面分别拆解。3.2 为什么PLC的BOOL字段要用byte而不是bool这块是我实际项目里第一次踩坑的地方值得多说几句。很多人看到PLC端是BOOL第一反应C#里就用bool类型。但这样会出问题.NET里的bool在互操作场景下默认会被Marshal成Win32 BOOL长度是4字节而ADS通讯本质上是把C#结构体按顺序翻译成字节流发给PLC。PLC端的BOOL只占1字节两边长度对不上结构体后续每个字段的偏移量全都会错位。解决办法就是用byte模拟BOOL写入1代表TRUE、0代表FALSE读取时再判断非零即TRUE。这样做有两个好处一是长度严格对齐1字节二是避免了bool在不同.NET Framework版本下的Marshal行为差异。在工业通讯这种对字节流一致性要求极高的场景里宁可牺牲一点类型上的优雅也要保证字节层面的绝对可控。3.3 写入完成后句柄释放和连接关闭的顺序代码里有个细节在Write之后立即ReleaseVariableHandle然后在finally里Dispose客户端。这个顺序是讲究的。句柄属于连接上下文的一部分如果你先Dispose了客户端再释放句柄可能会在释放时找不到上下文而报错即使不报错也会给排查问题添乱。另一个值得养成的习惯是一个TcAdsClient实例不要反复创建销毁。如果程序里既要读又要写尽量共用一个连接只在程序退出时统一Dispose。ADS连接不是轻量操作频繁建连断连在工控机或PLC侧都会留下大量TIME_WAIT状态的Socket时间长了路由性能会下降。我在上位机里见过别人写的一个定时器回调里每次都new TcAdsClient跑了一个月之后系统连接开始不定期超时改成复用连接后才恢复稳定。4. 类型映射和内存布局这一节建议直接收藏4.1 常用PLC类型到C#类型的映射表ADS写入结构体时类型映射的原则是以PLC侧声明的类型为准C#侧找对应字节长度的类型。我把项目里常用的对应关系整理成一张表方便做结构体时直接查PLC类型C#类型字节长度说明BOOLbyte1用0/1表示FALSE/TRUE不要直接用boolBYTE / USINTbyte1无符号8位SINTsbyte1有符号8位INTshort2有符号16位UINT / WORDushort2无符号16位DINTint4有符号32位UDINT / DWORDuint4无符号32位REALfloat4IEEE 754单精度LREALdouble8IEEE 754双精度STRING(n)string / byte[]n1多出的1字节是字符串终止符ARRAY [1..n] OF INTshort[]n*2定长数组C#侧用固定大小数组这张表背后其实只有一个原则ADS写入要么不校验类型要校验就严格按字节长度和符号表定义来。你会发现很多写进去数据完全不对的现场根本原因不是PLC坏了而是类型长度映射错位。4.2 Pack1和默认对齐为什么BOOL会让你前功尽弃C#结构体默认情况下为了让字段访问更快会在某些字段之间插入填充字节这叫做对齐补齐。比如一个int后面跟一个byte默认布局里byte后面可能被补齐到4字节边界。但在ADS通讯里我们需要的是结构体在内存里紧凑排列、一个字节都不多否则发给PLC的字节流里就混入了填充字节PLC按自己的紧凑布局去解释必定错位。解决方式就是在StructLayout里显式指定Pack 1强制按1字节对齐不做任何补齐。这一点对包含BOOL、BYTE、STRING这类非4字节倍数字段的结构体尤其重要。我调试过最典型的场景一个结构体里有BOOL和INT相邻默认布局下写入后PLC侧nTargetSpeed的值总是跟着bEnable一起错乱温度变成NaN名字变成乱码。用Pack1之后所有字段一次全部对上。4.3 字符串和定长数组的两个隐藏细节PLC的STRING(80)不是C#里最多80个字符的字符串这么简单。它在PLC侧实际上是一个长度81字节的定长字符数组最后额外占用一个终止符字节。因此C#侧映射时SizeConst必须写81而不是80。这里非常容易翻车写80最后一个终止符丢失或者写入后字符串截断甚至在部分TwinCAT版本里长度不匹配会被ADS层直接拒绝返回长度错误。定长数组同理。PLC的ARRAY [1..5] OF INT占10字节C#侧要用short[5]映射数组长度必须写5。我见过有人图省事用int[5]去接收结果每个元素都变成8字节等于把整个结构体的长度搞大了一倍。这里还是要回到那张映射表一个萝卜一个坑字节对齐永远是第一优先级。怎么快速验证整个结构体字节数是否对C#侧可以打印Marshal.SizeOf(typeof(ST_MachineData))比如上面的结构体计算结果应该是1248188字节然后到TwinCAT的在线监视里看PLC侧这个结构体变量的长度两边一致才说明布局没有偏差。Console.WriteLine(Marshal.SizeOf(typeof(ST_MachineData)));5. 实测踩坑记录写入成功但PLC侧数据不对按这个顺序排查5.1 变量路径与符号可见性最常见的假成功现象是C#侧Write没有抛异常但PLC侧变量纹丝不动。出现这种情况优先级最高的怀疑对象就是变量路径和符号导出设置。TwinCAT里的变量路径跟你声明的位置有关。声明在某个程序比如MAIN内部路径通常是MAIN.stMachineData声明在VAR_GLOBAL全局变量里路径可能就是stMachineData本身。我建议动手前先到TwinCAT在线监视里选中目标变量看系统里的完整符号名复制过来再用别自己拼。另外一个非常隐蔽的坑是符号可见性设置。TwinCAT 3默认对PLC程序里的变量做了符号导出限制如果你的结构体变量没勾选Symbol属性上位机通过符号名访问时就会报找不到符号。这个问题在多人协作的项目里尤其常见别人的PLC程序里定义了变量但从没注意过符号导出你这边联调半天死活写不进去。检查路径和可见性顺序永远排在怀疑数据类型之前。5.2 用字节偏移的思想定位写入错位当写入后PLC侧数值变成乱码、结构体里前面的字段正常后面的字段全乱这基本可以锁定是布局偏移问题。排查时不要只看表面值要把结构体当成一串字节来看从偏移0开始逐字段核对。举一个实际案例。我的一个结构体里有BOOL、REAL、INT三个字段一开始C#侧用了默认布局没有Pack1。写入后PLC侧温度值完全不对而且目标转速偶尔等于温度的二进制的一部分。按字节偏移展开之后发现原因很清楚C#侧BOOL占了4字节导致REAL字段起始偏移从PLC侧的1变成了4PLC侧把偏移4开始的4个字节当作REAL来解释读到的其实是C#结构体里BOOL加填充再加REAL前两字节的杂糅。这种情况下唯一正确的修复方式就是统一两边布局Pack1、byte模拟BOOL、字段顺序完全一致。5.3 ADS错误码速查711、706、705分别代表什么连接和写入过程中如果收到ADS错误不要慌三个高频错误码可以覆盖绝大部分情况错误码含义常见原因0x711符号不存在变量路径错误、符号未导出、拼写错误0x705数据类型无效C#结构体类型与PLC侧符号类型不匹配0x706数据长度无效结构体总字节数与PLC侧符号长度不一致我遇到0x706最多的时候就是字符串长度漏了终止符那1个字节整个结构体短了1字节ADS底层直接报长度错误。遇到0x711优先检查路径和VAR_GLOBAL声明位置。遇到0x705把C#侧结构体字段挨个跟PLC侧类型对照一遍重点看是不是把INT写成int或者把BOOL写成了bool。5.4 ADS路由不通与环境运行库问题连接不上除了IP和NetId还有个高频原因是开发机跟目标机的ADS路由没有建立。ADS默认使用48898端口做路由器通信Windows防火墙拦截时现象就是Telnet IP都通、但ADS Connect一直超时。排查路径是先在TwinCAT开发环境的Router对话框里看目标机状态是否显示运行再检查网段、防火墙、AMS NetId三段。最后聊一下环境运行库这个事。Sample02这种老示例默认基于.NET Framework如果你部署的机器上运行库版本不对程序会在启动阶段直接抛FileNotFoundException跟ADS代码本身没有任何关系。很多工控机是离线环境在线安装.NET Framework经常报0x80072efe本地安装包装3.5又容易报0x80d03805。我实测下来最稳的方式是用DISM指定本地源目录装3.5dism /online /enable-feature /featurename:NetFx3 /source:D:\sources\sxs /limitaccess4.x系列则直接用官方完整离线安装包。装完之后把TwinCAT.Ads.dll放对位置或者用NuGet还原Sample02基本就能正常启动。5.5 踩过几次坑之后的固定排查习惯每次写入结构体出问题我现在的排查顺序已经固化成一套链路先看连接能不能建立再看变量路径和符号可见性然后用Marshal.SizeOf核对结构体总字节数最后对照映射表逐字段检查类型。这个过程按顺序走下来90%的问题都能在十分钟内定位。比较意外的是我发现很多问题出在参考代码的惯性上。比如有人写习惯了读单个变量写结构体时下意识用了WriteAny(MAIN.stMachineData, data)这种重载照理说也能工作但一旦涉及STRING或数组不同版本ADS库的重载解析可能产生不同的Marshal行为导致测出来时好时坏。所以我个人用下来最稳的还是跟Sample02一模一样的句柄加Value写入方式少绕弯子。再说说扩容方向。结构体写入这条路走通之后数组结构体、嵌套结构体、Notification订阅基本都是同一个套路把C#侧的镜像结构体定义准确其他交给ADS协议。真正要下功夫的永远是类型映射那十几行代码。把这个搞扎实了后面不管接MES下发工艺参数还是做配方管理心里都有底。
C#通过ADS向TwinCAT写入PLC结构体：从Sample02到实战踩坑全解析
做倍福PLC的项目开发尤其是上位机用C#通过ADS跟TwinCAT通讯的同学一定绕不开官方那套经典的Sample示例。我在一个新项目的上位机模块里要用到写入PLC结构体这个功能就把官方Sample02整个重新啃了一遍。这个示例看着不起眼但它其实是ADS通讯里从读单个变量走向写复杂数据类型的关键台阶涉及.NET Framework环境下TcAdsClient的连接建立、结构体内存布局映射、符号句柄的创建与释放再加上PLC侧类型对应关系每个点都能单独拎出来讲半小时。这篇笔记就是把Sample02从代码到原理给你完整拆开适合刚接触ADS通讯、或者已经跑通了Sample01读数但写结构体时反复踩坑的人。我会尽量按我在实际项目里验证过的思路来写很多细节是官方文档里不会直接告诉你的。1. Sample02在官方示例里的位置它比读写单个变量更接近真实项目1.1 从读变量到写结构体跨度在哪里先理清Beckhoff官方ADS示例的基本排列。通常Sample01负责从PLC读取简单变量比如读一个INT、读一个数组让你跑通连接—读取—断开的最小链路。Sample02则反其道而行专门演示向上位机向PLC写入数据而标题里的重点落在写入PLC结构体。为什么官方要把结构体单独拿出来做示例因为实际项目里几乎没有哪个上位机只写一个单独的数字就完事。常见场景是一台设备上位机要把一整套工艺参数下发到PLC比如目标转速、温度设定、启停标志、设备名称。如果每个变量都单独写一次代码又碎又难维护连接开销也大。更合理的做法是把这些参数定义成一个结构体上位机构造好整个结构体一次ADS通讯写过去PLC侧的结构体变量直接就更新到位。这里也体现了一个心态转变Sample01读数据时你只需要搞清楚从PLC内存哪个位置读、读多少字节。但Sample02写结构体时你手上是一堆不同类型的字段它们按什么顺序排列、每个字段占几个字节、有没有对齐补齐全都会影响写入结果。搞懂这个基本就等于掌握了ADS通讯里最有含金量的一块。1.2 跑通示例需要的环境依赖官方示例通常是以.NET Framework 4.x为基础的Windows工程引用TwinCAT.Ads.dll。当前主流的TwinCAT 3环境里这个DLL可以从C:\TwinCAT\AdsApi\TwinCAT.Ads.dll找到也可以直接通过NuGet安装TwinCAT.Ads包。我用的是NuGet方式省去手动注册和版本不匹配的问题。除了ADS库本身本机PC或工控机上还得保证两件事一是.NET Framework运行库要装好二是TwinCAT系统的Router服务必须跑着。前者听着简单但在市面上很多离线工控机上常出幺蛾子后面会专门讲。后者就是TwinCAT Runtime的ADS路由器它是上位机请求和PLC响应之间的中转站没有它你根本连不上PLC。值得多说一句的是TwinCAT.Ads.dll在.NET Framework 4.x下是兼容的老示例工程只要引用的路径和版本对几乎不用改代码。但如果你是新建的.NET Core/.NET 5以上项目那要注意使用新版ADS NuGet包比如TwinCAT.Ads 6.x接口有些差异。我这次按照标题里的环境要求全程基于.NET Framework控制台工程来复现。2. 写结构体之前必须搞懂三个底层参数AMS NetId、端口号、变量句柄2.1 AMS NetIdPLC在ADS网络里的“门牌号”ADS通讯不是走IP直连而是通过AMS协议。每台参与通讯的设备都有一个AMS NetId它由6个字节组成写法通常像这样192.168.0.77.1.1注意它虽然长得像IP地址但不是IP地址。前四段往往取自设备的IP地址但后面的1.1是AMS路由的额外编号。你可以理解成IP地址是快递员的投递路线AMS NetId是小区里每户人家的门牌号。跨网段通讯时IP变了可能不影响AMS通讯只要NetId不变路由关系就还能维持。获取目标PLC的AMS NetId最直接的方法是打开TwinCAT开发环境在系统托盘的TwinCAT图标上右键找到Router对话框查看或者在System Manager的AMS NetId设置里复制。调试开发机连本机运行时有时可以直接用AmsNetId.Local这种写法不过固定项目里最好还是显式写字符串方便以后把程序部署到别的机器上。有个常见的误解把目标IP地址填进去就万事大吉。实际ADS连接时如果NetId填错哪怕IP是对的也会报找不到目标设备。我第一次做跨网段连接时就遇到这个问题改了半天防火墙才发现是AMS NetId里的后两位写错了当时记成了1.10实际设备是1.1。2.2 端口号851代表哪个PLC运行时AMS端口号用来区分同一台设备上不同的ADS服务。对PLC项目来说记住下面几个就够用端口号服务10000TwinCAT系统服务851PLC1运行时老版本TwinCAT 3和TwinCAT 2都用这个852PLC2运行时500NC轴控制服务官方Sample02写结构体目标只要是PLC1端口就是851。少数情况下TwinCAT 3新版本在PLC实例配置里会对应852甚至853这个以你在开发环境里看到的实例端口为准。判断方法很简单在TwinCAT开发环境里打开PLC实例属性能看到AMS Port号或者直接在在线监视里看符号地址。端口填错的因素我在一个老项目里碰到过现场PLC配置了第二个运行时实例把程序跑在PLC2上上位机仍然按照851去连结果ADS连接能建立因为851上还有一个空壳运行时但变量路径全部报错。所以连接前第一件事永远是确认当前激活的PLC实例是哪一个端口号就对哪一个。2.3 变量句柄为什么官方示例偏爱CreateVariableHandle连接建立之后写入结构体有两种常见路径一种是直接按符号名写比如WriteSymbol(MAIN.stMachineData, data)另一种是先CreateVariableHandle拿到一个整数句柄再按句柄写。为什么Sample02官方推荐句柄方式因为按符号名写入每次都要让ADS路由器去解析一遍符号路径底层要做一次符号表查找。句柄则是连接建立后只解析一次后续每次写入都直接用这个短整数引用目标变量效率和稳定性都高不少。特别是周期性下发数据的场景节省的那点开销在长时间运行里能明显感受到。句柄还有一个隐藏优势它绕开了路径字符串编码之类的坑。你只要在创建句柄时保证变量路径正确后续写入不用再关心路径问题。这也意味着句柄是有上限的用完必须释放否则长时间运行会慢慢耗尽PLC侧的句柄资源导致后面CreateVariableHandle报错。实际调试中这种资源泄漏很难一眼看出来但现象非常典型程序刚启动一切正常跑几小时后开始偶发句柄创建失败。3. 核心代码逐段拆解从连接到写入的完整链路3.1 连接建立与C#侧结构体定义先把PLC侧的一个简单结构体亮出来后面所有映射都围绕着它。在TwinCAT里定义这样一段IEC ST代码TYPE ST_MachineData : STRUCT bEnable : BOOL; // 启停标志 nTargetSpeed : INT; // 目标转速 fTemperature : REAL; // 温度设定 strName : STRING(80); // 设备名称 END_STRUCT END_TYPE VAR_GLOBAL stMachineData : ST_MachineData; END_VAR然后C#侧定义一个镜像结构体。这里最核心的一行是StructLayout特性它直接决定C#结构体在非托管内存里的排列规则using System; using System.Runtime.InteropServices; using TwinCAT.Ads; namespace Sample02_WriteStruct { [StructLayout(LayoutKind.Sequential, Pack 1, CharSet CharSet.Ansi)] public struct ST_MachineData { public byte bEnable; // 对应 BOOL用 byte 模拟 0/1 public short nTargetSpeed; // 对应 INT public float fTemperature; // 对应 REAL [MarshalAs(UnmanagedType.ByValTStr, SizeConst 81)] public string strName; // 对应 STRING(80)含终止符共81字节 } class Program { static TcAdsClient _client; static void Main(string[] args) { _client new TcAdsClient(); try { _client.Connect(192.168.0.77.1.1, 851); int hVar _client.CreateVariableHandle(MAIN.stMachineData); var data new ST_MachineData { bEnable 1, nTargetSpeed 1500, fTemperature 48.5f, strName Line_A_Speed_01 }; _client.Write(hVar, data); _client.ReleaseVariableHandle(hVar); Console.WriteLine(Write OK); } catch (Exception ex) { Console.WriteLine(Error: ex.Message); } finally { _client.Dispose(); } } } }这段代码看着不长但它把ADS写入结构体的三条主线都串起来了连接参数、符号句柄、数据映射。下面分别拆解。3.2 为什么PLC的BOOL字段要用byte而不是bool这块是我实际项目里第一次踩坑的地方值得多说几句。很多人看到PLC端是BOOL第一反应C#里就用bool类型。但这样会出问题.NET里的bool在互操作场景下默认会被Marshal成Win32 BOOL长度是4字节而ADS通讯本质上是把C#结构体按顺序翻译成字节流发给PLC。PLC端的BOOL只占1字节两边长度对不上结构体后续每个字段的偏移量全都会错位。解决办法就是用byte模拟BOOL写入1代表TRUE、0代表FALSE读取时再判断非零即TRUE。这样做有两个好处一是长度严格对齐1字节二是避免了bool在不同.NET Framework版本下的Marshal行为差异。在工业通讯这种对字节流一致性要求极高的场景里宁可牺牲一点类型上的优雅也要保证字节层面的绝对可控。3.3 写入完成后句柄释放和连接关闭的顺序代码里有个细节在Write之后立即ReleaseVariableHandle然后在finally里Dispose客户端。这个顺序是讲究的。句柄属于连接上下文的一部分如果你先Dispose了客户端再释放句柄可能会在释放时找不到上下文而报错即使不报错也会给排查问题添乱。另一个值得养成的习惯是一个TcAdsClient实例不要反复创建销毁。如果程序里既要读又要写尽量共用一个连接只在程序退出时统一Dispose。ADS连接不是轻量操作频繁建连断连在工控机或PLC侧都会留下大量TIME_WAIT状态的Socket时间长了路由性能会下降。我在上位机里见过别人写的一个定时器回调里每次都new TcAdsClient跑了一个月之后系统连接开始不定期超时改成复用连接后才恢复稳定。4. 类型映射和内存布局这一节建议直接收藏4.1 常用PLC类型到C#类型的映射表ADS写入结构体时类型映射的原则是以PLC侧声明的类型为准C#侧找对应字节长度的类型。我把项目里常用的对应关系整理成一张表方便做结构体时直接查PLC类型C#类型字节长度说明BOOLbyte1用0/1表示FALSE/TRUE不要直接用boolBYTE / USINTbyte1无符号8位SINTsbyte1有符号8位INTshort2有符号16位UINT / WORDushort2无符号16位DINTint4有符号32位UDINT / DWORDuint4无符号32位REALfloat4IEEE 754单精度LREALdouble8IEEE 754双精度STRING(n)string / byte[]n1多出的1字节是字符串终止符ARRAY [1..n] OF INTshort[]n*2定长数组C#侧用固定大小数组这张表背后其实只有一个原则ADS写入要么不校验类型要校验就严格按字节长度和符号表定义来。你会发现很多写进去数据完全不对的现场根本原因不是PLC坏了而是类型长度映射错位。4.2 Pack1和默认对齐为什么BOOL会让你前功尽弃C#结构体默认情况下为了让字段访问更快会在某些字段之间插入填充字节这叫做对齐补齐。比如一个int后面跟一个byte默认布局里byte后面可能被补齐到4字节边界。但在ADS通讯里我们需要的是结构体在内存里紧凑排列、一个字节都不多否则发给PLC的字节流里就混入了填充字节PLC按自己的紧凑布局去解释必定错位。解决方式就是在StructLayout里显式指定Pack 1强制按1字节对齐不做任何补齐。这一点对包含BOOL、BYTE、STRING这类非4字节倍数字段的结构体尤其重要。我调试过最典型的场景一个结构体里有BOOL和INT相邻默认布局下写入后PLC侧nTargetSpeed的值总是跟着bEnable一起错乱温度变成NaN名字变成乱码。用Pack1之后所有字段一次全部对上。4.3 字符串和定长数组的两个隐藏细节PLC的STRING(80)不是C#里最多80个字符的字符串这么简单。它在PLC侧实际上是一个长度81字节的定长字符数组最后额外占用一个终止符字节。因此C#侧映射时SizeConst必须写81而不是80。这里非常容易翻车写80最后一个终止符丢失或者写入后字符串截断甚至在部分TwinCAT版本里长度不匹配会被ADS层直接拒绝返回长度错误。定长数组同理。PLC的ARRAY [1..5] OF INT占10字节C#侧要用short[5]映射数组长度必须写5。我见过有人图省事用int[5]去接收结果每个元素都变成8字节等于把整个结构体的长度搞大了一倍。这里还是要回到那张映射表一个萝卜一个坑字节对齐永远是第一优先级。怎么快速验证整个结构体字节数是否对C#侧可以打印Marshal.SizeOf(typeof(ST_MachineData))比如上面的结构体计算结果应该是1248188字节然后到TwinCAT的在线监视里看PLC侧这个结构体变量的长度两边一致才说明布局没有偏差。Console.WriteLine(Marshal.SizeOf(typeof(ST_MachineData)));5. 实测踩坑记录写入成功但PLC侧数据不对按这个顺序排查5.1 变量路径与符号可见性最常见的假成功现象是C#侧Write没有抛异常但PLC侧变量纹丝不动。出现这种情况优先级最高的怀疑对象就是变量路径和符号导出设置。TwinCAT里的变量路径跟你声明的位置有关。声明在某个程序比如MAIN内部路径通常是MAIN.stMachineData声明在VAR_GLOBAL全局变量里路径可能就是stMachineData本身。我建议动手前先到TwinCAT在线监视里选中目标变量看系统里的完整符号名复制过来再用别自己拼。另外一个非常隐蔽的坑是符号可见性设置。TwinCAT 3默认对PLC程序里的变量做了符号导出限制如果你的结构体变量没勾选Symbol属性上位机通过符号名访问时就会报找不到符号。这个问题在多人协作的项目里尤其常见别人的PLC程序里定义了变量但从没注意过符号导出你这边联调半天死活写不进去。检查路径和可见性顺序永远排在怀疑数据类型之前。5.2 用字节偏移的思想定位写入错位当写入后PLC侧数值变成乱码、结构体里前面的字段正常后面的字段全乱这基本可以锁定是布局偏移问题。排查时不要只看表面值要把结构体当成一串字节来看从偏移0开始逐字段核对。举一个实际案例。我的一个结构体里有BOOL、REAL、INT三个字段一开始C#侧用了默认布局没有Pack1。写入后PLC侧温度值完全不对而且目标转速偶尔等于温度的二进制的一部分。按字节偏移展开之后发现原因很清楚C#侧BOOL占了4字节导致REAL字段起始偏移从PLC侧的1变成了4PLC侧把偏移4开始的4个字节当作REAL来解释读到的其实是C#结构体里BOOL加填充再加REAL前两字节的杂糅。这种情况下唯一正确的修复方式就是统一两边布局Pack1、byte模拟BOOL、字段顺序完全一致。5.3 ADS错误码速查711、706、705分别代表什么连接和写入过程中如果收到ADS错误不要慌三个高频错误码可以覆盖绝大部分情况错误码含义常见原因0x711符号不存在变量路径错误、符号未导出、拼写错误0x705数据类型无效C#结构体类型与PLC侧符号类型不匹配0x706数据长度无效结构体总字节数与PLC侧符号长度不一致我遇到0x706最多的时候就是字符串长度漏了终止符那1个字节整个结构体短了1字节ADS底层直接报长度错误。遇到0x711优先检查路径和VAR_GLOBAL声明位置。遇到0x705把C#侧结构体字段挨个跟PLC侧类型对照一遍重点看是不是把INT写成int或者把BOOL写成了bool。5.4 ADS路由不通与环境运行库问题连接不上除了IP和NetId还有个高频原因是开发机跟目标机的ADS路由没有建立。ADS默认使用48898端口做路由器通信Windows防火墙拦截时现象就是Telnet IP都通、但ADS Connect一直超时。排查路径是先在TwinCAT开发环境的Router对话框里看目标机状态是否显示运行再检查网段、防火墙、AMS NetId三段。最后聊一下环境运行库这个事。Sample02这种老示例默认基于.NET Framework如果你部署的机器上运行库版本不对程序会在启动阶段直接抛FileNotFoundException跟ADS代码本身没有任何关系。很多工控机是离线环境在线安装.NET Framework经常报0x80072efe本地安装包装3.5又容易报0x80d03805。我实测下来最稳的方式是用DISM指定本地源目录装3.5dism /online /enable-feature /featurename:NetFx3 /source:D:\sources\sxs /limitaccess4.x系列则直接用官方完整离线安装包。装完之后把TwinCAT.Ads.dll放对位置或者用NuGet还原Sample02基本就能正常启动。5.5 踩过几次坑之后的固定排查习惯每次写入结构体出问题我现在的排查顺序已经固化成一套链路先看连接能不能建立再看变量路径和符号可见性然后用Marshal.SizeOf核对结构体总字节数最后对照映射表逐字段检查类型。这个过程按顺序走下来90%的问题都能在十分钟内定位。比较意外的是我发现很多问题出在参考代码的惯性上。比如有人写习惯了读单个变量写结构体时下意识用了WriteAny(MAIN.stMachineData, data)这种重载照理说也能工作但一旦涉及STRING或数组不同版本ADS库的重载解析可能产生不同的Marshal行为导致测出来时好时坏。所以我个人用下来最稳的还是跟Sample02一模一样的句柄加Value写入方式少绕弯子。再说说扩容方向。结构体写入这条路走通之后数组结构体、嵌套结构体、Notification订阅基本都是同一个套路把C#侧的镜像结构体定义准确其他交给ADS协议。真正要下功夫的永远是类型映射那十几行代码。把这个搞扎实了后面不管接MES下发工艺参数还是做配方管理心里都有底。
