3. 命名规范与编码约定

在Studio 5000中，命名不是“给东西起个名字”这么简单。控制器里的每一个标签、每一个AOI、每一个UDT，最终都会变成工程文件中的符号引用。命名一旦混乱，程序的可读性、可维护性和跨项目复用能力都会迅速下降。本节要解决的核心问题是：如何用一套统一的命名规则，把位号、设备、程序、例程、标签、AOI和UDT组织成一套可检索、可排序、可复用的编码体系。

一、命名的基本约束与字符选择

Studio 5000的标签名允许字母、数字和下划线，不允许空格和大多数特殊字符。控制器标签名不区分大小写，但工程实践中建议统一使用“大驼峰”或“下划线分隔”中的一种，不要混用。例如，Motor_Start和motorStart同时出现，会让检索和排序变得困难。推荐的做法是：全部使用大写字母加下划线，例如MTR01_RUN，这样在RSLogix/Studio 5000的标签监视器和交叉引用中排序稳定，也便于与电气图纸上的位号对应。

另一个关键约束是长度。控制器标签名最长可达40个字符，但实际工程中建议控制在24个字符以内。过长的标签在梯形图显示时会截断，在HMI映射时也容易出错。如果确实需要表达更多信息，应通过UDT成员或程序结构来承载，而不是无限延长标签名。

二、位号与设备命名：从电气图纸到控制器

位号是连接电气设计和控制程序的桥梁。电气图纸上通常使用IEC 81346或企业自定义的位号体系，例如M01表示1号电机，V01表示1号阀门。在Studio 5000中，设备命名应尽量保留位号主体，并加上设备类型前缀。推荐格式为：

设备类型前缀 + 位号 + 功能后缀

示例：
MTR_M01_RUN      1号电机运行反馈
MTR_M01_START    1号电机启动命令
VLV_V01_OPEN     1号阀门开到位
VLV_V01_CMD      1号阀门开命令
PMP_P01_FAULT    1号泵故障

这里的前缀MTR、VLV、PMP是设备类型码，建议在项目初期就固定一张类型码表，例如：MTR=电机，VLV=阀门，PMP=泵，FAN=风机，CNV=输送机，ROB=机器人。后缀则表达信号功能：RUN表示运行反馈，START表示启动命令，FAULT表示故障，OPEN表示开到位，CMD表示命令输出。这样命名的好处是：在标签列表中按前缀排序，同一类设备自然聚在一起；按位号检索，可以快速定位到具体设备的所有信号。

三、程序、例程与AOI的命名

程序（Program）和例程（Routine）的命名应体现“区域+功能”的层级关系。推荐格式为：

程序：区域码_功能名
例程：序号_功能描述

示例：
PRG_LINE01_MAIN        1号线主程序
  R01_MainLogic        主逻辑例程
  R02_Interlock        互锁例程
  R03_FaultHandler     故障处理例程

PRG_LINE01_UTIL        1号线公用程序
  R01_AirSupply        气源控制
  R02_LubeControl      润滑控制

AOI的命名需要额外考虑“可复用性”。一个AOI如果只在一个项目中使用，命名可以简单；但如果要跨项目复用，就必须在名称中体现版本和功能。推荐格式为：AOI_功能_版本，例如AOI_MotorStarter_V2。注意，AOI名称一旦被引用，修改名称会导致所有引用点报错，因此AOI命名应在发布前确定，后续通过版本号区分迭代，而不是直接改名。

四、标签与UDT的命名体系

标签分为控制器标签（Controller Tags）和程序标签（Program Tags）。控制器标签用于全局共享，程序标签用于局部逻辑。命名上应通过前缀区分作用域：全局标签加g_前缀，程序标签加p_前缀。例如：

g_Line01_RunEnable      全局：1号线运行使能
p_Line01_StepIndex      局部：1号线步序索引

UDT的命名应体现“数据结构”的本质。推荐格式为UDT_功能名，例如UDT_Motor、UDT_Valve、UDT_PID。UDT内部的成员命名也要统一，建议使用“状态+命令+参数”三段式：

UDT_Motor
  .Sts_Run         运行状态
  .Sts_Fault       故障状态
  .Cmd_Start       启动命令
  .Cmd_Stop        停止命令
  .Prm_RatedCurrent  额定电流
  .Prm_StartDelay    启动延时

这样，当你在程序中看到MTR_M01.Sts_Run时，可以立刻判断出这是1号电机的运行状态，而不是命令或参数。UDT成员使用Sts_、Cmd_、Prm_前缀，是区分数据方向的关键。

五、版本与项目代号管理

版本管理是命名规范中最容易被忽视、却最容易在后期造成混乱的部分。Studio 5000项目文件本身有版本号（如V32、V33），但工程实践中还需要管理“程序版本”和“项目代号”。推荐的做法是：在项目根目录下建立一个_ProjectInfo程序，用控制器标签记录项目代号、程序版本、修订日期和修订人。例如：

g_ProjectCode    := 'LINE01_2024'
g_ProgramVersion := 'V1.3'
g_RevisionDate   := '2024-06-15'
g_RevisionBy     := 'ZhangSan'

项目代号建议采用“产线码_年份”的格式，例如LINE01_2024。程序版本采用V主版本.次版本格式，主版本在架构变更时递增，次版本在功能修改时递增。AOI和UDT的版本则直接体现在名称中，例如AOI_MotorStarter_V2、UDT_Motor_V3。当AOI升级时，不要直接修改原AOI，而是复制一份并递增版本号，这样旧项目仍然可以引用旧版本，新项目使用新版本，避免“牵一发而动全身”。

六、命名检查与常见错误

在程序发布前，建议做一次命名检查。检查项包括：是否存在空格或非法字符；前缀是否统一；同一设备的不同信号是否使用了相同的位号主体；AOI和UDT是否带有版本号；全局标签和局部标签是否用g_和p_区分。常见的错误包括：用Start1、Start_1、START1三种写法表示同一个信号；把命令和状态混用同一个后缀；AOI名称中不带版本号导致升级后引用混乱。这些错误在项目规模较小时影响不大，但一旦程序需要跨项目复用或多人协作，就会成为严重的维护负担。

最后需要强调的是，命名规范不是一成不变的。随着项目复杂度提升，可以逐步细化类型码和后缀表，但任何调整都应在项目初期或版本升级时统一进行，避免在项目中期随意更改已发布的命名规则。一套稳定的命名体系，是Studio 5000生产程序标准化工程的基础设施。