3. PLC变量与数据类型规范

在TIA Portal项目中，变量与数据类型规范是程序可读性、可维护性和版本可追溯性的第一道防线。一个产线项目往往包含数百个I/O点、几十个工位、多台设备，如果变量命名随意、数据类型混用、常量散落各处，后期排障和版本对比将变得极其困难。本节围绕变量命名规则、数据类型选择、常量与枚举、数组与结构体、UDT的规范化使用五个方面，给出可直接落地的规范建议。

一、变量命名规则

TIA Portal支持中文、英文、数字和下划线命名，但为了跨版本、跨工程师协作，建议统一采用“英文+数字+下划线”的命名方式，避免使用中文、空格和特殊字符。命名结构推荐采用“区域_设备_功能_类型”的分段式，例如：

Line1_Stn2_CylA_Extend_Cmd      // 1线2工位A气缸伸出命令
Line1_Stn2_CylA_Extend_Fb       // 1线2工位A气缸伸出反馈
Line1_Stn2_CylA_Extend_Tm       // 1线2工位A气缸伸出超时定时器
Line1_Stn2_Robot_Ready          // 1线2工位机器人就绪
Line1_Stn2_Robot_ProgNo         // 1线2工位机器人程序号

命名中应避免使用“M0.0”“DB1.DBX0.0”这类绝对地址作为变量名，因为一旦硬件组态调整，绝对地址会变化，而符号名不变。对于全局变量，建议在PLC变量表中按“区域”分组，例如Line1、Line2、Common、HMI等，便于筛选和版本对比。对于局部变量，在FB/FC接口区命名时，输入参数建议加“i_”前缀，输出参数加“o_”前缀，静态变量加“s_”前缀，临时变量加“t_”前缀，例如：

i_StartBtn      // 输入：启动按钮
o_CylExtend     // 输出：气缸伸出
s_StepNo        // 静态：步序号
t_TempCalc      // 临时：中间计算值

这种前缀方式在FB内部调用时能快速区分变量来源，减少误用。

二、数据类型选择

数据类型选择应遵循“够用、明确、可扩展”原则。BOOL用于开关量，如按钮、限位、接触器反馈；BYTE/WORD/DWORD用于位组合或通信数据；INT/DINT用于计数、位置、速度等整数；REAL用于模拟量、温度、压力等连续量；TIME用于定时器预设值；STRING用于配方名称、条码等文本。需要特别注意的是，模拟量输入模块的原始值通常为INT（0~27648），转换为工程量时建议使用REAL，并保留一位小数，例如：

// 模拟量转换示例：4~20mA对应0~100.0℃
RawValue : INT;        // 原始值 0~27648
EngValue : REAL;       // 工程量 0.0~100.0℃
EngValue := INT_TO_REAL(RawValue) / 27648.0 * 100.0;

对于需要跨PLC、跨HMI传输的变量，建议统一使用标准数据类型，避免使用PLC自定义类型直接映射到HMI，否则版本升级时容易出现兼容性问题。

三、常量与枚举

常量用于替代程序中反复出现的固定值，例如工位号、速度档位、配方索引。在TIA Portal中，可以在PLC变量表中定义常量，也可以在DB中定义常量。建议将产线中所有“魔法数字”提取为常量，例如：

// 常量定义示例
STN_COUNT := 8;          // 工位总数
SPEED_LOW := 10;         // 低速档 10%
SPEED_MID := 50;         // 中速档 50%
SPEED_HIGH := 100;       // 高速档 100%
MAX_RETRY := 3;          // 最大重试次数

枚举（Enum）适合表示状态机中的步序号或模式选择。例如，将工位状态定义为枚举类型：

TYPE e_StationState :
(
    Idle := 0,
    Ready := 10,
    Working := 20,
    Done := 30,
    Error := 99
);
END_TYPE

使用枚举后，程序中可以直接写“IF State = e_StationState.Working THEN”，比写“IF State = 20 THEN”更直观，也便于版本对比时快速识别状态含义。

四、数组与结构体

数组用于存储同类型批量数据，例如8个工位的完成信号、10个配方参数。数组下标建议从1开始，与工位号对应，避免从0开始造成混淆。例如：

StationDone : ARRAY[1..8] OF BOOL;   // 1~8工位完成信号
RecipeTemp  : ARRAY[1..10] OF REAL;  // 10个配方温度值

结构体用于将逻辑相关的变量组合在一起，例如一个气缸的“命令、反馈、超时、手动、故障”可以定义为一个结构体：

TYPE t_Cylinder :
STRUCT
    Cmd     : BOOL;   // 伸出命令
    FbExt   : BOOL;   // 伸出反馈
    FbRet   : BOOL;   // 缩回反馈
    TmOut   : TIME;   // 超时时间
    Fault   : BOOL;   // 故障标志
END_STRUCT;
END_TYPE

使用结构体后，一个气缸只需一个变量名，例如“CylA : t_Cylinder;”，访问时写“CylA.Cmd”“CylA.FbExt”，代码层次清晰，版本对比时也容易看出结构变化。

五、UDT的规范化使用

UDT（用户自定义数据类型）是TIA Portal中实现数据规范化的核心工具。建议将产线中重复出现的设备对象抽象为UDT，例如气缸、电机、机器人、扫码枪、称重仪等。UDT命名建议以“t_”开头，内部成员按“命令—反馈—参数—状态—故障”顺序排列，并统一使用英文缩写。例如：

TYPE t_Motor :
STRUCT
    CmdRun      : BOOL;   // 运行命令
    CmdDir      : BOOL;   // 方向 0=正转 1=反转
    FbRun       : BOOL;   // 运行反馈
    FbFault     : BOOL;   // 故障反馈
    SpeedSet    : REAL;   // 速度设定值
    SpeedAct    : REAL;   // 速度实际值
    Current     : REAL;   // 电流
    RunTime     : TIME;   // 累计运行时间
    FaultCode   : INT;    // 故障代码
END_STRUCT;
END_TYPE

定义好UDT后，在DB中声明数组，例如“Motors : ARRAY[1..6] OF t_Motor;”，即可批量管理6台电机。UDT的版本管理需要特别注意：一旦UDT被多个DB引用，修改UDT成员后必须统一更新所有引用，否则会出现“类型不一致”编译错误。建议在项目初期就规划好UDT结构，并在版本注释中记录UDT变更历史。

六、规范化落地建议

在实际项目中，建议按以下顺序推进变量与数据类型规范化：第一步，在项目初期建立命名规则文档，明确前缀、分段和缩写表；第二步，梳理产线中重复出现的设备对象，抽象为UDT，并统一成员顺序；第三步，将固定值提取为常量，将状态机步序号定义为枚举；第四步，在全局DB中使用UDT数组批量声明设备实例；第五步，在版本注释中记录UDT和常量的变更历史。这样，当产线扩展或程序版本升级时，变量层面的改动可以被快速定位和批量处理，减少因命名混乱或类型不一致导致的编译错误和排障时间。