通过结构体（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 中准确地拷贝出数据。
所以，你在做上位机对接时，如果遇到性能瓶颈（比如读得太慢），不管是用倍福还是基恩士，绕过"名字"，直接去读写底层的"内存地址"，永远是最高效的终极方案。