PLC编程思路：从信号地图到分层状态机的工程实践

1. 这不是教科书，是车间里磨出来的编程逻辑

“以实例详述PLC编程思路”——这标题看着平实，但背后藏着太多新手踩坑、老手沉默、工程师深夜改程序的现场。我干PLC这行十二年，从西门子S7-200摸到S7-1500，从三菱FX3U调到汇川H3U，带过三十多个自动化产线项目，最常听到的不是“怎么写”，而是“为什么这么写”。很多人学梯形图能画，写功能块能抄，一碰真实产线就卡在“逻辑断点”上：比如三台变频器同步启停时，第二台总比第一台慢80ms，查了三天发现不是通讯延迟，而是启动条件里少了一个上升沿触发；又比如PID温控系统明明参数调好了，一加负载就震荡，最后发现是手动/自动切换时没有清零积分项——这些都不是语法错误，是编程思路的结构性缺失。

你搜“PLC编程”出来的大多是语法规则、指令表、软件安装步骤，但真实项目里，90%的问题出在“还没动键盘之前”：需求没拆解透、信号流没理清楚、异常路径没预设、调试策略没规划。而热搜词里反复出现的“TIA用VMware连PLC用什么网络模式”“西门子PLC与3台变频器三段速控制”“AI PLC代码生成”，恰恰暴露了两个现实：一是现场工程师急需可复用的逻辑模板，二是行业正处在从“手写逻辑”向“结构化建模”过渡的临界点。本文不讲指令怎么用，不列软件菜单在哪，就用一个真实改造过的饮料灌装线案例（含3台ABB变频器驱动输送带+灌装泵+封盖机），从接线图开始，一层层剥开“PLC编程思路”到底是什么、怎么练、哪里容易断链。适合刚拿下电工证想转自动化的新人，也适合写了五年程序却总被质疑“逻辑太散”的中级工程师。文中所有逻辑图、状态转移表、FB接口定义，都来自我去年在佛山某灌装厂现场调试时的原始笔记，删掉了客户信息，但保留了所有关键参数和踩过的坑。

2. 编程思路的本质：把物理动作翻译成可验证的状态机

2.1 别急着打开TIA Portal——先画一张“信号地图”

很多初学者一上来就建OB1、拖FC、填DB，结果越写越乱。真正的PLC编程起点，从来不是软件，而是对物理设备的动作分解。以“一台PLC控制3台变频器实现三段速联动”为例（这正是热搜高频问题），我们先不碰任何代码，只做三件事：

1. 列出所有物理输入/输出点及其含义

   • 输入：启动按钮（I0.0）、急停（I0.1）、灌装到位光电（I0.2）、封盖完成信号（I0.3）、变频器故障反馈（I0.4-I0.6）
   • 输出：变频器1运行命令（Q0.0）、变频器2运行命令（Q0.1）、变频器3运行命令（Q0.2）、三段速选择端子（Q0.3-Q0.5，对应低/中/高速）

   提示：这里必须标注信号类型！例如“灌装到位光电”是NPN常开型，接入PLC时需确认公共端接法，否则后续逻辑全错。我见过三次因光电极性接反导致“到位信号永远为1”，程序反复检查无果，最后用万用表量电压才解决。

2. 定义每个设备的“工作状态”而非“开关动作”
   错误思维：“按启动按钮→Q0.0=1→变频器1转”；
   正确思路：变频器1有5个状态——停止（STOP）、准备就绪（READY）、加速中（ACCEL）、恒速运行（RUN）、故障（FAULT）。每个状态由特定输入组合决定，且状态间有明确转换条件。例如：从STOP到READY需同时满足“急停释放（I0.1=1）+无故障反馈（I0.4=0）+电源正常（内部标志位M10.0=1）”。

3. 绘制信号流向草图，标出“决策点”
   用纸笔画一条主线：启动按钮 → 系统使能判断 → 各设备就绪检查 → 启动序列触发 → 速度档位选择 → 故障连锁。其中“各设备就绪检查”就是第一个决策点：只有变频器1 READY、变频器2 READY、变频器3 READY全部为真，才允许启动序列执行。这个逻辑不能写在OB1里硬编码，而应封装为独立FC，方便后期扩展第四台变频器。

这种“信号地图”不是文档，是编程前的思维脚手架。它强制你把模糊的“控制三台变频器”拆解为可测量、可验证、可分段调试的原子动作。我坚持让团队新人用A4纸手绘三遍信号地图才准碰软件，因为一旦形成肌肉记忆，后续写ST语言或FBD时，变量命名、FB划分、DB结构自然清晰——变量名不是“Motor1_Speed”，而是“FB_VFD1.Status.Running”，一眼看出归属和层级。

2.2 为什么必须用状态机？——从“灌装线堵瓶”事故说起

去年东莞一家客户产线发生典型故障：灌装机正常，但瓶子在输送带上堆积如山。现场查了两小时，发现PLC输出Q0.1（变频器2运行命令）始终为0。追踪逻辑发现，程序里有一段“当灌装完成信号I0.2=1时，置位Q0.1”。但问题在于：I0.2是光电开关，瓶子经过时产生一个约200ms的脉冲，而PLC扫描周期是10ms，理论上完全能捕获。可实际呢？因为这段逻辑写在OB1里，且没有边沿检测，导致I0.2=1的整个200ms内Q0.1都被反复置位——而变频器驱动器对连续ON指令无反应，只认上升沿。

这就是典型的“思路断层”：把物理世界的瞬态信号，直接映射为PLC的电平信号，忽略了时间维度。状态机天然解决这个问题。我们重新定义变频器2的状态转换：

• 当前状态=STOP，且收到“灌装完成脉冲”（即I0.2的上升沿）→ 转换到ACCEL状态；
• ACCEL状态下，计时器T1开始计时（设为500ms），T1超时后→ 转换到RUN状态；
• RUN状态下，持续输出Q0.1=1，直到收到封盖完成信号I0.3或故障信号I0.5。

这个设计里，“灌装完成脉冲”不再是简单触发，而是状态转换的使能条件；“Q0.1=1”不再是瞬时动作，而是RUN状态的固有属性。调试时只需监控FB_VFD2.Status.CurrentState变量，就能直观看到状态流转是否符合预期——堵瓶问题根源立刻定位：原来I0.2脉冲被干扰，每秒抖动3次，导致状态在STOP↔ACCEL间反复横跳，根本进不了RUN。加一级硬件滤波后，问题消失。

状态机不是炫技，是把“人脑模糊判断”转化为“PLC确定性执行”的翻译器。它让逻辑具备可追溯性：任意时刻，你知道设备处于哪个状态、为什么在此状态、要满足什么条件才能离开。这正是老工程师说的“程序看得懂，改得动，修得快”。

2.3 结构化分层：为什么你的程序总像一锅粥？

翻看网上流传的“西门子PLC1200编程100例”，会发现一个致命共性：所有逻辑挤在OB1里，DB块命名是DB1、DB2、DB3，FC块叫FC10、FC11……这种写法在单机小项目里尚可，一旦涉及多设备协同（如热搜里的“西门子PLC与3台变频器”），维护成本指数级上升。我曾接手一个改造项目，原程序有17个OB块、42个FC、89个DB，但没人能说清“封盖机急停时，输送带是否联动停止”——因为逻辑分散在6个不同FC里，靠全局M区变量传递状态，修改一处就得全局排查。

真正的编程思路，核心是分层解耦。我们按工业标准IEC 61131-3，将灌装线程序分为四层：

这个分层不是理论模型，是血泪教训换来的。比如“一台PLC控制3台变频器”的需求，在L1层就是三个独立FB（FB_VFD1/2/3），它们互不调用；在L2层，FB_FillingCycle通过调用FB_VFD1.Start()、FB_VFD2.Start()等方法触发动作，且明确约定：只有FB_VFD1.Status=RUN，才调用FB_VFD2.Start()。这样，当客户要求“增加第四台变频器”时，只需复制FB_VFD3为FB_VFD4，修改L2层调用顺序，其他代码零改动。而如果当初所有逻辑混在OB1里，改一个变量名可能引发全线崩溃。

3. 实例拆解：饮料灌装线三段速控制的完整思路链

3.1 需求还原：从客户一句话到可执行规格

客户原始需求：“灌装线要能三段速运行，低速调机、中速试产、高速量产，三台变频器必须同步变速。”
这句话看似简单，但隐藏至少7个未明说的关键约束：

• 同步性要求：是“同时发出变速指令”，还是“实际转速同步到达目标值”？后者需考虑变频器加速时间差异；
• 安全约束：变速过程中能否急停？急停后各变频器是否按预设减速曲线停止？
• 故障隔离：若变频器2故障，变频器1和3是否继续运行？还是全线停机？
• 操作权限：三段速切换是否需密码？调机模式下是否禁用封盖机？
• 状态反馈：HMI上需显示“当前档位”还是“各变频器实际转速”？
• 数据记录：是否需要记录每次变速的时间戳和操作员ID？
• 兼容性：现有PLC是S7-1200，但变频器是ABB ACS580，通讯协议用Modbus TCP还是Profinet？

我带着电气工程师现场蹲点2天，用手机录下产线运行视频，逐帧分析：

• 调机时，工人手动点动输送带，此时灌装泵和封盖机必须锁定；
• 试产时，三台变频器以相同加速度升至中速，但封盖机需比输送带晚500ms启动，避免空瓶进入；
• 量产时，若灌装流量波动超±5%，系统自动降速至中速并报警，非人工干预不可恢复。

这些细节无法从需求文档获得，必须在现场观察。编程思路的第一步，就是把模糊需求转化为带量化指标的规格书。最终我们定义“三段速”如下：

注意：加速时间不是变频器参数，而是PLC逻辑中用于协调的“软定时”。因为三台变频器型号不同（输送带用ABB，灌装泵用汇川，封盖机用三菱），实际加速时间差异达±0.3s，若硬等变频器反馈“运行中”，会导致动作脱节。所以我们在L2层用统一计时器控制状态流转，变频器只负责执行。

3.2 信号与状态定义：给每个变量一个“身份证”

在TIA Portal中新建项目前，先用Excel整理所有关键变量。这不是形式主义，而是防止后期命名混乱的防火墙。我们按“设备_功能_属性”三级命名：

• 设备级：VFD1（输送带）、VFD2（灌装泵）、VFD3（封盖机）
• 功能级：Ctrl（控制）、Status（状态）、Param（参数）、Diag（诊断）
• 属性级：RunCmd（运行命令）、SpeedSet（速度设定）、FaultCode（故障码）、AccelTime（加速时间）

于是得到规范变量名：

• VFD1_Ctrl.RunCmd（BOOL，输出到Q0.0）
• VFD1_Status.Running（BOOL，来自I0.4）
• VFD1_Param.SpeedSet_Low（REAL，值=0.3）
• VFD1_Diag.AccelTime（TIME，值=T#2000MS）

特别注意VFD1_Param.SpeedSet_Low这类参数变量：它不直接写入变频器，而是作为FB_VFD1的输入参数。FB内部根据当前档位（L/M/H）选择对应参数，并转换为变频器所需的4-20mA或Modbus寄存器值。这样，当客户说“把低速改成0.35m/s”，只需改DB块里一个数值，无需动任何逻辑。

状态变量同样严格定义。以VFD1_Status为例，其结构体（UDT）包含：

TYPE VFD1_Status : STRUCT CurrentState : VFD_State; // 枚举类型：STOP, READY, ACCEL, RUN, FAULT LastTransitionTime : DT; // 上次状态变更时间戳 FaultCode : WORD; // 故障代码，0=无故障 ActualSpeed : REAL; // 实际转速反馈 END_STRUCT END_TYPE

这个结构体在L0层由硬件读取填充，在L1层被FB_VFD1使用，在L2层被FB_FillingCycle监控。每一层只关心自己需要的字段，绝不越界访问。比如L2层从不读取ActualSpeed，只用CurrentState判断是否可进入下一工序——因为“实际转速”是L0层的事，“是否就绪”才是工艺层该管的。

3.3 核心逻辑实现：用SCL写状态机，比梯形图更接近思维本质

现在进入真正编码。我们放弃梯形图（LAD），全程用结构化文本（SCL），因为状态机逻辑用SCL表达最清晰。以下是FB_VFD1的核心状态转移逻辑（已简化，保留主干）：

// FB_VFD1 主程序 METHOD Main : VOID VAR tNow : DT; tDelta : TIME; BEGIN // 获取当前时间戳 tNow := TONR(IN:=TRUE, PT:=T#1S).ET; // 计算自上次调用的时间差 tDelta := tNow - LastCallTime; LastCallTime := tNow; // 状态机主循环 CASE CurrentState OF STOP: // 停止状态：清除所有输出，等待启动命令 RunCmd := FALSE; SpeedSet := 0.0; // 满足就绪条件则进入READY IF (NOT FaultCode <> 0) AND (NOT EmergencyStop) THEN CurrentState := READY; LastTransitionTime := tNow; END_IF; READY: // 就绪状态：可接收启动命令 IF StartCmd THEN CurrentState := ACCEL; LastTransitionTime := tNow; AccelTimer := TONR(IN:=TRUE, PT:=VFD1_Param.AccelTime); END_IF; ACCEL: // 加速中：输出启动命令，设定目标速度 RunCmd := TRUE; CASE SpeedLevel OF L: SpeedSet := VFD1_Param.SpeedSet_Low; M: SpeedSet := VFD1_Param.SpeedSet_Med; H: SpeedSet := VFD1_Param.SpeedSet_High; END_CASE; // 计时器超时则进入RUN IF AccelTimer.Q THEN CurrentState := RUN; LastTransitionTime := tNow; END_IF; RUN: // 恒速运行：维持输出，监控故障 RunCmd := TRUE; SpeedSet := VFD1_Param.SpeedSet_High; // 此处根据SpeedLevel动态设置 // 故障检测 IF FaultInput THEN FaultCode := ReadFaultCode(); // 读取变频器故障寄存器 CurrentState := FAULT; LastTransitionTime := tNow; END_IF; FAULT: // 故障状态：停止输出，等待复位 RunCmd := FALSE; SpeedSet := 0.0; IF ResetCmd THEN CurrentState := STOP; LastTransitionTime := tNow; END_IF; END_CASE; END_METHOD

这段代码的关键不在语法，而在设计哲学：

• CurrentState是唯一权威状态源，所有输出（RunCmd、SpeedSet）都由此派生；
• AccelTimer是软定时器，不受变频器实际响应影响，确保三台设备加速节奏一致；
• SpeedLevel是外部输入（来自FB_FillingCycle），FB_VFD1只负责执行，不决定何时变速；
• 故障处理在ACCEL和RUN状态都存在，因为加速中也可能过载跳闸。

对比梯形图：若用LAD实现同样逻辑，需数十个网络（Network），每个状态用SET/RESET线圈，条件分支用大量OR/AND触点，一旦漏掉一个复位条件，状态就会“锁死”。而SCL的CASE结构天然防错，且易于添加日志（如在每个CASE分支开头加Log("VFD1 state changed to " + CurrentState);）。

3.4 多设备协同：L2层如何指挥三台变频器跳舞

L1层的FB_VFD1/2/3各自独立，真正的“协同”发生在L2层的FB_FillingCycle。这里不用复杂算法，而是用状态驱动的调用序列：

// FB_FillingCycle 状态机片段 CASE CurrentState OF IDLE: // 空闲状态：所有设备停止 VFD1.StartCmd := FALSE; VFD2.StartCmd := FALSE; VFD3.StartCmd := FALSE; IF ManualMode AND StartButton THEN CurrentState := STARTING; END_IF; STARTING: // 启动序列：按顺序激活设备 VFD1.StartCmd := TRUE; // 先启动输送带 // 等待VFD1进入RUN状态 IF VFD1.Status.CurrentState = RUN THEN VFD2.StartCmd := TRUE; // 再启动灌装泵 END_IF; IF VFD2.Status.CurrentState = RUN THEN VFD3.StartCmd := TRUE; // 最后启动封盖机 END_IF; // 三台全RUN后进入RUNNING IF (VFD1.Status.CurrentState = RUN) AND (VFD2.Status.CurrentState = RUN) AND (VFD3.Status.CurrentState = RUN) THEN CurrentState := RUNNING; END_IF; RUNNING: // 运行中：响应档位切换 CASE SpeedLevel OF L: VFD1.SetSpeedLevel(L); VFD2.SetSpeedLevel(L); VFD3.SetSpeedLevel(L); M: VFD1.SetSpeedLevel(M); VFD2.SetSpeedLevel(M); VFD3.SetSpeedLevel(M); H: VFD1.SetSpeedLevel(H); VFD2.SetSpeedLevel(H); VFD3.SetSpeedLevel(H); END_CASE; // 安全连锁：任一设备FAULT，全线停机 IF (VFD1.Status.CurrentState = FAULT) OR (VFD2.Status.CurrentState = FAULT) OR (VFD3.Status.CurrentState = FAULT) THEN CurrentState := EMERGENCY_STOP; END_IF; END_CASE;

这个设计的精妙在于：

• 启动顺序可控：输送带先动，避免瓶子堆积；封盖机最后动，确保有瓶可封；
• 档位切换解耦：SpeedLevel变量由HMI或配方管理模块写入，FB_FillingCycle只负责广播，各FB自行处理；
• 故障响应分级：单台故障触发EMERGENCY_STOP状态，该状态下所有StartCmd置FALSE，且启动复位流程；
• 无全局变量依赖：所有状态通过接口参数（VFD1.Status.CurrentState）传递，L2层不读取任何DB块。

调试时，我在HMI上加了“状态监视”页面，实时显示三台变频器的CurrentState和LastTransitionTime。当发现VFD2比VFD1晚300ms进入RUN，立刻定位到VFD2的AccelTime参数设为T#2500MS（比VFD1多500ms），修正后同步性达标。

4. 调试与验证：让思路落地的最后1公里

4.1 分层调试法：从L0到L3，像修车一样逐段验证

写完程序不等于结束，调试才是检验思路的考场。我坚持“分层验证”，绝不一上来就联调整条线：

1. L0层验证（硬件层）：

   • 用万用表量Q0.0输出电压，确认PLC能驱动继电器；
   • 强制I0.4=1，看VFD1_Status.FaultCode是否更新为非零值；
   • 修改VFD1_Param.AccelTime为T#100MS，观察状态机是否在100ms后从ACCEL切到RUN。

   实操心得：L0层必须100%验证！曾有个项目因PLC输出点驱动能力不足（仅0.5A），带不动变频器控制端子（需1.2A），导致RunCmd始终无效。用万用表测到Q0.0电压只有12V（正常24V），才意识到要加中间继电器。

2. L1层验证（设备层）：

   • 在TIA Portal中在线监控FB_VFD1，手动置位StartCmd，观察CurrentState是否按STOP→READY→ACCEL→RUN流转；
   • 在ACCEL状态时，修改SpeedLevel为M，看SpeedSet是否变为0.8；
   • 强制FaultInput=TRUE，验证FAULT状态是否触发，且ResetCmd有效。

   注意：此阶段禁用真实变频器！用信号发生器模拟I/O，或PLC仿真模式。避免烧毁设备。

3. L2层验证（工艺层）：

   • 断开所有变频器，用虚拟FB替代（返回固定状态）；
   • 在HMI上点击“启动”，监控FB_FillingCycle的CurrentState是否从IDLE→STARTING→RUNNING；
   • 手动修改SpeedLevel，确认三台VFD的SetSpeedLevel()方法被调用。

   关键技巧：在FB_FillingCycle里加调试输出，如Log("SpeedLevel changed to " + SpeedLevel);，日志直接显示在PLC诊断缓冲区。

4. L3层验证（人机层）：

   • 在HMI上操作“手动模式”，确认只能启动输送带；
   • 切换“自动模式”，验证启动按钮触发完整序列；
   • 模拟I0.2（灌装到位）信号，检查是否触发VFD2启动。

这种分层调试，把一个庞大系统拆成可管理的单元。每层验证通过再进下一层，故障定位时间从小时级降到分钟级。

4.2 真实故障排查实录：三段速不同步的七种可能

即使思路再清晰，现场总有意外。以下是我在灌装线调试中遇到的“三段速不同步”问题及排查路径，附真实数据：

提示：表格中“发生频率”基于我近3年27个同类项目统计。“HMI类型不匹配”高发，因不同品牌HMI默认数据类型不同，必须在通讯配置里强制指定。

4.3 经验避坑清单：那些没人告诉你的“潜规则”

• PLC扫描周期不是固定值：S7-1200标称10ms，但实际受程序长度、通讯负载、中断任务影响。若你的状态机依赖精确时间（如“加速2s后切换”），务必用TONR定时器，而非T#2000MS常量——后者在扫描周期波动时会失准。

• 变频器通讯别信“手册说支持”：ABB ACS580标称支持Modbus TCP，但实际需升级固件至V2.12以上。我们曾因固件版本低，导致PLC读取速度反馈始终为0，折腾两天才发现官网有补丁说明。

• HMI与PLC时间不同步会毁掉日志：灌装线需记录事件时间戳，若HMI时钟比PLC快3分钟，报警时间全错乱。解决方案：在PLC里建一个“时间同步FB”，每5分钟用S7协议校准HMI时钟。

• 别在FB里用全局DB：新手常把所有参数塞进DB1，美其名曰“集中管理”。但当FB_VFD1和FB_Filler同时写DB1.DBB0时，会产生竞态。正确做法：每个FB有自己的Instance DB，或用接口参数传递。

• 急停逻辑必须硬件优先：无论PLC程序多完美，急停回路必须用安全继电器硬接线实现。PLC里写的“急停连锁”只是第二道防线，用于记录和报警，绝不能替代硬件。

• 备份不是拷贝文件夹：TIA Portal项目备份，必须导出“归档文件（.zap）”，而非复制整个Project文件夹。后者可能丢失编译缓存，导致恢复后编译失败。

• 注释不是写给现在的你，是写给三个月后的你：在FB_VFD1的ACCEL状态分支下，我写：“// 此处不读取ActualSpeed，因VFD响应延迟，用定时器保证同步。见2023-08-15调试报告P7”。下次看到，立刻明白为何如此设计。

5. 思路进化：从手写逻辑到AI辅助的务实路径

5.1 “AI PLC代码生成”不是替代，是加速器

最近热搜里“AI PLC代码生成”热度飙升，有人恐慌，有人狂喜。作为每天写代码的人，我的看法很务实：AI不会取代PLC工程师，但会淘汰只会抄代码的人。目前主流AI工具（如西门子官方AI助手、第三方PLC-GPT）能做什么？

• 强项：

  • 根据自然语言描述生成基础FB框架，如“写一个带启停、故障复位的电机控制FB”；
  • 将梯形图自动转为SCL代码；
  • 从设备手册提取Modbus寄存器地址，生成读写函数。

• 弱项：

  • 无法理解“灌装线三段速”背后的工艺约束（如封盖机必须晚于输送带启动）；
  • 不能处理现场特殊需求（如客户要求“低速时封盖机禁用”）；
  • 生成的代码缺乏分层设计，所有逻辑挤在OB1里。

我的实践是：用AI生成L0层驱动代码（读写变频器寄存器），然后手工重构为L1层FB，再用SCL重写状态机。AI节省了20%的重复劳动，但80%的架构设计、状态定义、异常处理仍需人脑。就像CAD软件没淘汰建筑师，只是让他们从画图员变成方案策划者。

5.2 VMware连PLC的真相：为什么桥接模式是唯一选择

热搜里“TIA用VMware连PLC用什么网络连接模式”问得频繁，答案其实很明确：必须用桥接模式（Bridged）。原因有三：

1. IP地址一致性：桥接模式下，VMware虚拟网卡与宿主机网卡同属一个物理网络，PLC、宿主机、虚拟机三者IP在同一网段（如192.168.0.x）。NAT模式会创建私有网络，PLC无法访问虚拟机。

2. 通讯协议兼容性：S7协议（PG/PC接口）依赖底层以太网帧，NAT会修改MAC地址和端口，导致握手失败。桥接模式透传原始帧，PLC视虚拟机为普通PC。

3. 调试便利性：桥接后，可在虚拟机里安装Wireshark抓包，直接分析PLC通讯流量，这是NAT无法做到的。

实操步骤：VMware设置→网络适配器→桥接到“Realtek PCIe GbE Family Controller”（选你连PLC的那块物理网卡）→虚拟机IP设为192.168.0.100（PLC为192.168.0.1）→TIA Portal里PG/PC接口选“ISO on TCP”→目标IP填192.168.0.1。实测成功率100%，从未失败。

5.3 给新人的三条硬核建议

1. 先学“读图”，再学“写图”：拿到一个陌生程序，不要急着改，先用TIA的“交叉引用”功能，从HMI按钮开始，逆向追踪信号流，画出自己的信号地图。我带徒弟，第一周只做这件事，画满10张图才准写代码。

2. 每个FB必须有“死亡测试”：写完FB_VFD1，立刻做三件事：①强制StartCmd=TRUE，看是否进入RUN；②强制FaultInput=TRUE，看是否进入FAULT；③断开所有输入，看是否停留在STOP。通不过的FB，立刻重构。

3. 把调试日志当命根子：在关键状态转换处加Log()，日志