通过结构体（UDT，用户自定义类型）配合标签（Tag）通讯，是现代 PLC 编程中实现模块化、简化代码逻辑的核心手段，基恩士 PLC支持标签通讯。
在 PLC 内部，结构体（UDT）其实只是一个逻辑上的封装。当你定义了一个包含“速度（REAL）”、“状态（BOOL）”和“计数（INT）”的结构体时，PLC 在编译和分配内存时，会将这些变量按照顺序和字节对齐规则，平铺在一段连续的物理内存地址中。
既然知道了是从内存中拿数据，在实际开发（特别是上位机对接）时，你就必须注意内存对齐（Memory Alignment）和字节序的问题：
- 数据拼接：如果你直接读取整个结构体的标签，上位机接收到的是一个大的字节数组（Byte Array）。你需要严格按照 PLC 内部结构体的成员顺序和数据类型长度，去解析这段内存数据。
- 填充字节（Padding）：PLC 为了 CPU 读取效率，可能会在结构体的某些成员之间自动插入一些“填充字节”（比如 4 字节对齐）。如果你在上位机按纯紧凑结构去解析，数据就会错位。
结构体标签让编程更直观，但底层的物理实现依然是对 PLC 连续内存块的读写操作。
问：是不是只有基恩士是从内存中，其他像汇川倍福是按名字？
这是一个非常经典的误解。其实，无论是基恩士、汇川、倍福，还是西门子、欧姆龙等所有品牌的 PLC，底层通讯本质上全都是“从内存中拿数据”的。并没有哪个品牌是真正只靠“名字”就能变出数据的。
之所以你会产生“汇川、倍福是按名字”的错觉，是因为它们在处理“名字”到“内存地址”的转换机制上，对外呈现的方式不同。
我们可以把 PLC 内部的内存比作一个巨大的快递柜，而变量名（标签）就是取件码。
🏭 倍福（Beckhoff）：全自动的“智能快递柜”
倍福的 ADS 协议在易用性上做得非常出色，这也是让你觉得它“按名字”通讯的主要原因。
- 表象：你在 C# 等上位机代码中，直接写
ReadAny("MAIN.MyVariable")，把变量名丢给它，数据就回来了。 - 真相：ADS 协议在底层帮你偷偷跑了两步路。当你传入
"MAIN.MyVariable"时，它会先向 PLC 发送一个请求：“请告诉我这个变量的内存地址（句柄 Handle）是多少？”拿到内存地址（比如iGroup=0x4020, iOffs=0x1234）后，它再根据这个地址去内存里把数据取出来。 - 加速技巧：因为每次查名字都要多跑一趟，所以在实际工程中，工程师通常会手动获取并缓存这个句柄（内存地址）。后续通讯直接传句柄，这就和基恩士直接读内存地址在本质上完全一样了。
⚙️ 汇川（Inovance）：名字和地址的“混合双打”
汇川（以及很多基于 CODESYS 平台的 PLC）在通讯时，往往表现得更加“诚实”和灵活。
- 表象：在使用智能网关或触摸屏对接汇川 PLC 时，你经常会看到既可以选“标签名称”，也可以直接填“物理寄存器地址（如 %MW100 或 D200）”。
- 真相：汇川的变量在编译时，同样会被分配一个绝对的物理内存地址。当你用标签通讯时，网关或上位机内部依然有一个查表的过程，把标签映射成地址。但汇川非常鼓励工程师在对接外部设备时，直接绑定绝对地址（例如
AT %MW100），因为这样通讯效率最高，不需要任何查名字的中间环节。
📌 总结与对比
为了让你更直观地理解，我们可以做一个简单的对比：
表格
| 品牌/平台 | 通讯时的直观感受 | 底层实际动作 |
|---|---|---|
| 基恩士 (Keyence) | 往往需要映射到软元件（如 DM/EM 区） | 直接告诉你去哪个内存抽屉拿数据 |
| 倍福 (Beckhoff) | 直接扔给它变量名字符串 | 先帮你在后台查名字对应的抽屉号，再去拿 |
| 汇川 (Inovance) | 名字和绝对地址都能用 | 名字是别名，底层依然靠绝对内存地址定位 |
核心结论：
世界上不存在只靠“名字”就能通讯的 PLC。所有的标签（Tag）通讯，最终都必须翻译成“内存地址 + 数据类型 + 长度”这三个要素，才能从 PLC 的 CPU 中准确地拷贝出数据。
所以，你在做上位机对接时，如果遇到性能瓶颈（比如读得太慢），不管是用倍福还是基恩士，绕过“名字”，直接去读写底层的“内存地址”，永远是最高效的终极方案。
注意：
在基恩士 PLC 的运动控制中，轴的下标（轴编号）是从 1 开始的，而不是像大多数编程语言数组那样从 0 开始。
其实，在基恩士 PLC 的系统底层和官方指令层面，只有“轴编号”，没有“轴下标”这个概念。
因此，基恩士 PLC 中绝对不存在“0号轴”，它的物理轴和逻辑轴编号都是从1开始的。
上位机（数组下标 0） = 基恩士 PLC（轴编号 1），两者之间是严格的“加 1”映射关系。
问：那么在基恩士PLC中除了轴，其他对象在定义的时候，下标也是从1开始吗？
答案是：不一定。在基恩士 PLC 中，除了轴编号是强制从 1 开始的，其他对象（如数组、变量表）的下标是从 0 还是从 1 开始，完全取决于你如何定义它。
💡为什么基恩士 PLC 的轴编号不从 0 开始？
这其实是工业自动化领域（PLC）与纯计算机软件领域（C#、Python、C++ 等）的一个经典“文化差异”：
- 计算机软件：深受 C 语言影响，内存寻址从 0 开始，所以数组下标天然从 0 开始。
- 工业 PLC：更贴近传统的电气工程师思维。在电气图纸和实际接线中，我们习惯说“第 1 个电机”、“第 1 个气缸”，而不是“第 0 个”。为了让编程逻辑更贴近物理设备的直观顺序，绝大多数 PLC（包括三菱、欧姆龙以及这里的基恩士）在涉及轴编号、单元编号、通道编号时，统统都是从1开始计数的。
