3. 产线设备寻址与标签规划
在多设备协同的产线控制项目中，控制器不再只面对一台设备，而是同时管理多台伺服、变频器、远程I/O、机器人、视觉系统与安全模块。此时最容易埋下隐患的并不是逻辑本身，而是标签作用域混乱、地址重复、数据类型不统一。本节围绕控制器作用域标签、程序作用域标签、别名标签与结构体UDT四类对象，说明如何规划跨设备共享数据的命名规范与数据类型，从源头避免地址冲突与后期维护混乱。
一、先分清四类标签的职责边界
Studio 5000 Logix Designer 中的标签按作用域分为两大类：控制器作用域标签（Controller Tags）和程序作用域标签（Program Tags）。控制器作用域标签在整个控制器内可见，可被任意程序、任意任务访问，适合存放跨设备共享数据、硬件I/O映射、全局状态与报警汇总；程序作用域标签只在所属程序内可见，适合存放该设备或该工位的中间变量、步序标志、临时计算值。
别名标签（Alias Tag）本身不占用新的存储空间，它指向某个已存在的标签或I/O点，用于给硬件地址起一个语义化名字。结构体UDT（User-Defined Type）则把一组相关数据打包成一个自定义数据类型，例如把一台伺服的全部状态封装为UDT_Servo，包含使能、就绪、位置、速度、报警码等成员。
四者的关系可以用下面的结构图理解：控制器作用域标签是全局共享层，程序作用域标签是局部私有层，别名标签是硬件地址的语义映射层，UDT是数据类型的组织层。规划的核心原则是：跨设备共享的数据放控制器作用域，单设备内部逻辑放程序作用域，硬件点用别名标签，成组数据用UDT。
二、命名规范：让标签名自己说明归属
命名规范的目标是：看到标签名就能判断它属于哪台设备、哪个工位、什么用途，而不需要打开标签属性逐条查看。推荐采用“区域_设备_功能_属性”的分段式命名，段间用下划线连接，每段使用英文或拼音缩写，避免中文、空格和特殊字符。
例如一条包装产线包含上料、灌装、旋盖、贴标、下料五个工位，每个工位有一台伺服和若干气缸。可以这样规划：
- 控制器作用域全局标签：
Line_Status、Line_Speed_SP、Alarm_Summary、HMI_Cmd_Start； - 程序作用域标签：
Fill_Servo_Step、Cap_Cyl1_Extend、Label_Vision_Result； - 别名标签：
Fill_Servo_Ready指向Local:3:I.Data.0，Cap_Cyl1_Fwd_LS指向Local:4:I.Data.2； - UDT实例：
Fill_Servo、Cap_Servo、Label_Servo，类型均为UDT_Servo。
这样命名后，Fill_Servo.Position 一眼可知是灌装伺服的位置，Cap_Cyl1_Fwd_LS 是旋盖气缸1的前限位。跨设备共享时，其他程序只需引用 Fill_Servo.Position，而不需要知道它背后是哪个I/O点、哪个程序在写。
三、数据类型规划：统一口径，避免隐式转换
多设备协同中最常见的隐性故障是数据类型不匹配。例如伺服位置用REAL、机器人位置用DINT、视觉偏移用INT，三者相加时PLC会做隐式转换，可能丢失精度或产生溢出。规划时应遵循以下原则：
| 数据用途 | 推荐类型 | 说明 |
|---|---|---|
| 位置、速度、扭矩、温度 | REAL | 连续量，统一用浮点，避免整数截断 |
| 报警码、状态字、模式选择 | DINT 或 INT | 离散量，按设备手册位定义 |
| 使能、就绪、到位、故障 | BOOL | 单点布尔，放入UDT成员 |
| 计数器、批次号、条码 | DINT 或 STRING | 条码用STRING，长度按实际定义 |
| 时间戳、累计时间 | DINT（毫秒）或 LINT | 统一单位，避免秒/毫秒混用 |
UDT的设计要遵循“一个设备一个UDT”的原则。以伺服为例，UDT_Servo 至少包含：Enable、Ready、Fault、Position、Speed、Torque、AlarmCode、Status。这样每台伺服只需声明一个实例，程序里用 Fill_Servo.Ready 访问，既减少标签数量，又保证同类设备结构一致，后期增加设备只需复制实例。
四、跨设备共享数据的落地做法
跨设备共享数据应统一放在控制器作用域，并尽量用UDT组织。具体做法是：先定义全局UDT，例如 UDT_LineData，成员包括 LineSpeed、ProductCount、RejectCount、CurrentStation、AlarmActive；再在控制器作用域声明一个实例 LineData。各工位程序只读写 LineData 的成员，不直接访问其他程序的局部标签。
对于硬件I/O，一律先建别名标签，再在逻辑中使用别名。例如：
Fill_Servo_Ready → Local:3:I.Data.0
Fill_Servo_Alarm → Local:3:I.Data.1
Fill_Servo_Enable → Local:3:O.Data.0
Cap_Cyl1_Fwd_LS → Local:4:I.Data.2
Cap_Cyl1_Sol → Local:4:O.Data.1这样当硬件模块位置调整时，只需修改别名指向，逻辑程序无需改动。反之，如果逻辑里直接写 Local:3:I.Data.0，一旦模块换槽，就要全程序搜索替换，极易遗漏。
Fill_、Cap_、Label_。
最后给出一个可直接参考的标签规划表模板，按设备逐行填写，作为项目初期的规划成果：
| 标签名 | 作用域 | 类型 | 数据来源/指向 | 用途 |
|---|---|---|---|---|
| LineData | 控制器 | UDT_LineData | — | 产线共享数据 |
| Fill_Servo | 控制器 | UDT_Servo | — | 灌装伺服状态 |
| Fill_Servo_Ready | 控制器 | BOOL（别名） | Local:3:I.Data.0 | 伺服就绪 |
| Fill_Servo_Step | 程序Fill | DINT | — | 灌装步序 |
| Cap_Cyl1_Fwd_LS | 控制器 | BOOL（别名） | Local:4:I.Data.2 | 气缸前限位 |
| Label_Vision_Result | 程序Label | BOOL | — | 视觉判定结果 |
按上述方式完成规划后，控制器作用域负责“共享什么”，程序作用域负责“内部怎么算”，别名标签负责“硬件在哪里”，UDT负责“数据长什么样”。四者各司其职，跨设备数据交换时只需引用统一的全局标签或UDT实例，既不会出现地址冲突，也不会因为设备增减而大面积返工。