AF框架状态机在S7-1200/1500中的实现：从SCL编程到顺序控制实战

AF框架Application Framework在西门子S7-1200/1500的圈子里算是绕不开的一套SCL开源框架。我最近在整理它文档的翻译笔记刚好把第九章节的内容在博途里跑了一遍所以顺手把这章的翻译心得、代码细节和踩过的坑整理出来。这一章讲的是状态机StateMachine与顺序控制的框架实现也就是很多人问的“怎么用AF框架把设备流程拆清楚”。它解决的问题很典型一台设备十几步动作用置位复位线圈写逻辑改一步就牵连全局最后没人敢动程序。AF框架的第九章给出的处理方式是把流程拆成离散状态用统一的状态字和迁移条件来管理逻辑清晰、可扩展、现场调试也直观。这份内容适合正在用TIA博途写S7-1200/1500程序、但被复杂工艺流程和频繁修改折磨的工程师。不管你是刚接触SCL还是已经有几年项目经验只要能看懂基础的SCL语法跟着后面的步骤在博途里建一个测试项目基本就能把这套思路用到自己项目里。第九章在AF框架整个体系里属于“承上启下”的位置前面章节解决了数据类型、IO架构和报警设计的问题从这一章开始程序才算是真正进入了“设备动作管理”的层面。1. 第九章在AF框架整体架构里的定位1.1 AF框架到底解决了什么问题AF框架的初衷很简单就是把PLC程序从“一张图纸谁都不敢动”变成“一个个小功能块可以独立修改”。它把所有逻辑封装成带接口的FB用专门的UDT用户自定义数据类型来封装数据尽量避免直接裸用M区和临时变量满天飞的写法。这种思路在S7-300时代其实也有人用但那时候受限于硬件资源做得很苦。S7-1200/1500的计算能力和存储空间上来了SCL的编辑体验也好了一大截AF框架这种结构化写法的优势才真正被放大。我在实际项目里的体会是AF框架最大的收益不在“节省几KB内存”而在“让不同工程师能协作改程序”。以前别人写的梯形图你不看注释根本不敢碰但用了AF框架的块结构数据都走接口逻辑都封装在块内部外部只看到输入输出参数修改的边界就清晰了。第九章的状态机模型正好是把这种“封装”理念从单个块上升到整机设备的层面让整台机器的动作流程也变成了一套可以独立维护的组件。1.2 为什么要专门啃第九章而不是直接从第一章看很多初次接触AF框架的人喜欢按文档页码从头翻到尾我一开始也这么干但效果不好。前面几章讲的是基础数据类型、IO信号处理和报警管理内容比较枯燥而且如果没有实际项目经验看完了也不知道这些类型到底怎么配合。第九章就不一样它讲的顺序控制和状态管理是每个PLC工程师每天都头疼的事代入感特别强。当你理解了第九章的状态机写法再回头去看前面的数据类型定义会自然明白为什么要那样设计。比如状态字StateWord为什么采用DWORD而不是Struct为什么报警块和控制块要分开这些在状态机逻辑里都能找到答案。所以我的建议是时间紧就先啃第九章遇到不懂的类型定义再往前翻这种“按需检索”的阅读方式在技术文档面前反而最高效。另外从框架演进的角度看第九章的内容也最具复用价值。IO规划和报警组态在不同项目里差异很大但设备动作管理的框架基本是通用的手动模式、自动模式、暂停、急停恢复、报警响应这些都是标准需求。把这一章吃透等于掌握了一套可以跨行业套用的“设备控制底座”换行业做项目时底层的状态机不用重写只需要改状态列表和迁移条件。2. 核心设计思想用状态模型替代“线圈思维”2.1 AFC状态机的基本运行模式第九章反复强调一个观点不要把设备动作写成“动作A触发完成后再触发动作B”这种链条式逻辑而是要把设备行为描述成“若干稳定状态状态之间的迁移条件”。链条式逻辑的问题是一旦中间某一步被报警或急停打断整个链条的后续步骤都不会执行恢复时你得写大量“假动作”来兜底。而状态机模型天然适合处理异常不管设备处于哪个状态只要急停信号来了都无条件迁移到急停状态恢复时根据当前状态决定下一步去哪里。这里我先把状态机的基本运行套路说出来后面实操部分再展示代码。状态机运行时每个扫描周期只做三件事判断当前状态下的迁移条件是否成立执行该状态对应的动作更新输出和状态字。这三个动作在一个FB内部完成外部只看到“当前状态”和“请求迁移”这两个接口。所谓“迁移”不外乎四种形式条件自动跳转比如温度到了就进入下一步、操作员触发通过触摸屏的按钮信号、报警中断跳转报警位触发跳入故障状态、复位确认跳转故障复位后回到初始状态。这套模型中最重要的概念是“优先级”。条件的优先级一定要分清楚急停条件永远比自动运行条件优先级高报警条件又比正常运行条件优先级高。我记得文档原文里给了一个很形象的比喻状态机不是“贪吃蛇”它不会按顺序一条道走到黑而是像一个执勤的保安每时每刻都在判断“现在最该干什么”。操作优先级需要在编程前就定出来而不是在CASE语句里随手写否则后面加需求时非常容易产生逻辑冲突。2.2 第九章里几个关键的数据载体翻译第九章时我特别注意了里面反复出现的三个数据对象状态字、状态ID、迁移条件结构。这三个对象看起来简单却是整个状态机的骨架。状态字在AF框架里一般是一个DWORD按位划分成手动位、自动位、故障位、急停位等用于上位机读取和外部块联动。用一个DWORD的好处是可以通过一条点指令直接传给触摸屏或者OPC UA不用打包多个变量。状态ID则是一个INT用来标识设备当前处于具体哪个步骤比如0代表空闲100代表自动运行第一步200代表故障停止。状态ID可以比状态字分得更细我在项目里通常把它和触摸屏的“文本列表”绑定这样WinCC或威纶通上就能直接显示“清洗中”“灌装中”之类的文字状态。迁移条件结构是第九章里最有特色的设计。它把每一步的“触发条件”和“动作输出”都配置化而不是写死在CASE分支里。实际工程里很多设备的工艺流程经常微调比如一个工位本来要等3秒现在改成等5秒如果这个超时值是写在CASE语句里的改一次就要重新下载PLC程序。用配置化的迁移条件结构后这些参数都放在全局DB里上位机甚至可以直接通过触摸屏数值输入来修改程序本身不用动这对设备调试阶段的效率提升非常明显。3. 实操在TIA博途里把第九章的状态机搭起来3.1 准备工作库的导入和全局数据类型创建要在自己项目里复用AF框架第九章的状态机逻辑首先得把框架核心库导入博途。这里提醒一下不同TIA版本的库文件不能直接通用V15的库导入V17时偶尔会报版本不兼容遇见这种情况不要硬来去官网找对应版本重下。导入库之后在项目树里展开“库→全局库”把AF_StateMachine这个核心FB拖到“程序块”文件夹下博途会自动帮你创建对应的背景DB接口。建立全局DB时我习惯把设备的状态参数集中存放专门建一个“g_设备状态”的全局DB里面放两类数据一类是每个设备的状态ID和状态字另一类是该设备状态机用到的所有可调参数比如每步的超时时间、允许的偏差范围。这样做的好处是现场调试时维修人员不用进FB内部修改逻辑直接在全局DB的监控表里改参数就能调节工艺行为降低了出错的概率。还要创建几个UDT包括“状态信息”类型包含状态ID、状态字、时间戳、超时时间等以及“迁移条件”类型包含多个BOOL量和一个TIME量。这些类型在第九章的英文原稿里都有例子我翻译时保留了原来的字段名只是在注释里加中文说明。字段名不建议改成中文因为后续SCL代码里会大量引用这些字段用中文变量名也能编译但在库文件跨项目拷贝和多语言团队协作时中文名经常出幺蛾子。3.2 搭一个三段式顺序控制的状态机代码理论上的东西讲了不少还是直接给一段能在博途里运行的SCL代码更实在。这个例子是三段式流程设备上电复位第一步气缸伸出到位第二步等待3秒第三步气缸缩回然后回到初始。为了方便说明代码里我简化了报警处理逻辑只保留核心状态迁移骨架实际项目里你在此基础上扩展状态和条件就行。// 状态ID定义 // 0 空闲初始 // 10 自动启动 // 20 气缸伸出 // 30 等待完成 // 40 气缸缩回 // 999 故障停止 CASE g_设备状态.状态ID OF 0: // 空闲状态等待自动启动信号 IF g_设备状态.自动请求 AND NOT g_设备状态.急停 THEN g_设备状态.状态ID : 10; END_IF; 10: // 自动启动复位各类输出 #气缸伸出 : FALSE; #运行指示 : TRUE; IF g_设备状态.启动确认 THEN g_设备状态.状态ID : 20; END_IF; 20: // 气缸伸出动作 #气缸伸出 : TRUE; IF #气缸伸出到位 THEN #伸出到位时刻 : T_PLC_MS(); g_设备状态.状态ID : 30; END_IF; 30: // 等待3秒 IF T_PLC_MS() - #伸出到位时刻 T#3S THEN g_设备状态.状态ID : 40; END_IF; 40: // 气缸缩回 #气缸伸出 : FALSE; IF #气缸缩回到位 THEN g_设备状态.状态ID : 0; #运行指示 : FALSE; END_IF; 999: // 故障停止等待复位 #气缸伸出 : FALSE; #运行指示 : FALSE; IF g_设备状态.故障复位 THEN g_设备状态.状态ID : 0; END_IF; ELSE: g_设备状态.状态ID : 999; END_CASE;这段代码里用到的T_PLC_MS是S7-1200/1500的系统函数返回一个64位毫秒时间戳用来做短延时非常方便比TON定时器块的代码量小。这里有个容易忽略的细节在状态30里计算延时必须用“伸出到位那一刻”的时间戳做基准而不是进入状态30的扫描周期时刻。如果直接用进入状态的时刻做计算会因为扫描周期的抖动导致延时每次都不一样这在需要精确节拍的生产节拍应用里是致命的。3.3 状态迁移表的设计手册和参数整定AF框架第九章里最值得抄的其实是那张“状态迁移表”它不是代码而是一张用于和工艺工程师沟通的对照表格。我给每个设备做状态机之前都会先在纸上把这张表画出来左边三列分别是当前状态、触发条件、执行动作右边两列是下一状态和备注。这张表每填一行程序里的CASE分支就多一段等逻辑讨论清楚了再动手写代码比直接打开博途边想边写要省事得多。表格做完后很多参数其实不需要写死在程序里。比如“等待3秒”在表格里我标注为可调参数然后把这个参数映射到全局DB里某一个TIME变量上。触摸屏组态时把该变量关联到“数值显示数值输入”控件操作员就可以在生产现场直接调整节拍不用打开博途改程序。这样修改在技术上是安全的因为程序结构没有变化只是延时值变了而已对现场工程师来说非常友好。还要强调一点每个状态机的超时时间必须单独成变量不要共用一个全局TIME变量。我踩过这个坑两个不同设备的状态机共享同一个超时时间结果一个设备改参数另一个也跟着变查了好久才发现是DB变量关联重复了。参数隔离是模块化编程的基本素养也是AF框架从一开始就强调的设计原则。4. 上位机、通讯和安全回路的联动方法4.1 把状态字和状态ID抛给触摸屏和上位机状态机做出来后上位机的组态就变得很轻松。以威纶通触摸屏和S7-1200的通讯为例你只需要在设备列表里新建一个MODBUS TCP或S7连接具体看你用驱动类型然后把全局DB里的状态ID变量映射到触摸屏内部的LW寄存器上再在PLC里调用一条MOVE指令把状态ID转成字符串对应的数值。这里有个小技巧状态ID最好按十进制位做规划比如1-99是空闲/待机100-199是自动流程步骤200-299是报警300-399是手动调试步骤这样触摸屏上的文本列表可以按区段配置条理非常清楚。如果是S7-1500配上WinCC Unified或者传统的WinCC操作更直接因为TIA Portal集成环境下可以直接把DB变量拖到画面里无需额外通讯配置。但国内现场大量使用的还是威纶通或昆仑通态这类第三方触摸屏它们和S7-1200的标签导入功能现在已经很成熟只要提前在PLC变量表里把状态ID的符号名起好触摸屏软件能直接读取符号表导入省去手动输入地址的功夫也顺便避免了地址错误。另一位同事的项目里用了Intouch和S7-1500做通讯接的是S7-1500自带的OPC UA服务器。这种情况下状态机和上位机的对接更简单上位机直接订阅“g_设备状态.状态ID”和“g_设备状态.状态字”这两个节点即可。需要注意OPC UA浏览DB变量时变量名如果是中文部分老版本客户端软件会出现乱码现象所以OPC公开的节点我建议都单独映射到一组英文变量上尽量避免直接用中文符号名做通讯映射。4.2 用状态机统一协调变频器、阀门和机器人自动化线体上很少只有一套状态机往往是多设备协同变频器控制输送带阀门控制流道机器人在某个工位上下料。AF框架第九章的思路完全可以横向复制到这些执行机构上每个变频器、每个阀门、每个机器人各自维护一个自己的状态机FB再在上一级建一个“设备协调器”的FB来做状态同步。举个我实际调试过的例子输送带由ABB变频器驱动PLC通过PROFINET和变频器交换控制字和状态字。变频器有两种控制方式本地面板控制和远程总线控制状态机里我把这两种方式分别建模成“本地待机”和“远程运行”两个状态。当急停或安全光栅触发时PLC不是直接丢一个停止位给变频器而是先把自身状态机切到“安全中断”状态再由该状态下发“OFF2”自由停车控制字给变频器。这个转发逻辑保证了停止命令的优先级不会被自动运行状态下的启动命令覆盖安全信号永远最后一锤定音。机器人和PLC的PROFINET通讯地址对应也是这套思路。机器人的每个工作流程用机器人侧程序定义好PLC侧只维护“启动请求”“工作完成”“紧急停止”三个控制位和“机器人忙”“机器人故障”“当前工步”三个状态位。在PLC状态机里机器人不是无脑发送所有命令而是在不同状态下按需置位对应控制位。比如只有在“请求机器人抓取”状态下才允许把启动请求位置TRUE在“安全中断”状态下强制把它清掉这样就避免了机器人控制器同时收到多个互相矛盾的指令。4.3 安全回路与muting功能块怎么融合进来第九章状态机模型和安全PLC程序的结合是很多做安全项目的工程师关心的点。S7-1200F和S7-1500F的安全程序一般用LAD/FBD来写安全光栅、急停按钮这些信号进安全程序处理后通过F-IO映射到标准程序区。在状态机里我不建议把安全逻辑直接写在CASE分支里而是建议在状态机FB的入口处加一个统一的安全门禁判断。具体做法是在FB的输入参数ISafeStop上接来自安全程序的急停输出。状态机每一轮扫描先判断这个位如果为TRUE不管当前状态ID是什么都直接跳转到安全停止状态。这个跳转要放在Case语句外面做也就是说状态机FB的第一句就是“IF急停 THEN 强制进入停止状态”而不是在每个CASE分支里逐个判断否则总有漏网的状态没写急停响应。muting功能块安全光栅屏蔽在AF框架里通常作为独立FB实现它不直接参与状态机流转而是输出一个MutingActive位。这个位的作用是在允许的时间窗内屏蔽安全光栅的触发信号让物料可以正常通过。把muting功能和状态机的联动点放在状态迁移条件上比如“在自动运行第3步且muting激活时光栅信号不作为迁移条件”这种设计既符合安全标准的要求又不会让安全PLC程序变得面目全非。安全程序里只保留muting功能本身的时间窗逻辑联动的条件判断全部由状态机给出。5. 常见编译坑和现场调试经验5.1 编译报错的几个高频雷区第一次把AF框架的状态机块拖到博途里编译时如果报错大部分都是环境问题不是框架本身有问题。最常见的是“多重背景Multi-instance”声明错误AF框架很多FB在设计时就采用了多实例背景数据块的模式你在项目里如果把它声明为“单实例”或者“参数实例”编译就会报错。解决方法是调用AF状态机FB时在FB的“多重背景”栏里勾选或者使用一个专门的调用组织块而不是在OB1里直接声明一个全局实例DB去调用。另一个高频雷区是TIA博途版本差异导致的SCL语法不兼容。比如老版本里SCL支持直接给BYTE数组元素赋值新版本会要求你使用POKE指令或者改用WORD位运算。AF框架库里大量使用位操作和数组从老版本迁移项目到新版本时这类报错几乎必然出现。我的经验是遇到这类报错不要手忙脚乱意思就是要你用更标准的系统函数替换掉原来的直接内存访问方式翻译一下官方提示按提示修改即可。再一个坑就是保持性设置。状态机和普通逻辑不一样它依赖当前状态ID来决策如果PLC断电重启后状态ID变成了随机值设备就会乱动作。所以全局DB里的状态ID、状态字必须勾选“保持”属性。很多工程师定义全局DB时默认不勾保持调试时一切正常但现场一断电再上电设备动作就错乱了。排查这类问题其实只要看程序块的属性面板把需要掉电保持的变量勾上保持选项就行。5.2 状态乱跳和输出抖动的排查套路状态机投入运行后最常被现场投诉的问题是“状态乱跳”或“输出抖动”。这两个问题的根源往往不是状态机逻辑本身而是迁移条件的信号质量。比如用接近开关的到位信号做迁移条件如果信号在临界点反复通断状态就会在“正在执行动作”和“动作完成”之间来回跳机械上表现为气缸抖动。解决办法是在迁移条件上加延时确认也就是信号持续稳定的时间超过某个阈值比如100毫秒才认可到位。输出抖动还有一个隐蔽原因在外设还没有真正到位时状态机就已经迁移到了下一拍。以液压系统为例油缸伸出到位信号可能取自压力继电器压力建立需要时间如果你的状态迁移条件只检测到压力开关上升沿就立刻跳状态下一拍的动作输出就会因为实际压力还没稳定而出现抖动。正确做法是在状态迁移条件里同时加入压力和延时双确认或者干脆在动作执行状态下增加一个最小保持时间。在线监控状态机时我推荐同时打开PLC的“调用结构”窗口和全局DB的监控表。调用结构窗口看的是FB是否被多个地方调用、调用顺序是否正确全局DB监控表看的是当前状态ID和状态字实时值。遇到状态乱跳时先看状态ID有没有瞬间跳好几位如果出现跳过多位的情况多半是有另一个FB也在改同一个状态ID用交叉引用功能查一下“g_设备状态.状态ID”很快就能定位到是哪个块在“捣乱”。这种多写冲突是AF框架应用中最容易混淆的地方因为它不属于编译错误只有在运行时才能发现。5.3 调试工具和现场排错技巧实录现场调试状态机博途自带的“带有控制功能的仿真表”是最好用的工具。把状态ID、急停、复位、自动请求这些关键变量拖进仿真表就能手动强制修改当前状态和触发条件模拟各种极端情况比如“设备正运行到第2步突然按急停程序会怎么走”。我在出厂前测试里一定会跑一遍所有状态的转换路径确保每个迁移条件都被实际执行过而不是只在理论上推演过。还有一个很笨但对排查特别有效的方法在每个状态分支里加上一个累加器记录该状态被进入的次数。比如状态20分支里写“#状态计数[20] : #状态计数[20] 1”调试结束后看一眼这些计数瞬间就知道每个状态被激活过几次。如果某个状态计数异常高说明反复在这个状态和下一个状态之间打转再结合定时器值就能判断是哪个条件在临界抖动。最后分享一个关于在线修改程序的体会状态机代码不像继电器逻辑那样改一笔就能生效。修改迁移条件或状态ID定义时必须考虑正在运行设备的现实状态比如修改“等待完成”分支的超时值可以让状态机重新编译下载但如果直接修改CASE分支结构比如从30迁到40的条件可能在下载瞬间让设备跳到一个不合理状态。所以我在现场在线修改状态机时永远先把状态机切到“手动调试”模式确认设备处于安全位置后再下载下载完成后一路用仿真表把状态恢复到原流程再切回自动模式。这套吃了几次亏总结出来的流程我在项目里执行了两年再没出过因为在线修改导致的状态错乱事故。