OpenPLC实战手记：IEC 61131-3变量类型不是语法糖，是内存契约
你有没有遇到过这样的情况？
在OpenPLC里写好一个温度控制逻辑，上电运行几分钟后，motor_run突然变成TRUE——可梯形图里明明没触发任何条件；
或者用STRING[16]接收Modbus写入的设备ID，结果HMI显示乱码，Wireshark抓包一看，寄存器值是对的，但字节顺序像被拧过麻花；
又或者把REAL变量直接丢进毫秒级定时中断里做PID运算，CPU占用率飙到92%，而同一段逻辑换成DINT后瞬间回落到14%……
这些都不是Bug，也不是配置错误。它们是你和IEC 61131-3标准之间，一次沉默却真实的“握手失败”。
OpenPLC没有黑盒固件帮你兜底。它把标准摊开在你面前：每个变量类型，都是一份关于内存布局、运算行为、协议映射与边界责任的硬性契约。理解它，不是为了通过考试，而是为了不让你的产线在凌晨三点因为一个越界的ARRAY索引停机。
下面，我们就从调试台前的真实问题出发，一层层拆解这些类型在OpenPLC中究竟是怎么“活”起来的。
BOOL：你以为它只占1位？OpenPLC说：不，它占1字节
在西门子TIA Portal里，ARRAY[1..16] OF BOOL真就只占2个字节——16个bit打包得严丝合缝。但在OpenPLC里，写同样一句：
VAR flags : ARRAY[1..16] OF BOOL; END_VAR它实际吃掉16字节内存，每个BOOL独占一个uint8_t。为什么？
因为OpenPLC运行时（基于Beremiz或自研ST解析器）为简化指针操作与跨平台兼容性，放弃位寻址优化，统一按字节对齐。这不是缺陷，是取舍：用一点内存换掉所有嵌入式平台上的位操作陷阱——比如ARM Cortex-M系列对非对齐访问会触发HardFault。
所以当你看到Web IDE变量监视窗里start_btn = TRUE，别以为它在内存里是0x01的某个bit；它就是0x01这个完整的字节。而通过Modbus TCP读线圈（Function Code 01），OpenPLC会把这个字节的最低位（LSB）当作TRUE/FALSE返回，高位全忽略。
💡 坑点与秘籍：
- 如果你要节省内存，别堆BOOL数组，改用INT或DINT配合位操作函数（SHL,SHR,AND）模拟位域；
-IF motor_run THEN ... END_IF生成的是纯test %al, %al汇编指令，零转换开销——这是BOOL唯一不该被替代的价值； <
