结构化文本PLC编程整洁代码规范及分层状态机实现问询

问题1：2600行函数块是否可接受？规范做法与整洁代码经验 #

• 是否正常：绝对不可接受。PLC编程虽有工业场景的特殊性，但2600行的单一函数块（FB）完全违背了单一职责原则，会导致维护难度陡增、调试成本极高、复用性基本为零，甚至修改一处逻辑可能引发连锁bug。这种情况通常是长期迭代未重构、早期缺乏规范导致的“代码屎山”，绝非行业正常水平。
• 规范做法：
  • 按功能拆分：将FB_DriveCommands拆分为多个聚焦单一功能的小FB，比如FB_DriveSpeedControl（速度控制）、FB_DriveFaultHandling（故障处理）、FB_DrivePositioning（定位逻辑）等，每个FB只负责一个核心业务模块。
  • 分层模块化：采用“硬件层-基础逻辑层-业务逻辑层”的分层设计，底层FB封装与驱动器的硬件交互，上层FB实现业务规则，避免硬件代码与业务逻辑混杂。
  • 抽离通用逻辑：将重复出现的逻辑（如故障复位、状态验证）抽离为独立函数（FC）或基础FB，供多个模块调用，减少代码冗余。
• 整洁代码经验：
  • 命名精准：变量、FB、FC的命名要见名知意，比如用b_DriveReady而非b_Flag1，用FB_DriveAxisHoming而非FB_Axis1。
  • 注释聚焦：只注释“为什么这么做”，比如特殊业务规则或非直观的算法逻辑，避免冗余的“做了什么”注释。
  • 控制代码长度：单个FB/FC的代码行数尽量控制在200行以内，超过就考虑拆分。
  • 减少全局依赖：尽量通过FB的输入输出参数传递数据，避免使用全局变量，降低模块间耦合。
  • 简化分支嵌套：使用IF...ELSE、CASE...OF时，控制嵌套层级不超过3层，复杂分支拆分为独立子逻辑。

问题2：结构化文本的分层状态机（HSM）方案 #

如果必须用结构化文本实现HSM而非Twincat的UML状态图，有几种可行方案：

• 轻量自定义HSM：基于状态模式手动实现，用枚举定义主状态和子状态，每个状态对应独立的逻辑块，父状态负责子状态的切换调度。示例代码：

  TYPE E_MainState :
  (
    Idle,
    Homing,
    Running
  );
  END_TYPE
  
  TYPE E_HomingSubState :
  (
    StartHoming,
    WaitForHomingDone,
    HomingFault
  );
  END_TYPE
  
  VAR
    e_MainState : E_MainState := Idle;
    e_HomingSubState : E_HomingSubState := StartHoming;
    b_HomingDone : BOOL;
  END_VAR
  
  // 主状态调度
  CASE e_MainState OF
    Idle:
      // 触发回零的逻辑，切换到Homing状态
    Homing:
      // 子状态处理
      CASE e_HomingSubState OF
        StartHoming:
          // 发送回零指令，切换子状态
          e_HomingSubState := WaitForHomingDone;
        WaitForHomingDone:
          IF b_HomingDone THEN
            e_MainState := Running;
            e_HomingSubState := StartHoming; // 重置子状态
          END_IF;
        HomingFault:
          // 故障处理逻辑
      END_CASE;
    Running:
      // 运行状态逻辑
  END_CASE;
  

• 社区开源ST HSM库：PLC编程社区有不少基于结构化文本实现的HSM库，这些库封装了状态切换、事件处理的通用逻辑，可直接复用核心代码适配Twincat 3环境。
• FB嵌套实现分层：将每个分层状态封装为独立FB，父状态FB通过调用子状态FB实现分层逻辑，子状态的输出反馈给父状态用于判断状态切换，天然契合HSM的分层特性，且便于调试维护。

内容的提问来源于stack exchange，提问作者17tmh