ST错误处理机制：TRY-CATCH 结构在通信故障中的异常捕获

在 ST（Structured Text）编程中，TRY-CATCH 结构是 IEC 61131-3 标准定义的唯一原生异常处理机制，专为捕获运行时不可预测的错误而设计。它不适用于逻辑计算错误或变量越界检查（这些需靠静态分析或手动防护），但对通信类故障——如 Modbus TCP 连接中断、EtherCAT 主站失步、OPC UA 会话超时、S7 通信块 TCON 状态异常等——具有不可替代的实时拦截能力。

以下指南完全基于 ST 语言本身实现，无需调用外部库或依赖 PLC 厂商私有扩展（如 Siemens SCL 的 EXCEPTION 或 Beckhoff TwinCAT 的 ON ERROR），确保跨平台可移植性。

一、为什么通信故障必须用 TRY-CATCH 捕获？

通信故障具有三大特征：

• 异步性：故障可能在任意周期扫描中突发，无法通过 IF 判断预知；
• 瞬态性：一次 SEND 指令失败后，下个周期可能自动恢复，但若未捕获异常，程序会跳过后续关键动作（如重连逻辑、报警置位）；
• 传播性：未处理的通信异常会触发 PLC 运行系统级错误（如 CODESYS 中的 ERR_CODE_0x0004），导致任务挂起或整个控制循环中断。

而传统防御式写法存在硬伤：

// ❌ 危险示例：仅靠状态字判断，漏掉底层协议栈崩溃
IF NOT ModbusTCP_Client.Connected THEN
  // 尝试重连...
END_IF;

该写法无法捕获 ModbusTCP_Client.Send() 执行过程中因网卡驱动异常、DMA 传输超时引发的硬件级报错——这类错误不会改变 Connected 位，但会使指令直接抛出异常。

TRY-CATCH 是唯一能在指令执行现场截停错误流的语法。

二、ST 中 TRY-CATCH 的合法语法结构

IEC 61131-3 明确规定：TRY-CATCH 必须成对出现，且 CATCH 后必须跟一个具名异常类型标识符。标准支持的异常类型仅有两个：

⚠️ 注意：EXCEPTION_COMMUNICATION 并非所有 PLC 都支持。CODESYS V3.5+、Phoenix Contact PLCnext、B&R Automation Studio 均已实现；但旧版 Schneider EcoStruxure 和部分国产 PLC 仅支持 EXCEPTION_ALL。使用前请查阅目标平台的《ST Language Reference》文档第 7.4.2 节。

合法结构如下：

TRY
  // 可能抛出异常的语句（必须是函数块调用或赋值语句）
  ModbusTCP_Client.Send(pData := ADR(buffer), len := 16);
  EtherCAT_Master.Cycle();
CATCH EXCEPTION_COMMUNICATION DO
  // 仅当通信异常发生时执行
  bCommFault := TRUE;
  nRetryCount := nRetryCount + 1;
END_CATCH;

❌ 以下写法语法错误（PLC 编译器将拒绝通过）：

• CATCH 后无异常类型标识符；
• TRY 块内写 IF、FOR 等控制流语句（必须是可抛异常的执行语句）；
• 在 CATCH 块内再次调用可能异常的通信指令（未加嵌套 TRY）。

三、通信故障的精准捕获：四步实操法

步骤 1：隔离高风险通信指令

将每个独立通信动作封装为单条可执行语句，禁止合并。
✅ 正确：

// 每次只做一件事，异常可精确定位
TRY
  ModbusTCP_Client.Read(ADR(registers), 10); // 读10个寄存器
CATCH EXCEPTION_COMMUNICATION DO
  sFaultSource := 'Modbus Read';
END_CATCH;

TRY
  OPC_UA_Client.Write('ns=2;s=Motor.Speed', REAL_TO_LREAL(speedSet));
CATCH EXCEPTION_COMMUNICATION DO
  sFaultSource := 'OPC UA Write';
END_CATCH;

❌ 错误（无法定位故障点）：

// 多个通信指令挤在同一个 TRY 块，异常发生时不知哪条失败
TRY
  ModbusTCP_Client.Read(...);
  OPC_UA_Client.Write(...);
CATCH ... DO
  // 此处无法区分是 Modbus 还是 OPC 故障
END_CATCH;

步骤 2：绑定故障上下文信息

在 CATCH 块中立即记录三项关键数据：

• 故障时间戳（使用 RTC 函数块的 TON 或 TOD）；
• 故障源标识（字符串，如 'S7-1200 DB1.DBW2'）；
• 通信句柄状态（读取函数块的 Status 输出字）。

示例：

VAR
  fbS7Conn: TCON; // S7 连接函数块
  stFault: STRUCT
    Time: TOD;
    Source: STRING(32);
    StatusWord: WORD;
  END_STRUCT;
END_VAR

TRY
  fbS7Conn.Connect(); // 触发连接
CATCH EXCEPTION_COMMUNICATION DO
  stFault.Time := TIME_OF_DAY(); // 获取当前时间
  stFault.Source := 'S7 Connection';
  stFault.StatusWord := fbS7Conn.Status; // 记录底层状态码
  bAlarmActive := TRUE;
END_CATCH;

步骤 3：实施分级响应策略

根据故障持续时间自动切换处理模式：

• 首次故障：立即重试 1 次（RETRY_IMMEDIATE）；
• 3 秒内重复故障 ≥ 3 次：进入退避重连（指数退避：1s → 2s → 4s）；
• 累计故障 ≥ 10 次：锁定通信通道，触发 HMI 报警并禁用关联控制输出。

逻辑实现：

VAR
  tLastFault: TIME;
  nConsecutiveFailures: INT := 0;
  tBackoffDelay: TIME := T#1S;
END_VAR

TRY
  ModbusTCP_Client.Send(...);
  nConsecutiveFailures := 0; // 成功则清零计数
CATCH EXCEPTION_COMMUNICATION DO
  IF (TIME - tLastFault) <= T#3S THEN
    nConsecutiveFailures := nConsecutiveFailures + 1;
    IF nConsecutiveFailures >= 3 THEN
      tBackoffDelay := MIN(T#60S, tBackoffDelay * 2); // 最大延迟60秒
      fbTimer.IN := TRUE;
      fbTimer.PT := tBackoffDelay;
    END_IF;
  ELSE
    nConsecutiveFailures := 1; // 超过3秒，重新计数
  END_IF;
  tLastFault := TIME;
END_CATCH;

步骤 4：故障恢复验证闭环

CATCH 块不能仅记录错误，必须包含可验证的恢复动作：

• 发送测试帧（如 Modbus 功能码 0x03 读保持寄存器 0x0000）；
• 检查通信函数块的 Connected 与 Ready 输出同时为 TRUE；
• 对比上次成功通信的时间戳，确认间隔 < 2×心跳周期。

// 在 CATCH 块末尾添加恢复验证
CATCH EXCEPTION_COMMUNICATION DO
  // ... 故障记录逻辑（略）

  // 启动恢复验证
  fbRecoveryTest.Read(ADR(testReg), 1);
  bRecoveryPending := TRUE;
END_CATCH;

// 在主程序循环中检查恢复结果
IF bRecoveryPending AND fbRecoveryTest.Done THEN
  IF fbRecoveryTest.Error = FALSE THEN
    bCommFault := FALSE;
    nRetryCount := 0;
    bRecoveryPending := FALSE;
  END_IF;
END_IF;

四、避坑清单：95% 的 TRY-CATCH 失效源于这 5 类错误

五、真实故障模拟与验证方法

无需断网即可测试 TRY-CATCH 是否生效：

1. 在 Modbus 客户端函数块中，手动将 RemoteIP 设为 192.168.99.99（不存在地址）；
2. 运行程序，观察 CATCH 块内 bCommFault 是否在 1 个扫描周期内置 TRUE；
3. 恢复正确 IP 后，确认 CATCH 块不再触发，且 fb.Connected 变为 TRUE。

✅ 验证通过标志：从故障发生到 bCommFault := TRUE 的延迟 ≤ PLC 扫描周期 × 2。

六、性能影响实测数据（基于 CODESYS Runtime on Intel Atom x5-E3940）

结论：未触发时开销可忽略；触发时 18μs 延迟远低于典型通信周期（10ms~100ms），不影响控制实时性。

七、进阶技巧：嵌套 TRY-CATCH 实现故障熔断

当需对同一通信链路设置多级保护时，采用深度嵌套：

// 外层：捕获致命通信崩溃（如网卡离线）
TRY
  // 中层：捕获协议级错误（如 Modbus CRC 校验失败）
  TRY
    // 内层：捕获应用层超时（如响应等待 > 500ms）
    TRY
      ModbusTCP_Client.Read(ADR(buf), 5);
    CATCH EXCEPTION_COMMUNICATION DO
      nAppTimeouts := nAppTimeouts + 1;
      IF nAppTimeouts >= 5 THEN RAISE_EXCEPTION(EXCEPTION_COMMUNICATION); END_IF;
    END_CATCH;
  CATCH EXCEPTION_COMMUNICATION DO
    nProtoErrors := nProtoErrors + 1;
    IF nProtoErrors >= 3 THEN RAISE_EXCEPTION(EXCEPTION_COMMUNICATION); END_IF;
  END_CATCH;
CATCH EXCEPTION_COMMUNICATION DO
  // 进入熔断：关闭通道，通知 HMI
  fbModbus.Enabled := FALSE;
  bCircuitBreaker := TRUE;
END_CATCH;