问题从一次卡步骤开始
现场联调时遇到过一个典型问题：设备自动运行到夹紧后偶尔不进入下一步。在线监控看输出动作已经执行，到位信号也能看到，但流程就是停住。最开始大家怀疑传感器抖动，后来又查气压和节流阀，最后发现根因不止一个信号，而是程序里没有清楚表达“当前流程到底在哪一步”。
原程序用多个中间位拼流程：上料完成、定位允许、夹紧完成、加工允许分别散在不同网络里。单看每一段都能解释，但串起来很难判断当前状态、退出条件和异常去向。
现场现象
当时看到的现象有几个：
- 自动流程不是每次都卡，手动点动多数正常。
- 夹紧到位信号偶尔有短暂抖动，但不是每次抖动都会卡住。
- 复位后设备能重新启动，但不知道是从哪个条件恢复的。
- 新增扫码确认后，原来的完成位被多个网络引用，修改风险变高。
这种问题最麻烦的地方是：变量很多，但没有一个变量能回答“设备当前处于哪个步骤”。
排查顺序
我通常按下面顺序处理这类顺控问题。
第一步，先确认基础信号。不要一开始就改流程逻辑，先看输入点是否稳定、常开常闭是否一致、到位信号是否有抖动。
第二步，把当前流程位置找出来。如果程序没有显式步骤变量，就临时列出关键中间位，判断这些位组合起来对应哪个阶段。
第三步，单独审查状态切换条件。比如夹紧后进入加工，应该只依赖夹紧到位、工件确认、无报警、下游允许这几个条件，而不是散落在不同网络里的十几个隐含条件。
第四步，再看异常和复位。报警发生后回到 Idle，还是停在当前步骤等待人工处理，必须明确。
判断依据
显式状态划分的价值不是“写法更高级”，而是让判断依据变少。一个顺控至少应该能看出：
- 当前步骤是什么；
- 当前步骤的进入条件是什么；
- 当前步骤的退出条件是什么；
- 超时或报警时去哪里；
- 手动操作是否会改变自动步骤。
如果这些问题都要靠搜索几十个中间位才能回答，后续维护一定困难。
一个可落地的结构
我更倾向于把顺控拆成三层。
第一层是步骤变量，例如：
0 Idle
10 Prepare
20 Clamp
30 Process
40 Unload
900 Fault第二层只写步骤跳转条件。这里不要顺手写输出，不要把动作和跳转混在一起。
第三层按当前步骤执行输出动作。例如只有在 Clamp 步骤才允许夹紧阀输出，只有在 Process 步骤才允许加工动作。
这种结构不复杂，但在线监控时会清楚很多。
常见错误做法
一个常见错误是把每个动作完成位都当成流程状态。完成位只说明某个动作发生过，不一定说明设备现在处于哪个阶段。
另一个错误是手动模式直接推动自动流程。维修人员点动一个气缸后，自动步骤不应该悄悄往后跳。手动可以控制输出，但自动恢复前必须重新检查起始条件。
还有一种做法是报警复位后回到“看起来最近的步骤”。这在简单设备上可能暂时能跑，但复杂动作里很容易留下半完成状态。可恢复步骤必须经过评估，不确定时回 Idle 更稳妥。
最终建议
如果是新项目，顺控一开始就应该定义步骤变量和跳转表。即使不用复杂框架，也至少要让 HMI 能显示当前步骤名称和停留时间。
如果是旧项目改造，不建议一次重写全部程序。可以先从最容易卡住的一段流程开始，把关键步骤抽出来，把跳转条件集中整理，再逐步替换散落的中间位。
显式状态划分不会让首版程序更短，但能让联调、排障和后续改造更可控。对需要长期维护的设备，这个成本是值得的。