ST IF语句嵌套过深：如何用 CASE 语句重构多层逻辑判断

在结构化文本（ST）编程中，当控制逻辑涉及多个互斥条件分支时，过度嵌套的 IF...ELSIF...ELSE 语句极易导致代码可读性崩塌、调试困难、维护成本飙升。典型表现是：缩进层级达 5 层以上，单个 IF 块跨越百行，END_IF; 与开头难以匹配，新增一个判断分支需反复调整缩进和括号配对。此时，用 CASE 语句重构不是优化技巧，而是工程底线。

一、先识别：什么算“嵌套过深”？

嵌套深度 = 从最外层 IF 开始，向下每进入一层 IF 或 ELSIF 内部的 IF，深度 +1。
以下代码即为深度为 4 的危险嵌套：

IF Motor_Status = 1 THEN
    IF Speed_Range = 'HIGH' THEN
        IF Temp_Sensor > 85.0 THEN
            IF Coolant_Flow = FALSE THEN
                **触发** 报警_过热停机;
            ELSE
                **启动** 辅助冷却泵;
            END_IF;
        ELSE
            **维持** 当前转速;
        END_IF;
    ELSIF Speed_Range = 'LOW' THEN
        **降频** 至基础运行点;
    END_IF;
ELSE
    **检查** 启动信号有效性;
END_IF;

该段存在 4 个问题：

1. 第 4 层 IF（Coolant_Flow = FALSE）已脱离业务语义主干，沦为故障处理子分支；
2. ELSIF Speed_Range = 'LOW' 与上层 Speed_Range = 'HIGH' 实为同一维度枚举值，却分散在不同嵌套层；
3. ELSE 分支语义模糊（“检查启动信号有效性”应属初始化逻辑，非状态兜底）；
4. 无明确状态出口，无法快速定位当前处于哪一组组合条件。

判定标准：满足任一即需重构——

• 主干 IF 嵌套 ≥ 3 层；
• 同一变量在多层中重复比较（如 Speed_Range 出现在第 2 层和第 3 层）；
• ELSIF 分支数 > 4 且均为离散枚举值；
• 单个 IF 块内含超过 2 个 IF 子块。

二、核心原则：CASE 不是语法替换，而是状态解耦

CASE 的本质是将多维条件映射到单一状态标识，再对该标识做线性分支处理。成功重构的关键不在写法，而在三步解耦：

1. 提取主控变量：识别驱动逻辑走向的核心状态量（如设备模式、运行阶段、故障等级）；
2. 归并等价分支：把分散在各层中含义相同的判断合并为一个枚举项；
3. 剥离副作用操作：将报警、启停、复位等动作移至 CASE 分支末尾，禁止在中间嵌套 IF。

以电机控制为例，原始嵌套中交织了 4 个变量：Motor_Status、Speed_Range、Temp_Sensor、Coolant_Flow。但真正决定动作的主控变量是「运行健康度」，它可由其他变量计算得出：

$$ \text{Health\_Level} = \begin{cases} 0 & \text{if } \text{Motor\_Status} = 0 \\ 1 & \text{if } \text{Motor\_Status} = 1 \land \text{Temp\_Sensor} \leq 85.0 \\ 2 & \text{if } \text{Motor\_Status} = 1 \land \text{Temp\_Sensor} > 85.0 \land \text{Coolant\_Flow} = \text{TRUE} \\ 3 & \text{if } \text{Motor\_Status} = 1 \land \text{Temp\_Sensor} > 85.0 \land \text{Coolant\_Flow} = \text{FALSE} \end{cases} $$

注意：Health_Level 是计算结果，非物理传感器值，必须声明为 INT 类型变量并在 CASE 前完成赋值。

三、四步重构法：从嵌套到 CASE 的完整迁移

步骤 1：定义清晰的枚举类型（ST 标准写法）

TYPE eHealthLevel :
(
    HEALTH_OFF := 0,
    HEALTH_NORMAL := 1,
    HEALTH_WARN := 2,
    HEALTH_FAULT := 3
);
END_TYPE

✅ 优势：eHealthLevel 可被所有 POUs 复用；IDE 支持自动补全；编译器校验取值范围。
❌ 禁止：用 INT 直接写 0..3，会导致后续修改时无法追溯语义。

步骤 2：用单层逻辑计算主控变量

// 在主程序循环开头执行
healthLevel : eHealthLevel;

// 计算健康等级（无嵌套！）
IF Motor_Status = 0 THEN
    healthLevel := HEALTH_OFF;
ELSIF Temp_Sensor <= 85.0 THEN
    healthLevel := HEALTH_NORMAL;
ELSIF Coolant_Flow = TRUE THEN
    healthLevel := HEALTH_WARN;
ELSE
    healthLevel := HEALTH_FAULT;
END_IF;

✅ 关键：所有判断均基于原始变量，不引入新 IF；ELSIF 隐含优先级，顺序即逻辑权重。
⚠️ 注意：此处 Temp_Sensor <= 85.0 已覆盖 Motor_Status = 1 前提（因 Motor_Status = 0 已被首分支捕获），避免冗余判断。

步骤 3：用 CASE 替换嵌套主干

CASE healthLevel OF
    HEALTH_OFF:
        **复位** 所有输出寄存器;
        **清除** 故障标志;

    HEALTH_NORMAL:
        **执行** 速度闭环控制;
        **更新** PID 输出;

    HEALTH_WARN:
        **限制** 最大转速为 70%;
        **点亮** 黄色警告灯;
        **记录** 温度超限事件;

    HEALTH_FAULT:
        **切断** 主接触器;
        **触发** 硬件急停信号;
        **发送** MODBUS 故障码 0x1A;

    ELSE
        **置位** 系统错误标志;
        **进入** 安全停机状态;
END_CASE;

✅ 结构优势：

• 每个分支长度可控（建议 ≤ 5 行）；
• 新增状态只需在 TYPE 中追加枚举项 + CASE 中增加分支；
• ELSE 明确承担“未定义状态”兜底，而非模糊业务逻辑。

步骤 4：验证边界与异常流

必须检查 3 类边界场景：

✅ 工具推荐：在 TIA Portal 中使用“强制表”实时修改变量；用“监控表”跟踪 healthLevel 变化时序。
❌ 禁止：在 CASE 分支内再次写 IF 判断同一变量（如 IF healthLevel = HEALTH_WARN THEN ... END_IF;），这等于退回嵌套原点。

四、高阶技巧：处理多变量组合与动态优先级

当主控变量无法单靠 IF/ELSIF 计算时（例如：需同时考虑 Mode_Select、Fault_Code、User_Priority 三个独立输入），采用加权编码法：

1. 为每个变量分配权重（确保无进位冲突）：

   • Mode_Select（0~3）→ 权重 100 → 贡献 0, 100, 200, 300
   • Fault_Code（0~15）→ 权重 1 → 贡献 0~15
   • User_Priority（0~2）→ 权重 10 → 贡献 0, 10, 20

2. 构建组合键：

   comboKey := (Mode_Select * 100) + (User_Priority * 10) + Fault_Code;

3. 在 CASE 中直接匹配关键组合：

   CASE comboKey OF
       100..115: // Mode=1, Priority=0, Fault=0~15 → 自动模式基础响应
           **调用** FB_AutoBase;
   
       110..125: // Mode=1, Priority=1, Fault=0~15 → 用户干预增强模式
           **调用** FB_UserOverride;
   
       300: // Mode=3 (MAINTENANCE), Fault=0 → 维护模式专用流程
           **禁用** 安全继电器;
           **启用** 手动轴控接口;
   
       ELSE
           **执行** 默认安全策略;
   END_CASE;

✅ 优势：无需枚举全部 4×16×3=192 种组合，只定义关键路径；comboKey 为 INT，兼容所有 PLC 平台。
⚠️ 注意：权重设计必须满足 最大值 × 权重 < 下一变量最小权重，此处 15×1=15 < 10 成立，2×10=20 < 100 成立。

五、避坑指南：ST 中 CASE 的 5 个致命错误

六、性能实测：CASE 比嵌套 IF 快多少？

在 Siemens S7-1500（CPU 1516F）上，对 10 个分支的逻辑进行 100 万次循环测试：

结论：CASE 执行效率提升 2.5 倍，栈空间减少 70%，这对高速运动控制（如电子凸轮同步）至关重要——过深嵌套可能引发扫描周期超时（OB30 中断丢失）。

七、迁移 checklist：上线前必须完成的 7 项验证

1. TYPE 枚举项覆盖所有实际运行状态（查 I/O 信号日志确认）；
2. 预计算段无除零、溢出、未初始化访问；
3. CASE 每个分支末尾有明确输出动作（无空分支）；
4. ELSE 分支包含 **置位** 系统错误标志; 且连接至 HMI 报警页；
5. 在仿真环境触发所有枚举值，验证无跳变、无遗漏；
6. 下载至 PLC 后，用在线诊断监控 healthLevel 变量实时变化；
7. 修改任意输入信号，确认 CASE 分支切换延迟 ≤ 1 个扫描周期（典型值 2~10 ms）。