写 CoDeSys 的人大概都有过这种经历程序写得挺顺逻辑也能跑但一上真机就出些说不清的鬼事。比如模拟量输入偶尔跳出 65535或者计数器到了某个数之后突然变成负数又或者在线监控的时候发现一个看起来不大的结构体变量实际占的内存比预估大了一圈。这些问题的根源多半不在逻辑而在数据类型。这篇内容就把 CoDeSys 里的数据类型从头到尾捋一遍。不是教科书式的罗列而是结合我实际调试、优化、改错的经验重点讲清楚两件事怎么选类型以及怎么在数据类型这个层面把内存省下来。适合正在入门 CoDeSys、以及已经在用但没系统整理过类型体系的朋友。1. 选型方法论先回答范围、精度、保持性三个问题很多新手写 PLC 程序习惯先想逻辑再补变量变量类型随便点一个顺手的比如计数用 INT、速度用 REAL、状态用 BOOL。这个顺序其实反了。我在项目里吃过亏之后现在每条数据都要先做一道“三问”数值范围是多少精度要求多高掉电之后要不要保留这三个问题定了类型基本就能锁定——是 INT 还是 DINT是 REAL 还是 LREAL是普通变量还是 RETAIN全在这一步解决。1.1 先算数值范围INT 溢出是 PLC 里最隐蔽的故障INT 的范围是 -32768 到 32767这个数字大家心里都有数但真用起来很多人还是会“想当然”。我调试过一台计数设备生产节拍很快计数变量用了 INT刚开始正常跑了几个小时突然报警查到最后是计数值超过了 32767翻成了负数逻辑判断全部乱套。这个错从语法层面根本看不出来CoDeSys 不会因为你可能溢出就给你编译报错。所以我的习惯是任何变量先算一遍“最大可能值 量程上限 × 安全裕量”再决定位数。计数累计、脉冲累计、配方总数量这类会一直向上加的值直接上 DINT范围能到正负 21 亿多普通工业场景用到头都难。只有那种明确知道自己边界、比如单次扫描内的临时序号、互锁用的编号才用 INT 省内存。还有一点容易被忽略混合运算时的隐式转换。INT 乘 INT如果结果超出 32767在 CoDeSys 中不会自动变成 DINT你得自己声明 DINT或者用类型转换函数包一层。我见过有人写nTotal : iA * iB;两个 INT 相乘结果溢出排查了很久。正确写法是至少把其中一个转成 DINTnTotal : DINT; iA, iB : INT; nTotal : DINT_TO_DINT(iA) * iB; // 实际上 DINT_TO_DINT 没必要但需要让编译器按 DINT 运算更稳妥的做法是从源头就把参与大数运算的变量声明成 DINT省去后面一堆转换和踩坑。1.2 精度要求决定实数类型REAL 与 LREAL 的真正分界线这个问题我在流量累计和设备位置计算上翻过车。REAL 在 CoDeSys 里占 4 字节大约 7 位有效十进制数字LREAL 占 8 字节大约 15 到 17 位有效数字。看起来 REAL 够用但浮点数的“够用”和整数不一样——它有累加误差。我调过一套配料系统流量累计用 REAL 存累计值设备连续跑了两周累计值到了几十万量级这时候每次扫描往里加零点几升数字几乎纹丝不动。原因就是浮点数的有效数字只有 7 位大数和小数相加时小数的低位被吞掉了。这不是 CoDeSys 的问题是 IEEE 754 浮点数的通病。累计、积分、需要长期累加的量老老实实用 LREAL。模拟量百分比、PID 中间变量、速度设定这种“实时刷新、不长期累加”的REAL 完全够用没必要上 LREAL 白白多占 4 字节。另外要注意目标控制器的浮点处理能力。有些低成本的控制器没有硬件浮点单元LREAL 运算靠软件模拟执行一个小数运算可能比 REAL 慢好几倍。控制周期紧张的时候这也会成为瓶颈。1.3 保持性要求普通变量、RETAIN 从开始就要分开规划第三个问题最容易被项目需求阶段忽略。设备掉电重启之后哪些数据要恢复到断电前的值操作模式、配方号、累计产量、当前暂停状态……这些都要 RETAIN而临时计算值、上电标志、扫描计数这种掉电后清零反而更安全。我的做法是写数据字典的时候专门列一列“掉电保持”这一栏把每个变量的需求写清楚然后再分配到普通变量区还是保持区。因为 RETAIN 变量和非 RETAIN 变量在内存里处于不同区域混着放不光影响内存规划还会让在线修改变得很难搞。这个问题在第 4 节单独展开。2. 一张类型速查表外加最容易用错的四组对比把标准类型一张表列清楚选型的时候对着查就行。注意下面标注的是 CoDeSys 里最常见的位宽和范围实际控制器可能略有差异但 IEC 61131-3 标准下基本一致。类型位宽范围 / 精度典型场景常见误用BOOL1字节TRUE / FALSE开关量、状态位、启停控制以为一个 BOOL 只占 1 bitBYTE1字节0~255串口字节、小型状态字用来存有符号数WORD2字节0~65535通信协议状态字、寄存器原值存负数、做数值计算INT2字节-32768~32767普通计数、转速、IO 映射存会超过 32767 的累计值DINT4字节-21亿~21亿累计量、大数计算、时间戳无符号逻辑字混用REAL4字节约7位有效数字PID、模拟量百分比、速度浮点长期累加导致误差LREAL8字节约15~17位有效数字流量累计、重力补偿等精度敏感运算所有浮点都上 LREALTIME4字节毫秒计最大约49天延时、扫描周期计时拿 INT 存毫秒数TOD / DATE / DT4字节时间点日志、配方时间戳类型间直接赋值STRING1字节/字符显式指定长度HMI 文本、报警信息默认长度过大浪费内存WSTRING2字节/字符显式指定长度多语言界面、Unicode不知道比 STRING 大一倍2.1 BOOL 不省位BYTE 也要省着用新手最容易误解的就是 BOOL。在 CoDeSys 里一个 BOOL 变量实际占用 1 个字节不是 1 个位。所以如果你为了省内存写了 100 个 BOOL 变量放一堆标志位那其实是 100 字节。真要压缩位级存储得用 BYTE、WORD、DWORD 自己管理位或者用联合体把一组 BOOL 映射到一个 BYTE 上。这个在第 3 节讲内存优化时具体演示。BYTE 和 WORD 的误用也常见。BYTE 虽然理论上是“字节”但很多人拿它存串口读出来的原始数据之后直接当成数值参与计算结果符号位全是乱的。记住一条原则BYTE/WORD/DWORD 是“无符号存储容器”INT/DINT 是“带符号数值”。通信协议、寄存器原值、报文解析用前一组控制计算、逻辑判断用后一组。2.2 WORD 与 INT状态字和带符号数值这个误区我文章开头提了但还是想单独拿出来说。模拟量模块读进来的原始值协议上经常是 WORD0~65535但实际物理量可能是负的比如 -50 度的温度。如果你直接用 WORD 存原始值再往工程量换算大概率出现“负温度显示成 65535 减一点”这种诡异现象。正确做法是硬件通道原始值直接声明成 INT然后根据量程线性换算成 REAL 工程量。比如一个 4~20mA 对应 -50~150 度的传感器先把通道值转成 INT再按比例换算。wRaw : WORD; // 通信层原始报文里的字仅用于数据帧搬运 nValue : INT; // 解析后的带符号传感器值 rTemp : REAL; // 工程量温度 rTemp : INT_TO_REAL(nValue) / 32767.0 * 200.0 - 50.0;2.3 实数家族REAL 用于过程量LREAL 用于累计量我这里再明确一个实操经验PID 调节器内部、模拟量设定值、速度百分比全部用 REAL。我见过有人把这些全部换成 LREAL理由是“精度高更放心”。但实际效果并不明显反而拖慢了控制周期。而流量、电量、位置积分这种会不断累加的历史量用 REAL 就会出前一节说的“加不进去”的毛病必须 LREAL。如果实在纠结最笨也最有效的办法是评估一下这个值从 0 开始累加是否会超过 7 位有效数字会就用 LREAL不会REAL 就够。2.4 时间日期类型别当普通数字用TIME 在 CoDeSys 里本质是毫秒计数的 4 字节值最大能表达约 49 天。所以如果你用 TIME 做长时间累计到第 50 天可能就溢出了。跨天的工作时长累计建议自己用 DINT 数秒或者用 DATE_AND_TIME 算差。TIME_OF_DAY 用于一天内的时刻DATE 用于日期DT 用于日期时刻。它们之间赋值一定要用对应转换函数不能直接 INT 赋值否则日志里的时间戳会变成莫名其妙的值。3. 内存优化大头结构体对齐与字符串/数组选类型只是第一步。真正让内存“唰”地一下膨胀起来的往往是结构体、数组、字符串这三个地方。很多工业项目里变量都是几百上千个单个字段省几个字节累计起来可能就是几十甚至上百 KB 的差距。这部分是我优化程序内存时最喜欢动手的区域。3.1 结构体从 16 字节压到 12 字节的实例结构体存设备参数、配方数据、报警记录时字段顺序如果随便排编译器会为了 CPU 访问效率插入填充字节这部分白白浪费。我给一个常见的字段顺序和内存布局按常见的 4 字节对齐规则计算TYPE ST_Mixed : STRUCT b1 : BOOL; // 偏移0占1字节 i1 : INT; // 需要2字节对齐偏移2开始偏移1被填充 b2 : BOOL; // 偏移4 b3 : BOOL; // 偏移5 i2 : INT; // 偏移6 b4 : BOOL; // 偏移8 r1 : REAL; // 需要4字节对齐偏移12开始偏移9~11被填充 END_STRUCT END_TYPE这个结构体里真正用到的数据是 12 字节但实际占用了 16 字节白白浪费 4 字节。如果这是一个数组ARRAY[0..99] OF ST_Mixed那就是 1600 字节 vs 1200 字节的差别。把字段按“大头在前、小头归类”的方式重排TYPE ST_Mixed : STRUCT r1 : REAL; // 偏移0~34字节对齐没问题 i1 : INT; // 偏移4~5 i2 : INT; // 偏移6~7 b1 : BOOL; // 偏移8 b2 : BOOL; // 偏移9 b3 : BOOL; // 偏移10 b4 : BOOL; // 偏移11 END_STRUCT END_TYPE重排之后整个结构体正好 12 字节4 字节对齐没有任何填充。注意不同控制器的对齐规则不完全一样有的按 2 字节对齐有的按 4 字节对齐。具体布局以目标设备的实际行为为准可以通过SIZEOF()在线上实测。但“大字段优先、小字段按类型归堆”这个原则基本通用。3.2 把 BOOL 合并到 BYTE 和 UNION 的使用边界如果结构体里散落着七八个 BOOL又不想让它们各占一字节可以用联合体或者字节位操作来合并。CoDeSys 3 支持 UNION它让多个变量共享同一块内存非常适合报文解析和标志位打包。TYPE ST_FlagArea : UNION byFlags : BYTE; // 用这一个字节统一访问 ST_Bits : STRUCT bRun : BOOL; // 位0 bAlarm : BOOL; // 位1 bManual : BOOL; // 位2 bFault : BOOL; // 位3 bReady : BOOL; // 位4 END_STRUCT END_UNION END_TYPE注意这个联合体整体占 1 字节而不是 5 字节。但代价是这些 BOOL 不能再当独立变量使用必须通过联合体实例来访问比如stFlag.ST_Bits.bRun。逻辑上稍微繁琐一些可读性也会打折。所以我的原则是只在标志位特别多、或者需要把一字节发给通信模块时使用普通程序里不要为了省那几字节牺牲可读性。3.3 STRING(255) 与 BOOL 数组的隐蔽开销字符串存储是个容易被忽视的大坑。STRING每字符占 1 字节WSTRING每字符占 2 字节而且末尾都有结束符。30 个报警变量每个都声明成STRING(255)那光这一块就是 7.5KB 以上的内存。而实际每条报警可能只填二十几个字符。我的习惯是报警文本、配方名称、操作员注释这类字符串先看最长可能多长再留 30% 余量。比如设备名最长 20 个字符就写STRING(30)而不是直接STRING(255)。BOOL 数组同样费内存。ARRAY[0..99] OF BOOL占的是 100 字节不是 12.5 字节。如果要监控一大片点位状态把位映射到 WORD/DWORD 上反而省得多。比如 32 个点位各写 32 个 BOOL 变量就是 32 字节用一个 DWORD 加位掩码只有 4 字节差了 8 倍。3.4 用 SIZEOF 和 ADR 验证实际布局结构体重排后到底省没省不能靠感觉。CoDeSys 里可以写几个监视表达式来实测nStructSize : SIZEOF(stMixed); pB2 : ADR(stMixed.b2); pI2 : ADR(stMixed.i2);把pI2 - pB2拉出来看偏移差就能直接算出两个字段之间有没有填充。特别是拿到一个新控制器平台时我建议先建一个测试结构体把各类型字段放进去用SIZEOF测一轮确认这个平台的真实对齐规则再大规模铺开写正式结构体。这一步十几分钟但能避免后面几十个结构体全部写错布局。4. 掉电保持区RETAIN不是免费保险箱空间与维护代价类型选型还要考虑变量要不要掉电保持。很多人觉得 RETAIN 就是个属性的事加个关键字而已。实际上保持区的内存是独立于普通工作存储区的通常由非易失存储器或电池供电区域提供空间比普通内存小得多写入次数也有限。把不需要保持的东西全加 RETAIN等于拿宝贵的存储区做临时变量的活。4.1 RETAIN 与 PERSISTENT两种保持策略别混着用CoDeSys 里有两类保持变量RETAIN和PERSISTENT。简单理解RETAIN变量在控制器掉电且正常重启时能恢复但执行冷启动Cold Reset这类操作时通常会被清掉PERSISTENT的保持级别更高冷启动甚至程序重新下载后只要数据区没被主动清也能尽量保留旧值。具体行为跟目标设备的保持区规划有关但方向是这样。我实际项目的做法是操作模式、配方号、累计产量这类要跨重启保留的能不用 PERSISTENT 就不用而是把恢复逻辑写在启动程序里从普通变量往回带。原因在于 PERSISTENT 变量一旦数量增多在线下载时必须处理的保持区校验逻辑更复杂很容易出现“下装一半”“数据区重叠”这类只有离线全量下载才能解决的状况。对现场维护来说这是很麻烦的事。4.2 保持区最常见的三种浪费我审过不少程序保持区浪费基本逃不出这三类第一类是临时状态也加了 RETAIN。比如手动模式、单步标志、当前报警弹窗状态这些本来就是每次上电由操作员决定要不要开的没必要掉电记忆。第二类是整块结构体整体设成 RETAIN。结构体里可能有 30 个字段真正需要保持的只有 3 个结果为了 3 个字段把整个结构体全保了。第三类是把通信报文缓冲区也保持完全没必要。省保持区的思路和普通内存一样按字段粒度和需求去加而不是按“块”去加。如果结构体只有个别字段需要保持把保持字段单独抽成一个VAR RETAIN再在启动逻辑里回填其他地方保持普通变量。VAR RETAIN nCycleCount : DINT; // 真正需要断电保持的计数 rLastPos : REAL; // 上一次断点位置 END_VAR4.3 在线修改保持变量的额外成本在线修改项目时如果增删了 RETAIN 变量或改了保持区布局有时候会碰到“无法地址分配”或“保持区校验错误”之类的提示。因为控制器已经在运行保持区已经被占用并映射到非易失存储你改动之后它没法安全热插拔。这种情况下最稳妥的办法就是给现场计划一次离线下载同时让操作人员确认是否需要保存当前产量数据。这个坑我踩过之后现在任何涉及 RETAIN 的改动都会提前评估绝不手痒在线直接改。5. 实战复盘一个模拟量闭环控制的类型优化全过程前面讲了一堆原则最后用一个我手头的模拟控制项目复盘来收束。这个项目是某加热段的温度闭环控制一个模拟量输入、一个 PID 输出、配方表和报警表。最初程序能跑但内存占用偏高而且偶发温度负值显示异常。利用本文的原则做了一次类型优化。5.1 优化前的问题清单项目原始写法问题表现模拟量原始值用 WORD 存负温度显示成 65535 附近产量累计用 INT连续运行几小时后溢出变负流量累计用 REAL数值大了以后累计量加不进去PID 结构体BOOL/INT/REAL 随便排SIZEOF 实测比声明大小多 8 字节报警文本STRING(255) × 20白占约 5KB保持区8 个变量全部 RETAIN保持区压力大在线改一次还报地址错5.2 逐项替换方案模拟量原始值改成INT工程量换算用REAL。产量累计改成DINT流量累计改成LREAL。PID 结构体把 REAL 字段排前、INT 排中、BOOL 合并到 BYTE同时报警文本从STRING(255)压到STRING(60)。保持区只留下产量累计、配方号和最后停车原因三项其他全部改成普通变量启动逻辑里再按需要初始化。5.3 优化后的内存对比与稳定性项目优化前优化后变化PID 结构体实例约 48 字节约 36 字节减少 25%报警文本区约 5.1KB约 1.2KB减少约 3.9KBRETAIN 变量数83保持区大幅瘦身温度负值显示异常正常类型语义修正长时间累计会溢出/饱和稳定类型范围匹配需求这段优化没有改一条控制逻辑只动了数据类型和相关映射代码。下了重下后跑起来模拟量数值、累计趋势、报警记录都正常了。重点是后续维护的人看程序第一眼就能分清“哪个是状态字、哪个是数值、哪个要掉电保持”不用再像以前那样猜。我在实际项目里慢慢形成的一个习惯是每个 POU 写代码前先做一张小表把输入输出和需要存储的数据列全标上范围、精度、保持性三个属性。数据类型选对了70% 的隐蔽故障其实根本不会出现。类型选型这件事看起来是每个变量省几个字节的小事落到整机项目里就是稳定性和维护成本的大事。
写 CoDeSys 的人大概都有过这种经历程序写得挺顺逻辑也能跑但一上真机就出些说不清的鬼事。比如模拟量输入偶尔跳出 65535或者计数器到了某个数之后突然变成负数又或者在线监控的时候发现一个看起来不大的结构体变量实际占的内存比预估大了一圈。这些问题的根源多半不在逻辑而在数据类型。这篇内容就把 CoDeSys 里的数据类型从头到尾捋一遍。不是教科书式的罗列而是结合我实际调试、优化、改错的经验重点讲清楚两件事怎么选类型以及怎么在数据类型这个层面把内存省下来。适合正在入门 CoDeSys、以及已经在用但没系统整理过类型体系的朋友。1. 选型方法论先回答范围、精度、保持性三个问题很多新手写 PLC 程序习惯先想逻辑再补变量变量类型随便点一个顺手的比如计数用 INT、速度用 REAL、状态用 BOOL。这个顺序其实反了。我在项目里吃过亏之后现在每条数据都要先做一道“三问”数值范围是多少精度要求多高掉电之后要不要保留这三个问题定了类型基本就能锁定——是 INT 还是 DINT是 REAL 还是 LREAL是普通变量还是 RETAIN全在这一步解决。1.1 先算数值范围INT 溢出是 PLC 里最隐蔽的故障INT 的范围是 -32768 到 32767这个数字大家心里都有数但真用起来很多人还是会“想当然”。我调试过一台计数设备生产节拍很快计数变量用了 INT刚开始正常跑了几个小时突然报警查到最后是计数值超过了 32767翻成了负数逻辑判断全部乱套。这个错从语法层面根本看不出来CoDeSys 不会因为你可能溢出就给你编译报错。所以我的习惯是任何变量先算一遍“最大可能值 量程上限 × 安全裕量”再决定位数。计数累计、脉冲累计、配方总数量这类会一直向上加的值直接上 DINT范围能到正负 21 亿多普通工业场景用到头都难。只有那种明确知道自己边界、比如单次扫描内的临时序号、互锁用的编号才用 INT 省内存。还有一点容易被忽略混合运算时的隐式转换。INT 乘 INT如果结果超出 32767在 CoDeSys 中不会自动变成 DINT你得自己声明 DINT或者用类型转换函数包一层。我见过有人写nTotal : iA * iB;两个 INT 相乘结果溢出排查了很久。正确写法是至少把其中一个转成 DINTnTotal : DINT; iA, iB : INT; nTotal : DINT_TO_DINT(iA) * iB; // 实际上 DINT_TO_DINT 没必要但需要让编译器按 DINT 运算更稳妥的做法是从源头就把参与大数运算的变量声明成 DINT省去后面一堆转换和踩坑。1.2 精度要求决定实数类型REAL 与 LREAL 的真正分界线这个问题我在流量累计和设备位置计算上翻过车。REAL 在 CoDeSys 里占 4 字节大约 7 位有效十进制数字LREAL 占 8 字节大约 15 到 17 位有效数字。看起来 REAL 够用但浮点数的“够用”和整数不一样——它有累加误差。我调过一套配料系统流量累计用 REAL 存累计值设备连续跑了两周累计值到了几十万量级这时候每次扫描往里加零点几升数字几乎纹丝不动。原因就是浮点数的有效数字只有 7 位大数和小数相加时小数的低位被吞掉了。这不是 CoDeSys 的问题是 IEEE 754 浮点数的通病。累计、积分、需要长期累加的量老老实实用 LREAL。模拟量百分比、PID 中间变量、速度设定这种“实时刷新、不长期累加”的REAL 完全够用没必要上 LREAL 白白多占 4 字节。另外要注意目标控制器的浮点处理能力。有些低成本的控制器没有硬件浮点单元LREAL 运算靠软件模拟执行一个小数运算可能比 REAL 慢好几倍。控制周期紧张的时候这也会成为瓶颈。1.3 保持性要求普通变量、RETAIN 从开始就要分开规划第三个问题最容易被项目需求阶段忽略。设备掉电重启之后哪些数据要恢复到断电前的值操作模式、配方号、累计产量、当前暂停状态……这些都要 RETAIN而临时计算值、上电标志、扫描计数这种掉电后清零反而更安全。我的做法是写数据字典的时候专门列一列“掉电保持”这一栏把每个变量的需求写清楚然后再分配到普通变量区还是保持区。因为 RETAIN 变量和非 RETAIN 变量在内存里处于不同区域混着放不光影响内存规划还会让在线修改变得很难搞。这个问题在第 4 节单独展开。2. 一张类型速查表外加最容易用错的四组对比把标准类型一张表列清楚选型的时候对着查就行。注意下面标注的是 CoDeSys 里最常见的位宽和范围实际控制器可能略有差异但 IEC 61131-3 标准下基本一致。类型位宽范围 / 精度典型场景常见误用BOOL1字节TRUE / FALSE开关量、状态位、启停控制以为一个 BOOL 只占 1 bitBYTE1字节0~255串口字节、小型状态字用来存有符号数WORD2字节0~65535通信协议状态字、寄存器原值存负数、做数值计算INT2字节-32768~32767普通计数、转速、IO 映射存会超过 32767 的累计值DINT4字节-21亿~21亿累计量、大数计算、时间戳无符号逻辑字混用REAL4字节约7位有效数字PID、模拟量百分比、速度浮点长期累加导致误差LREAL8字节约15~17位有效数字流量累计、重力补偿等精度敏感运算所有浮点都上 LREALTIME4字节毫秒计最大约49天延时、扫描周期计时拿 INT 存毫秒数TOD / DATE / DT4字节时间点日志、配方时间戳类型间直接赋值STRING1字节/字符显式指定长度HMI 文本、报警信息默认长度过大浪费内存WSTRING2字节/字符显式指定长度多语言界面、Unicode不知道比 STRING 大一倍2.1 BOOL 不省位BYTE 也要省着用新手最容易误解的就是 BOOL。在 CoDeSys 里一个 BOOL 变量实际占用 1 个字节不是 1 个位。所以如果你为了省内存写了 100 个 BOOL 变量放一堆标志位那其实是 100 字节。真要压缩位级存储得用 BYTE、WORD、DWORD 自己管理位或者用联合体把一组 BOOL 映射到一个 BYTE 上。这个在第 3 节讲内存优化时具体演示。BYTE 和 WORD 的误用也常见。BYTE 虽然理论上是“字节”但很多人拿它存串口读出来的原始数据之后直接当成数值参与计算结果符号位全是乱的。记住一条原则BYTE/WORD/DWORD 是“无符号存储容器”INT/DINT 是“带符号数值”。通信协议、寄存器原值、报文解析用前一组控制计算、逻辑判断用后一组。2.2 WORD 与 INT状态字和带符号数值这个误区我文章开头提了但还是想单独拿出来说。模拟量模块读进来的原始值协议上经常是 WORD0~65535但实际物理量可能是负的比如 -50 度的温度。如果你直接用 WORD 存原始值再往工程量换算大概率出现“负温度显示成 65535 减一点”这种诡异现象。正确做法是硬件通道原始值直接声明成 INT然后根据量程线性换算成 REAL 工程量。比如一个 4~20mA 对应 -50~150 度的传感器先把通道值转成 INT再按比例换算。wRaw : WORD; // 通信层原始报文里的字仅用于数据帧搬运 nValue : INT; // 解析后的带符号传感器值 rTemp : REAL; // 工程量温度 rTemp : INT_TO_REAL(nValue) / 32767.0 * 200.0 - 50.0;2.3 实数家族REAL 用于过程量LREAL 用于累计量我这里再明确一个实操经验PID 调节器内部、模拟量设定值、速度百分比全部用 REAL。我见过有人把这些全部换成 LREAL理由是“精度高更放心”。但实际效果并不明显反而拖慢了控制周期。而流量、电量、位置积分这种会不断累加的历史量用 REAL 就会出前一节说的“加不进去”的毛病必须 LREAL。如果实在纠结最笨也最有效的办法是评估一下这个值从 0 开始累加是否会超过 7 位有效数字会就用 LREAL不会REAL 就够。2.4 时间日期类型别当普通数字用TIME 在 CoDeSys 里本质是毫秒计数的 4 字节值最大能表达约 49 天。所以如果你用 TIME 做长时间累计到第 50 天可能就溢出了。跨天的工作时长累计建议自己用 DINT 数秒或者用 DATE_AND_TIME 算差。TIME_OF_DAY 用于一天内的时刻DATE 用于日期DT 用于日期时刻。它们之间赋值一定要用对应转换函数不能直接 INT 赋值否则日志里的时间戳会变成莫名其妙的值。3. 内存优化大头结构体对齐与字符串/数组选类型只是第一步。真正让内存“唰”地一下膨胀起来的往往是结构体、数组、字符串这三个地方。很多工业项目里变量都是几百上千个单个字段省几个字节累计起来可能就是几十甚至上百 KB 的差距。这部分是我优化程序内存时最喜欢动手的区域。3.1 结构体从 16 字节压到 12 字节的实例结构体存设备参数、配方数据、报警记录时字段顺序如果随便排编译器会为了 CPU 访问效率插入填充字节这部分白白浪费。我给一个常见的字段顺序和内存布局按常见的 4 字节对齐规则计算TYPE ST_Mixed : STRUCT b1 : BOOL; // 偏移0占1字节 i1 : INT; // 需要2字节对齐偏移2开始偏移1被填充 b2 : BOOL; // 偏移4 b3 : BOOL; // 偏移5 i2 : INT; // 偏移6 b4 : BOOL; // 偏移8 r1 : REAL; // 需要4字节对齐偏移12开始偏移9~11被填充 END_STRUCT END_TYPE这个结构体里真正用到的数据是 12 字节但实际占用了 16 字节白白浪费 4 字节。如果这是一个数组ARRAY[0..99] OF ST_Mixed那就是 1600 字节 vs 1200 字节的差别。把字段按“大头在前、小头归类”的方式重排TYPE ST_Mixed : STRUCT r1 : REAL; // 偏移0~34字节对齐没问题 i1 : INT; // 偏移4~5 i2 : INT; // 偏移6~7 b1 : BOOL; // 偏移8 b2 : BOOL; // 偏移9 b3 : BOOL; // 偏移10 b4 : BOOL; // 偏移11 END_STRUCT END_TYPE重排之后整个结构体正好 12 字节4 字节对齐没有任何填充。注意不同控制器的对齐规则不完全一样有的按 2 字节对齐有的按 4 字节对齐。具体布局以目标设备的实际行为为准可以通过SIZEOF()在线上实测。但“大字段优先、小字段按类型归堆”这个原则基本通用。3.2 把 BOOL 合并到 BYTE 和 UNION 的使用边界如果结构体里散落着七八个 BOOL又不想让它们各占一字节可以用联合体或者字节位操作来合并。CoDeSys 3 支持 UNION它让多个变量共享同一块内存非常适合报文解析和标志位打包。TYPE ST_FlagArea : UNION byFlags : BYTE; // 用这一个字节统一访问 ST_Bits : STRUCT bRun : BOOL; // 位0 bAlarm : BOOL; // 位1 bManual : BOOL; // 位2 bFault : BOOL; // 位3 bReady : BOOL; // 位4 END_STRUCT END_UNION END_TYPE注意这个联合体整体占 1 字节而不是 5 字节。但代价是这些 BOOL 不能再当独立变量使用必须通过联合体实例来访问比如stFlag.ST_Bits.bRun。逻辑上稍微繁琐一些可读性也会打折。所以我的原则是只在标志位特别多、或者需要把一字节发给通信模块时使用普通程序里不要为了省那几字节牺牲可读性。3.3 STRING(255) 与 BOOL 数组的隐蔽开销字符串存储是个容易被忽视的大坑。STRING每字符占 1 字节WSTRING每字符占 2 字节而且末尾都有结束符。30 个报警变量每个都声明成STRING(255)那光这一块就是 7.5KB 以上的内存。而实际每条报警可能只填二十几个字符。我的习惯是报警文本、配方名称、操作员注释这类字符串先看最长可能多长再留 30% 余量。比如设备名最长 20 个字符就写STRING(30)而不是直接STRING(255)。BOOL 数组同样费内存。ARRAY[0..99] OF BOOL占的是 100 字节不是 12.5 字节。如果要监控一大片点位状态把位映射到 WORD/DWORD 上反而省得多。比如 32 个点位各写 32 个 BOOL 变量就是 32 字节用一个 DWORD 加位掩码只有 4 字节差了 8 倍。3.4 用 SIZEOF 和 ADR 验证实际布局结构体重排后到底省没省不能靠感觉。CoDeSys 里可以写几个监视表达式来实测nStructSize : SIZEOF(stMixed); pB2 : ADR(stMixed.b2); pI2 : ADR(stMixed.i2);把pI2 - pB2拉出来看偏移差就能直接算出两个字段之间有没有填充。特别是拿到一个新控制器平台时我建议先建一个测试结构体把各类型字段放进去用SIZEOF测一轮确认这个平台的真实对齐规则再大规模铺开写正式结构体。这一步十几分钟但能避免后面几十个结构体全部写错布局。4. 掉电保持区RETAIN不是免费保险箱空间与维护代价类型选型还要考虑变量要不要掉电保持。很多人觉得 RETAIN 就是个属性的事加个关键字而已。实际上保持区的内存是独立于普通工作存储区的通常由非易失存储器或电池供电区域提供空间比普通内存小得多写入次数也有限。把不需要保持的东西全加 RETAIN等于拿宝贵的存储区做临时变量的活。4.1 RETAIN 与 PERSISTENT两种保持策略别混着用CoDeSys 里有两类保持变量RETAIN和PERSISTENT。简单理解RETAIN变量在控制器掉电且正常重启时能恢复但执行冷启动Cold Reset这类操作时通常会被清掉PERSISTENT的保持级别更高冷启动甚至程序重新下载后只要数据区没被主动清也能尽量保留旧值。具体行为跟目标设备的保持区规划有关但方向是这样。我实际项目的做法是操作模式、配方号、累计产量这类要跨重启保留的能不用 PERSISTENT 就不用而是把恢复逻辑写在启动程序里从普通变量往回带。原因在于 PERSISTENT 变量一旦数量增多在线下载时必须处理的保持区校验逻辑更复杂很容易出现“下装一半”“数据区重叠”这类只有离线全量下载才能解决的状况。对现场维护来说这是很麻烦的事。4.2 保持区最常见的三种浪费我审过不少程序保持区浪费基本逃不出这三类第一类是临时状态也加了 RETAIN。比如手动模式、单步标志、当前报警弹窗状态这些本来就是每次上电由操作员决定要不要开的没必要掉电记忆。第二类是整块结构体整体设成 RETAIN。结构体里可能有 30 个字段真正需要保持的只有 3 个结果为了 3 个字段把整个结构体全保了。第三类是把通信报文缓冲区也保持完全没必要。省保持区的思路和普通内存一样按字段粒度和需求去加而不是按“块”去加。如果结构体只有个别字段需要保持把保持字段单独抽成一个VAR RETAIN再在启动逻辑里回填其他地方保持普通变量。VAR RETAIN nCycleCount : DINT; // 真正需要断电保持的计数 rLastPos : REAL; // 上一次断点位置 END_VAR4.3 在线修改保持变量的额外成本在线修改项目时如果增删了 RETAIN 变量或改了保持区布局有时候会碰到“无法地址分配”或“保持区校验错误”之类的提示。因为控制器已经在运行保持区已经被占用并映射到非易失存储你改动之后它没法安全热插拔。这种情况下最稳妥的办法就是给现场计划一次离线下载同时让操作人员确认是否需要保存当前产量数据。这个坑我踩过之后现在任何涉及 RETAIN 的改动都会提前评估绝不手痒在线直接改。5. 实战复盘一个模拟量闭环控制的类型优化全过程前面讲了一堆原则最后用一个我手头的模拟控制项目复盘来收束。这个项目是某加热段的温度闭环控制一个模拟量输入、一个 PID 输出、配方表和报警表。最初程序能跑但内存占用偏高而且偶发温度负值显示异常。利用本文的原则做了一次类型优化。5.1 优化前的问题清单项目原始写法问题表现模拟量原始值用 WORD 存负温度显示成 65535 附近产量累计用 INT连续运行几小时后溢出变负流量累计用 REAL数值大了以后累计量加不进去PID 结构体BOOL/INT/REAL 随便排SIZEOF 实测比声明大小多 8 字节报警文本STRING(255) × 20白占约 5KB保持区8 个变量全部 RETAIN保持区压力大在线改一次还报地址错5.2 逐项替换方案模拟量原始值改成INT工程量换算用REAL。产量累计改成DINT流量累计改成LREAL。PID 结构体把 REAL 字段排前、INT 排中、BOOL 合并到 BYTE同时报警文本从STRING(255)压到STRING(60)。保持区只留下产量累计、配方号和最后停车原因三项其他全部改成普通变量启动逻辑里再按需要初始化。5.3 优化后的内存对比与稳定性项目优化前优化后变化PID 结构体实例约 48 字节约 36 字节减少 25%报警文本区约 5.1KB约 1.2KB减少约 3.9KBRETAIN 变量数83保持区大幅瘦身温度负值显示异常正常类型语义修正长时间累计会溢出/饱和稳定类型范围匹配需求这段优化没有改一条控制逻辑只动了数据类型和相关映射代码。下了重下后跑起来模拟量数值、累计趋势、报警记录都正常了。重点是后续维护的人看程序第一眼就能分清“哪个是状态字、哪个是数值、哪个要掉电保持”不用再像以前那样猜。我在实际项目里慢慢形成的一个习惯是每个 POU 写代码前先做一张小表把输入输出和需要存储的数据列全标上范围、精度、保持性三个属性。数据类型选对了70% 的隐蔽故障其实根本不会出现。类型选型这件事看起来是每个变量省几个字节的小事落到整机项目里就是稳定性和维护成本的大事。
