1. 从一次产线急停改造说起为什么外部中断值得单独拎出来讲去年帮一家做包装机械的客户改一条老产线设备上有个高速计数工位物料到位信号由一只光电开关给出脉冲宽度实测只有不到2毫秒。原来的程序用普通数字量输入加循环扫描去抓这个信号结果在博途里监控时好时坏偶尔漏抓一次后面的封切动作就整个错位废品率一直压不下去。后来把这只信号切到S7-1200的硬件中断输入上用OB40去接问题当场消失。这件事让我意识到很多做PLC编程的朋友对外部中断这个概念其实是模糊的——知道有这么个东西但真到用的时候要么不敢用要么用了不知道怎么和主程序解耦。这篇内容就围绕S7-1200的外部中断展开重点讲两件事一是外部中断硬件中断到底怎么创建从硬件组态到OB40的编写二是DETACH指令怎么把中断和某个事件源分离以及分离之后怎么再挂回去。关键词里出现的OB40、DETACH正是这条链路上最核心的两个点。适合已经会写基本梯形图、但对中断机制还停留在听说过阶段的工程师也适合那些被高速信号、精确定时、事件触发类需求折磨过的朋友。我会把组态步骤、指令用法、实测中的坑都摊开讲尽量让你看完就能在自己的项目里复现。先说一个结论性的判断外部中断不是高级功能而是处理时间敏感事件的必需品。只要你的信号宽度接近或小于PLC的扫描周期或者你要求某个动作必须在事件发生的瞬间被记录、被响应那普通轮询就不可靠必须上中断。S7-1200的扫描周期在默认设置下通常是几毫秒到十几毫秒具体取决于程序量和通信负载这个数字后面还会反复用到。2. S7-1200外部中断的底层逻辑它到底在什么时候被触发2.1 扫描周期与中断的抢占关系要理解外部中断先得理解S7-1200的循环扫描机制。CPU在RUN模式下反复执行一个循环读输入映像区、执行OB1、写输出映像区、处理通信和系统任务然后进入下一个循环。这个过程是周期性的OB1里写的逻辑本质上是在定期巡检。问题就出在定期两个字上。假设你的扫描周期是8毫秒而某个输入信号只持续了2毫秒那么在这8毫秒的窗口里CPU很可能在信号出现之前刚读完输入等下一次读输入时信号已经消失了。这就是漏抓的根源和程序写得对不对没关系是机制决定的。外部中断硬件中断的作用就是打破这个周期性。当组态为中断输入的通道检测到指定边沿时CPU会暂停当前正在执行的OB1转去执行OB40执行完再回到被打断的地方继续。这个抢占是硬件层面触发的响应时间远小于一个扫描周期通常在微秒到几十微秒级别。所以它能抓住那些轮询抓不住的窄脉冲。注意中断不是并行执行而是插队执行。OB40执行期间OB1是停住的。所以OB40里绝对不能写耗时逻辑否则会拖垮整个扫描周期。2.2 哪些通道能用作中断输入不是所有数字量输入都能触发硬件中断。在S7-1200上能否用作中断输入取决于CPU型号和信号板/信号模块的能力。以常见的CPU 1214C DC/DC/DC为例其集成的数字量输入中部分通道支持硬件中断功能具体哪些通道支持要在博途的硬件组态里看通道属性。判断方法很直接在设备视图里点开CPU或信号模块选中某个输入通道看属性面板里有没有硬件中断这一栏。有就能用没有就只能当普通输入。这个细节很多人第一次做会忽略以为随便找个输入点组态一下就行结果发现属性里根本没有中断选项白白折腾半天。另外要注意高速计数功能HSC和硬件中断是两套机制。HSC用于计数和测频硬件中断用于事件响应。有些场景两者会配合使用比如HSC计到某个值时触发中断但那是HSC自己的比较中断和数字量输入的外部中断不是一回事别混为一谈。2.3 上升沿、下降沿与两者都触发组态中断输入时需要指定触发边沿上升沿、下降沿或者上升沿和下降沿都触发。这个选择直接决定了OB40被调用的时机。上升沿触发信号从0变1的瞬间触发。适合按钮按下物料到位这类事件。下降沿触发信号从1变0的瞬间触发。适合按钮松开物料离开这类事件。两者都触发任何跳变都触发。适合需要记录信号完整波形的场景但要小心抖动导致的频繁触发。实测经验如果信号源是机械触点比如行程开关强烈建议只选一个边沿并且在硬件上做消抖或者用输入滤波。因为机械触点在闭合瞬间会产生多次抖动如果选了两者都触发一次动作可能触发好几次OB40程序逻辑就会乱。光电、接近开关这类固态传感器抖动小得多但也不是完全没有。3. 手把手创建外部中断从硬件组态到OB40落地3.1 硬件组态里的关键设置项打开博途进入设备与网络视图双击CPU进入设备视图。选中你要用作中断的那个输入通道在下方属性面板里找到硬件中断分组。这里有几个设置项需要逐个确认第一是启用硬件中断勾选它。第二是触发边沿按上一节的分析选上升沿或下降沿。第三是输入滤波这个参数很关键它决定了信号需要稳定多长时间才被认可。滤波时间设得太短抖动会进来设得太长窄脉冲会被滤掉。默认值通常是6.4毫秒左右对于2毫秒的窄脉冲必须把它调小比如0.2毫秒或0.4毫秒具体看信号质量。这里有个容易踩的坑滤波时间和中断响应是矛盾的。滤波是为了抗干扰但滤波本身会引入延迟。如果你既要抓窄脉冲又要抗干扰就得在传感器选型和布线上下功夫而不是一味调滤波参数。我一般建议先用示波器看一下实际信号的波形和抖动情况再决定滤波值别凭感觉填。组态完成后编译硬件配置。如果这个通道之前被别的功能占用了比如已经被组态成HSC输入博途会报错需要先释放。3.2 OB40的添加与优先级设置硬件中断组态好之后需要添加一个OB40来承载中断逻辑。在项目树里右键程序块选择添加新块类型选硬件中断系统会自动命名为OB40如果已有OB40会提示你选择或新建其他编号的中断OB。添加时有一个优先级参数。S7-1200的中断优先级范围通常是1到26具体范围看CPU型号数值越大优先级越高。如果项目里只有一个中断源优先级随便设一个中间值就行。但如果有多个中断源就要考虑谁先响应。比如安全相关的急停信号优先级应该高于普通的物料检测信号。提示优先级还影响中断能否被另一个中断打断。高优先级中断可以打断低优先级中断的执行这叫中断嵌套。嵌套用好了能保证关键事件的实时性用不好会导致逻辑复杂、难以调试。新手项目里建议先不要用嵌套把所有中断优先级设成一样让它们排队执行。OB40添加后里面默认是空的。你可以在里面写中断触发时要执行的逻辑。但这里要强调一个设计原则OB40里只做记录和置位不做决策和耗时操作。比如中断来了把某个标志位置1、把当前计数值存下来、给一个变量打时间戳这些都可以。但不要在OB40里做PID运算、不要做通信、不要做循环等待这些应该交给OB1去处理。3.3 一个完整的最小示例假设需求是光电开关检测到物料到位上升沿记录到位次数并置位一个物料已到位标志主程序检测到标志后执行后续动作。硬件组态把光电开关接到CPU的某个支持中断的输入通道比如I0.0启用硬件中断触发边沿选上升沿滤波时间设为0.4毫秒。OB40里的逻辑用梯形图或SCL都行这里用SCL示意// OB40 硬件中断 到位次数 : 到位次数 1; 物料已到位 : TRUE;OB1里的逻辑// OB1 主循环 IF 物料已到位 THEN 物料已到位 : FALSE; // 执行封切、计数确认等后续动作 封切启动 : TRUE; END_IF;这个结构就是典型的中断记录、主程序处理。中断只负责快速响应和打标记真正的业务逻辑在主循环里跑两边通过标志位解耦。这样即使后续动作耗时较长也不会阻塞中断响应。实测下来这套结构在物料检测频率每秒几十次的情况下非常稳。但如果频率再高比如每秒几百次就要考虑中断本身的执行开销了因为每次中断都有进出栈的成本太频繁会明显拉高CPU负载。4. DETACH指令把中断源摘下来再挂回去4.1 DETACH到底解决什么问题前面讲的是中断一直挂在那里来一个信号触发一次。但实际项目里经常有这样的需求某个阶段我不希望这个中断触发或者我要动态切换中断的处理逻辑。这时候就要用到DETACH。DETACH指令的作用是把一个事件源比如某个硬件中断输入从它的OB上分离。分离之后即使这个输入通道检测到触发边沿也不会再调用OB40了。对应的ATTACH指令可以把事件源重新挂到一个OB上。举个实际场景一台设备有手动和自动两种模式。手动模式下操作员点动按钮不希望触发自动流程的中断逻辑自动模式下才需要物料检测中断。这时候就可以在模式切换时用DETACH把中断输入摘下来切回自动时再用ATTACH挂回去。另一个场景是中断源的动态重映射。比如同一个输入点在不同工位要触发不同的处理逻辑。可以先DETACH改一下组态或逻辑再ATTACH到另一个OB。不过S7-1200上OB的绑定关系在运行时改起来有限制更常见的做法还是用标志位在OB40内部做分支DETACH/ATTACH更多用于启用/禁用这个层面。4.2 DETACH和ATTACH的指令格式与参数在博途里DETACH和ATTACH属于扩展指令里的中断类别。指令的参数主要有两个EVENT事件源和OB要绑定或解绑的组织块。EVENT参数需要填一个事件标识符。对于硬件中断输入这个标识符不是随便写的它和硬件组态里的通道是对应的。获取方式有两种一是在硬件组态里查看该通道的事件ID二是在程序里用系统常量。博途通常会提供类似Hardware interrupt 0这样的系统常量直接拖进来用就行。ATTACH的用法ATTACH(OB : OB40, EVENT : Hardware interrupt 0);DETACH的用法DETACH(OB : OB40, EVENT : Hardware interrupt 0);注意DETACH的OB参数它表示从哪个OB上分离。如果这个事件源当前没有绑定到任何OBDETACH会报错。所以稳妥的做法是在DETACH之前先确认当前状态或者用错误处理包一下。4.3 分离之后中断去哪了这是很多人困惑的点DETACH之后输入信号还在通道还在检测边沿但因为没有绑定OB触发事件就被丢弃了。它不会排队等着也不会缓存就是直接忽略。所以DETACH期间发生的触发事后是补不回来的。这个特性决定了DETACH的使用要谨慎。如果你的业务逻辑不能容忍漏掉一次触发那就不能用DETACH来禁用中断而应该在OB40内部用标志位判断让中断照常触发但逻辑上跳过。反过来如果这个阶段本来就不该有触发比如设备停机、工位空置那DETACH就是干净利落的做法还能省掉中断调用的开销。注意DETACH/ATTACH是运行时指令可以在OB1里根据条件调用。但不要在OB40里调用DETACH去分离自己这属于自己把自己摘下来行为不确定容易出问题。要分离就在主程序里做。5. 中断与主程序的协作设计标志位、数据一致性与常见陷阱5.1 标志位交互的正确姿势中断和主程序之间共享数据最常用的就是标志位和全局变量。但这里有个隐患OB40可能在OB1读写某个变量的中途插进来导致数据不一致。举个典型例子OB1正在执行一个多步操作读了一个变量A准备基于A去改B。就在读完A、还没改B的时候OB40触发了OB40也改了A或B。等OB1回来继续执行它手里的A已经是旧值逻辑就可能出错。解决办法有几个层次。最简单的是把交互变量限制为单个位或单个字并且保证读写是原子的。S7-1200对单个位、单字16位、双字32位的读写通常是原子的不会被打断到一半。所以标志位用BOOL计数值用DINT一般没问题。但如果是一个结构体、一个数组OB1正在遍历它OB40改了其中一项就可能出问题。更稳妥的做法是用中断禁用指令。在OB1读写共享数据的临界区前后调用DIS_AIRT禁用中断和EN_AIRT启用中断把这段代码保护起来。不过这会增加中断延迟临界区不能太长。DIS_AIRT(); // 禁用中断 // 读写共享数据的临界区 共享结构.成员1 : ...; 共享结构.成员2 : ...; EN_AIRT(); // 启用中断实测经验大多数中小型项目里只要共享数据控制在几个基本类型变量不用临界区保护也很少出问题。但一旦涉及数组、结构体的批量操作或者中断频率很高就一定要加保护。我见过一个项目OB40在改一个配方数组OB1在遍历这个数组做计算偶发数据错乱查了很久才定位到是中断打断导致的加上DIS_AIRT就好了。5.2 中断频率与CPU负载的平衡每次中断触发CPU都要保存现场、跳转、执行OB40、恢复现场。这个开销虽然不大但积少成多。如果中断频率太高CPU会大量时间花在进出中断上OB1的执行被严重挤压表现为扫描周期变长、通信变慢、HMI响应迟钝。怎么判断频率是否过高可以在OB40里对一个计数器累加每秒在OB1里读一次这个计数器的增量就知道中断频率了。S7-1200的CPU一般能承受每秒几千次的中断但具体要看OB40里的逻辑量。如果OB40里只有几条赋值几千次没问题如果里面有几十条指令可能几百次就开始吃力了。优化思路能合并的中断就合并。比如多个输入点触发同一类逻辑可以考虑用硬件上的一根汇总信号触发一个中断然后在OB40里读所有相关输入的状态而不是每个点都配一个中断。这样中断次数少了单次处理的内容多了总体开销反而下降。5.3 几个我踩过的坑第一个坑是滤波时间设错导致中断不触发。有次调试信号明明有OB40就是不进。查了半天发现滤波时间设成了默认的6.4毫秒而信号只有1毫秒宽直接被滤没了。把滤波调到0.2毫秒立刻正常。这个坑的教训是调试中断时先用示波器或高速采集确认信号实际宽度再对照滤波参数。第二个坑是DETACH之后忘了ATTACH。有个项目在手动模式下DETACH了中断切回自动时逻辑分支写漏了没ATTACH回去结果自动模式下物料检测完全失效排查时还以为是传感器坏了。后来养成了习惯DETACH和ATTACH成对写在一个状态机里切模式时统一处理避免遗漏。第三个坑是在OB40里调用需要时间的指令。有次在OB40里写了一个字符串拼接用于记录日志字符串操作比较耗时结果中断频繁触发时扫描周期暴涨通信都断了。后来把日志记录改成只存原始数据到缓冲区OB1里再格式化问题解决。OB40里真的只能放最轻量的操作。6. 典型应用场景拆解从高速计数到安全响应6.1 高速物料检测与分拣这是外部中断最经典的应用。传送带上的物料经过检测工位光电开关给出窄脉冲中断触发后记录物料到达时刻和序号主程序根据这些信息控制分拣机构动作。这个场景的关键参数是物料间隔时间和信号宽度。如果物料间隔是50毫秒信号宽度是2毫秒那么中断频率是每秒20次完全在S7-1200的能力范围内。但如果传送带速度很快间隔缩短到5毫秒中断频率就是每秒200次这时候就要评估OB40的执行时间了。设计要点中断里只记录时间戳和序号分拣决策放在OB1里做。因为分拣涉及气缸动作、位置计算这些逻辑耗时且需要和其他工位协调不适合放在中断里。6.2 设备安全门与急停信号安全相关的信号也常用中断处理。比如安全门被打开需要立即停止某些输出。用中断的好处是响应快不受扫描周期影响。但要注意安全功能不能只依赖标准PLC的中断。真正的安全回路应该由安全继电器或安全PLC实现标准PLC的中断只能作为辅助的快速响应。这个边界要清楚不能拿普通中断去替代安全功能那是拿人身安全开玩笑。在标准PLC层面中断可以做的记录安全门打开的精确时刻、触发报警、置位停机标志。这些是记录和通知不是安全保护本身。6.3 与HSC配合的位置捕获S7-1200的HSC高速计数器有一个位置捕获功能可以在外部信号触发时把当前计数值锁存下来。这个功能底层也是靠硬件中断实现的但用起来比手动写OB40更方便。如果你的需求是在某个信号到来的瞬间记录编码器位置优先考虑HSC的位置捕获而不是自己用OB40去读计数值。因为HSC的捕获是硬件完成的精度更高也不占用中断资源。只有HSC满足不了的需求比如需要在捕获时同时执行复杂逻辑才考虑自己写中断。6.4 多中断源的优先级管理一个稍微复杂的设备可能同时有多个中断源物料检测、安全门、限位开关、故障信号等。这时候优先级设置就重要了。我的建议是分三档安全类最高故障类次之普通工艺类最低。安全类中断要能打断其他中断保证第一时间响应。故障类要能打断工艺类保证异常被及时记录。工艺类之间可以同级排队执行。但优先级嵌套会增加调试难度。如果项目不大中断源不多也可以全部设成同级靠OB40内部的逻辑判断来处理先后。这样简单不容易出乱子。7. 调试与验证怎么确认中断真的按预期工作7.1 用计数器验证触发次数最直接的验证方法在OB40里对一个DINT变量累加然后在HMI或监控表里看这个值。给一个已知数量的触发信号比如手动按10次按钮看计数器是不是正好加10。如果多了可能是抖动导致重复触发如果少了可能是滤波太狠或边沿选错。这个方法简单但有效我每次调试中断都会先做这一步确认触发链路是通的再去调业务逻辑。7.2 用时间戳测量响应延迟如果需要知道中断响应的实际延迟可以在OB40里读取系统时间和触发信号的实际时刻对比。S7-1200可以用RD_SYS_T或RD_LOC_T读取时间精度到毫秒级。对于更精确的测量就要用示波器同时抓触发信号和PLC的某个输出翻转直接看时间差。实测数据在CPU 1214C上从输入信号跳变到OB40第一条指令执行延迟通常在几十微秒到一百多微秒之间具体取决于CPU负载和中断优先级。这个延迟对于绝大多数工业场景是足够的。7.3 在线监控OB40的注意事项博途的在线监控对OB40也适用但有个现象要注意OB40执行很快监控刷新可能看不到。因为OB40可能只执行几微秒而监控刷新是几百毫秒一次你看到的往往是OB40执行完之后的变量状态而不是执行中的状态。如果想看OB40内部的执行过程可以在关键位置加一个计数器或标志位让每次执行都留下痕迹然后看这些痕迹的变化。或者用触发记录功能在特定条件下抓取变量快照。7.4 常见故障对照表现象可能原因排查方向OB40完全不触发硬件中断未启用、边沿选错、滤波时间过长检查通道属性、用示波器看信号触发次数偏多信号抖动、选了双边沿、滤波太短加滤波、改单边沿、硬件消抖触发次数偏少滤波太长、信号宽度不足、中断被DETACH调滤波、确认信号、检查ATTACH状态扫描周期变长OB40逻辑太重、中断频率过高精简OB40、降低中断频率数据偶发错乱中断打断OB1的共享数据读写加DIS_AIRT/EN_AIRT保护DETACH报错事件源未绑定、OB参数不对确认当前绑定状态、检查事件ID这张表是我这些年调试中断时总结的高频问题基本上覆盖了八成以上的现场故障。遇到问题先对号入座能省不少时间。8. 一些不那么标准但很实用的经验关于中断输入通道的选择我有个偏好尽量用CPU集成的输入通道少用信号模块的通道。原因是集成通道的中断响应通常更快而且不占用模块间的背板通信。当然这是在通道数量够用的前提下如果集成通道不够该用模块还是得用。关于OB40的编号S7-1200允许有多个硬件中断OB编号从OB40开始往上。如果项目里有多个中断源需要不同的处理逻辑可以建多个OB每个绑不同的事件源。但OB数量多了管理起来麻烦我的做法是尽量用一个OB40内部用事件源的标识或标志位来分支。这样代码集中调试方便。关于DETACH的使用时机我一般只在设备模式切换和工位启用/停用这两个场景用。其他情况比如暂时不想处理某个中断我更倾向于在OB40里用标志位跳过而不是DETACH。因为DETACH是硬禁用漏掉的触发补不回来标志位是软跳过中断照常触发只是逻辑不执行行为更可预测。还有一个细节ATTACH的时候如果事件源已经绑定在某个OB上会怎样实测是博途会报错或覆盖具体行为取决于固件版本。稳妥做法是ATTACH之前先DETACH确保干净状态。虽然多一步但避免了不确定性。最后说一个关于移植性的问题。S7-1200的中断机制和S7-1500基本一致DETACH/ATTACH的用法也相同所以在这两个平台之间移植代码中断部分通常不用大改。但和S7-200 SMART就差得比较远了200 SMART的中断是另一套体系没有DETACH这种动态绑定指令。如果你是从200 SMART转过来的这部分要重新学不能套用旧经验。我在实际项目里用外部中断最多的场景还是高速信号捕获和模式相关的逻辑切换。前者靠OB40的快速响应后者靠DETACH/ATTACH的动态管理。把这两块吃透S7-1200的中断功能基本就够用了。真正要小心的不是指令本身而是中断和主程序之间的数据交互——那才是最容易出问题、也最考验设计功力的地方。
1. 从一次产线急停改造说起为什么外部中断值得单独拎出来讲去年帮一家做包装机械的客户改一条老产线设备上有个高速计数工位物料到位信号由一只光电开关给出脉冲宽度实测只有不到2毫秒。原来的程序用普通数字量输入加循环扫描去抓这个信号结果在博途里监控时好时坏偶尔漏抓一次后面的封切动作就整个错位废品率一直压不下去。后来把这只信号切到S7-1200的硬件中断输入上用OB40去接问题当场消失。这件事让我意识到很多做PLC编程的朋友对外部中断这个概念其实是模糊的——知道有这么个东西但真到用的时候要么不敢用要么用了不知道怎么和主程序解耦。这篇内容就围绕S7-1200的外部中断展开重点讲两件事一是外部中断硬件中断到底怎么创建从硬件组态到OB40的编写二是DETACH指令怎么把中断和某个事件源分离以及分离之后怎么再挂回去。关键词里出现的OB40、DETACH正是这条链路上最核心的两个点。适合已经会写基本梯形图、但对中断机制还停留在听说过阶段的工程师也适合那些被高速信号、精确定时、事件触发类需求折磨过的朋友。我会把组态步骤、指令用法、实测中的坑都摊开讲尽量让你看完就能在自己的项目里复现。先说一个结论性的判断外部中断不是高级功能而是处理时间敏感事件的必需品。只要你的信号宽度接近或小于PLC的扫描周期或者你要求某个动作必须在事件发生的瞬间被记录、被响应那普通轮询就不可靠必须上中断。S7-1200的扫描周期在默认设置下通常是几毫秒到十几毫秒具体取决于程序量和通信负载这个数字后面还会反复用到。2. S7-1200外部中断的底层逻辑它到底在什么时候被触发2.1 扫描周期与中断的抢占关系要理解外部中断先得理解S7-1200的循环扫描机制。CPU在RUN模式下反复执行一个循环读输入映像区、执行OB1、写输出映像区、处理通信和系统任务然后进入下一个循环。这个过程是周期性的OB1里写的逻辑本质上是在定期巡检。问题就出在定期两个字上。假设你的扫描周期是8毫秒而某个输入信号只持续了2毫秒那么在这8毫秒的窗口里CPU很可能在信号出现之前刚读完输入等下一次读输入时信号已经消失了。这就是漏抓的根源和程序写得对不对没关系是机制决定的。外部中断硬件中断的作用就是打破这个周期性。当组态为中断输入的通道检测到指定边沿时CPU会暂停当前正在执行的OB1转去执行OB40执行完再回到被打断的地方继续。这个抢占是硬件层面触发的响应时间远小于一个扫描周期通常在微秒到几十微秒级别。所以它能抓住那些轮询抓不住的窄脉冲。注意中断不是并行执行而是插队执行。OB40执行期间OB1是停住的。所以OB40里绝对不能写耗时逻辑否则会拖垮整个扫描周期。2.2 哪些通道能用作中断输入不是所有数字量输入都能触发硬件中断。在S7-1200上能否用作中断输入取决于CPU型号和信号板/信号模块的能力。以常见的CPU 1214C DC/DC/DC为例其集成的数字量输入中部分通道支持硬件中断功能具体哪些通道支持要在博途的硬件组态里看通道属性。判断方法很直接在设备视图里点开CPU或信号模块选中某个输入通道看属性面板里有没有硬件中断这一栏。有就能用没有就只能当普通输入。这个细节很多人第一次做会忽略以为随便找个输入点组态一下就行结果发现属性里根本没有中断选项白白折腾半天。另外要注意高速计数功能HSC和硬件中断是两套机制。HSC用于计数和测频硬件中断用于事件响应。有些场景两者会配合使用比如HSC计到某个值时触发中断但那是HSC自己的比较中断和数字量输入的外部中断不是一回事别混为一谈。2.3 上升沿、下降沿与两者都触发组态中断输入时需要指定触发边沿上升沿、下降沿或者上升沿和下降沿都触发。这个选择直接决定了OB40被调用的时机。上升沿触发信号从0变1的瞬间触发。适合按钮按下物料到位这类事件。下降沿触发信号从1变0的瞬间触发。适合按钮松开物料离开这类事件。两者都触发任何跳变都触发。适合需要记录信号完整波形的场景但要小心抖动导致的频繁触发。实测经验如果信号源是机械触点比如行程开关强烈建议只选一个边沿并且在硬件上做消抖或者用输入滤波。因为机械触点在闭合瞬间会产生多次抖动如果选了两者都触发一次动作可能触发好几次OB40程序逻辑就会乱。光电、接近开关这类固态传感器抖动小得多但也不是完全没有。3. 手把手创建外部中断从硬件组态到OB40落地3.1 硬件组态里的关键设置项打开博途进入设备与网络视图双击CPU进入设备视图。选中你要用作中断的那个输入通道在下方属性面板里找到硬件中断分组。这里有几个设置项需要逐个确认第一是启用硬件中断勾选它。第二是触发边沿按上一节的分析选上升沿或下降沿。第三是输入滤波这个参数很关键它决定了信号需要稳定多长时间才被认可。滤波时间设得太短抖动会进来设得太长窄脉冲会被滤掉。默认值通常是6.4毫秒左右对于2毫秒的窄脉冲必须把它调小比如0.2毫秒或0.4毫秒具体看信号质量。这里有个容易踩的坑滤波时间和中断响应是矛盾的。滤波是为了抗干扰但滤波本身会引入延迟。如果你既要抓窄脉冲又要抗干扰就得在传感器选型和布线上下功夫而不是一味调滤波参数。我一般建议先用示波器看一下实际信号的波形和抖动情况再决定滤波值别凭感觉填。组态完成后编译硬件配置。如果这个通道之前被别的功能占用了比如已经被组态成HSC输入博途会报错需要先释放。3.2 OB40的添加与优先级设置硬件中断组态好之后需要添加一个OB40来承载中断逻辑。在项目树里右键程序块选择添加新块类型选硬件中断系统会自动命名为OB40如果已有OB40会提示你选择或新建其他编号的中断OB。添加时有一个优先级参数。S7-1200的中断优先级范围通常是1到26具体范围看CPU型号数值越大优先级越高。如果项目里只有一个中断源优先级随便设一个中间值就行。但如果有多个中断源就要考虑谁先响应。比如安全相关的急停信号优先级应该高于普通的物料检测信号。提示优先级还影响中断能否被另一个中断打断。高优先级中断可以打断低优先级中断的执行这叫中断嵌套。嵌套用好了能保证关键事件的实时性用不好会导致逻辑复杂、难以调试。新手项目里建议先不要用嵌套把所有中断优先级设成一样让它们排队执行。OB40添加后里面默认是空的。你可以在里面写中断触发时要执行的逻辑。但这里要强调一个设计原则OB40里只做记录和置位不做决策和耗时操作。比如中断来了把某个标志位置1、把当前计数值存下来、给一个变量打时间戳这些都可以。但不要在OB40里做PID运算、不要做通信、不要做循环等待这些应该交给OB1去处理。3.3 一个完整的最小示例假设需求是光电开关检测到物料到位上升沿记录到位次数并置位一个物料已到位标志主程序检测到标志后执行后续动作。硬件组态把光电开关接到CPU的某个支持中断的输入通道比如I0.0启用硬件中断触发边沿选上升沿滤波时间设为0.4毫秒。OB40里的逻辑用梯形图或SCL都行这里用SCL示意// OB40 硬件中断 到位次数 : 到位次数 1; 物料已到位 : TRUE;OB1里的逻辑// OB1 主循环 IF 物料已到位 THEN 物料已到位 : FALSE; // 执行封切、计数确认等后续动作 封切启动 : TRUE; END_IF;这个结构就是典型的中断记录、主程序处理。中断只负责快速响应和打标记真正的业务逻辑在主循环里跑两边通过标志位解耦。这样即使后续动作耗时较长也不会阻塞中断响应。实测下来这套结构在物料检测频率每秒几十次的情况下非常稳。但如果频率再高比如每秒几百次就要考虑中断本身的执行开销了因为每次中断都有进出栈的成本太频繁会明显拉高CPU负载。4. DETACH指令把中断源摘下来再挂回去4.1 DETACH到底解决什么问题前面讲的是中断一直挂在那里来一个信号触发一次。但实际项目里经常有这样的需求某个阶段我不希望这个中断触发或者我要动态切换中断的处理逻辑。这时候就要用到DETACH。DETACH指令的作用是把一个事件源比如某个硬件中断输入从它的OB上分离。分离之后即使这个输入通道检测到触发边沿也不会再调用OB40了。对应的ATTACH指令可以把事件源重新挂到一个OB上。举个实际场景一台设备有手动和自动两种模式。手动模式下操作员点动按钮不希望触发自动流程的中断逻辑自动模式下才需要物料检测中断。这时候就可以在模式切换时用DETACH把中断输入摘下来切回自动时再用ATTACH挂回去。另一个场景是中断源的动态重映射。比如同一个输入点在不同工位要触发不同的处理逻辑。可以先DETACH改一下组态或逻辑再ATTACH到另一个OB。不过S7-1200上OB的绑定关系在运行时改起来有限制更常见的做法还是用标志位在OB40内部做分支DETACH/ATTACH更多用于启用/禁用这个层面。4.2 DETACH和ATTACH的指令格式与参数在博途里DETACH和ATTACH属于扩展指令里的中断类别。指令的参数主要有两个EVENT事件源和OB要绑定或解绑的组织块。EVENT参数需要填一个事件标识符。对于硬件中断输入这个标识符不是随便写的它和硬件组态里的通道是对应的。获取方式有两种一是在硬件组态里查看该通道的事件ID二是在程序里用系统常量。博途通常会提供类似Hardware interrupt 0这样的系统常量直接拖进来用就行。ATTACH的用法ATTACH(OB : OB40, EVENT : Hardware interrupt 0);DETACH的用法DETACH(OB : OB40, EVENT : Hardware interrupt 0);注意DETACH的OB参数它表示从哪个OB上分离。如果这个事件源当前没有绑定到任何OBDETACH会报错。所以稳妥的做法是在DETACH之前先确认当前状态或者用错误处理包一下。4.3 分离之后中断去哪了这是很多人困惑的点DETACH之后输入信号还在通道还在检测边沿但因为没有绑定OB触发事件就被丢弃了。它不会排队等着也不会缓存就是直接忽略。所以DETACH期间发生的触发事后是补不回来的。这个特性决定了DETACH的使用要谨慎。如果你的业务逻辑不能容忍漏掉一次触发那就不能用DETACH来禁用中断而应该在OB40内部用标志位判断让中断照常触发但逻辑上跳过。反过来如果这个阶段本来就不该有触发比如设备停机、工位空置那DETACH就是干净利落的做法还能省掉中断调用的开销。注意DETACH/ATTACH是运行时指令可以在OB1里根据条件调用。但不要在OB40里调用DETACH去分离自己这属于自己把自己摘下来行为不确定容易出问题。要分离就在主程序里做。5. 中断与主程序的协作设计标志位、数据一致性与常见陷阱5.1 标志位交互的正确姿势中断和主程序之间共享数据最常用的就是标志位和全局变量。但这里有个隐患OB40可能在OB1读写某个变量的中途插进来导致数据不一致。举个典型例子OB1正在执行一个多步操作读了一个变量A准备基于A去改B。就在读完A、还没改B的时候OB40触发了OB40也改了A或B。等OB1回来继续执行它手里的A已经是旧值逻辑就可能出错。解决办法有几个层次。最简单的是把交互变量限制为单个位或单个字并且保证读写是原子的。S7-1200对单个位、单字16位、双字32位的读写通常是原子的不会被打断到一半。所以标志位用BOOL计数值用DINT一般没问题。但如果是一个结构体、一个数组OB1正在遍历它OB40改了其中一项就可能出问题。更稳妥的做法是用中断禁用指令。在OB1读写共享数据的临界区前后调用DIS_AIRT禁用中断和EN_AIRT启用中断把这段代码保护起来。不过这会增加中断延迟临界区不能太长。DIS_AIRT(); // 禁用中断 // 读写共享数据的临界区 共享结构.成员1 : ...; 共享结构.成员2 : ...; EN_AIRT(); // 启用中断实测经验大多数中小型项目里只要共享数据控制在几个基本类型变量不用临界区保护也很少出问题。但一旦涉及数组、结构体的批量操作或者中断频率很高就一定要加保护。我见过一个项目OB40在改一个配方数组OB1在遍历这个数组做计算偶发数据错乱查了很久才定位到是中断打断导致的加上DIS_AIRT就好了。5.2 中断频率与CPU负载的平衡每次中断触发CPU都要保存现场、跳转、执行OB40、恢复现场。这个开销虽然不大但积少成多。如果中断频率太高CPU会大量时间花在进出中断上OB1的执行被严重挤压表现为扫描周期变长、通信变慢、HMI响应迟钝。怎么判断频率是否过高可以在OB40里对一个计数器累加每秒在OB1里读一次这个计数器的增量就知道中断频率了。S7-1200的CPU一般能承受每秒几千次的中断但具体要看OB40里的逻辑量。如果OB40里只有几条赋值几千次没问题如果里面有几十条指令可能几百次就开始吃力了。优化思路能合并的中断就合并。比如多个输入点触发同一类逻辑可以考虑用硬件上的一根汇总信号触发一个中断然后在OB40里读所有相关输入的状态而不是每个点都配一个中断。这样中断次数少了单次处理的内容多了总体开销反而下降。5.3 几个我踩过的坑第一个坑是滤波时间设错导致中断不触发。有次调试信号明明有OB40就是不进。查了半天发现滤波时间设成了默认的6.4毫秒而信号只有1毫秒宽直接被滤没了。把滤波调到0.2毫秒立刻正常。这个坑的教训是调试中断时先用示波器或高速采集确认信号实际宽度再对照滤波参数。第二个坑是DETACH之后忘了ATTACH。有个项目在手动模式下DETACH了中断切回自动时逻辑分支写漏了没ATTACH回去结果自动模式下物料检测完全失效排查时还以为是传感器坏了。后来养成了习惯DETACH和ATTACH成对写在一个状态机里切模式时统一处理避免遗漏。第三个坑是在OB40里调用需要时间的指令。有次在OB40里写了一个字符串拼接用于记录日志字符串操作比较耗时结果中断频繁触发时扫描周期暴涨通信都断了。后来把日志记录改成只存原始数据到缓冲区OB1里再格式化问题解决。OB40里真的只能放最轻量的操作。6. 典型应用场景拆解从高速计数到安全响应6.1 高速物料检测与分拣这是外部中断最经典的应用。传送带上的物料经过检测工位光电开关给出窄脉冲中断触发后记录物料到达时刻和序号主程序根据这些信息控制分拣机构动作。这个场景的关键参数是物料间隔时间和信号宽度。如果物料间隔是50毫秒信号宽度是2毫秒那么中断频率是每秒20次完全在S7-1200的能力范围内。但如果传送带速度很快间隔缩短到5毫秒中断频率就是每秒200次这时候就要评估OB40的执行时间了。设计要点中断里只记录时间戳和序号分拣决策放在OB1里做。因为分拣涉及气缸动作、位置计算这些逻辑耗时且需要和其他工位协调不适合放在中断里。6.2 设备安全门与急停信号安全相关的信号也常用中断处理。比如安全门被打开需要立即停止某些输出。用中断的好处是响应快不受扫描周期影响。但要注意安全功能不能只依赖标准PLC的中断。真正的安全回路应该由安全继电器或安全PLC实现标准PLC的中断只能作为辅助的快速响应。这个边界要清楚不能拿普通中断去替代安全功能那是拿人身安全开玩笑。在标准PLC层面中断可以做的记录安全门打开的精确时刻、触发报警、置位停机标志。这些是记录和通知不是安全保护本身。6.3 与HSC配合的位置捕获S7-1200的HSC高速计数器有一个位置捕获功能可以在外部信号触发时把当前计数值锁存下来。这个功能底层也是靠硬件中断实现的但用起来比手动写OB40更方便。如果你的需求是在某个信号到来的瞬间记录编码器位置优先考虑HSC的位置捕获而不是自己用OB40去读计数值。因为HSC的捕获是硬件完成的精度更高也不占用中断资源。只有HSC满足不了的需求比如需要在捕获时同时执行复杂逻辑才考虑自己写中断。6.4 多中断源的优先级管理一个稍微复杂的设备可能同时有多个中断源物料检测、安全门、限位开关、故障信号等。这时候优先级设置就重要了。我的建议是分三档安全类最高故障类次之普通工艺类最低。安全类中断要能打断其他中断保证第一时间响应。故障类要能打断工艺类保证异常被及时记录。工艺类之间可以同级排队执行。但优先级嵌套会增加调试难度。如果项目不大中断源不多也可以全部设成同级靠OB40内部的逻辑判断来处理先后。这样简单不容易出乱子。7. 调试与验证怎么确认中断真的按预期工作7.1 用计数器验证触发次数最直接的验证方法在OB40里对一个DINT变量累加然后在HMI或监控表里看这个值。给一个已知数量的触发信号比如手动按10次按钮看计数器是不是正好加10。如果多了可能是抖动导致重复触发如果少了可能是滤波太狠或边沿选错。这个方法简单但有效我每次调试中断都会先做这一步确认触发链路是通的再去调业务逻辑。7.2 用时间戳测量响应延迟如果需要知道中断响应的实际延迟可以在OB40里读取系统时间和触发信号的实际时刻对比。S7-1200可以用RD_SYS_T或RD_LOC_T读取时间精度到毫秒级。对于更精确的测量就要用示波器同时抓触发信号和PLC的某个输出翻转直接看时间差。实测数据在CPU 1214C上从输入信号跳变到OB40第一条指令执行延迟通常在几十微秒到一百多微秒之间具体取决于CPU负载和中断优先级。这个延迟对于绝大多数工业场景是足够的。7.3 在线监控OB40的注意事项博途的在线监控对OB40也适用但有个现象要注意OB40执行很快监控刷新可能看不到。因为OB40可能只执行几微秒而监控刷新是几百毫秒一次你看到的往往是OB40执行完之后的变量状态而不是执行中的状态。如果想看OB40内部的执行过程可以在关键位置加一个计数器或标志位让每次执行都留下痕迹然后看这些痕迹的变化。或者用触发记录功能在特定条件下抓取变量快照。7.4 常见故障对照表现象可能原因排查方向OB40完全不触发硬件中断未启用、边沿选错、滤波时间过长检查通道属性、用示波器看信号触发次数偏多信号抖动、选了双边沿、滤波太短加滤波、改单边沿、硬件消抖触发次数偏少滤波太长、信号宽度不足、中断被DETACH调滤波、确认信号、检查ATTACH状态扫描周期变长OB40逻辑太重、中断频率过高精简OB40、降低中断频率数据偶发错乱中断打断OB1的共享数据读写加DIS_AIRT/EN_AIRT保护DETACH报错事件源未绑定、OB参数不对确认当前绑定状态、检查事件ID这张表是我这些年调试中断时总结的高频问题基本上覆盖了八成以上的现场故障。遇到问题先对号入座能省不少时间。8. 一些不那么标准但很实用的经验关于中断输入通道的选择我有个偏好尽量用CPU集成的输入通道少用信号模块的通道。原因是集成通道的中断响应通常更快而且不占用模块间的背板通信。当然这是在通道数量够用的前提下如果集成通道不够该用模块还是得用。关于OB40的编号S7-1200允许有多个硬件中断OB编号从OB40开始往上。如果项目里有多个中断源需要不同的处理逻辑可以建多个OB每个绑不同的事件源。但OB数量多了管理起来麻烦我的做法是尽量用一个OB40内部用事件源的标识或标志位来分支。这样代码集中调试方便。关于DETACH的使用时机我一般只在设备模式切换和工位启用/停用这两个场景用。其他情况比如暂时不想处理某个中断我更倾向于在OB40里用标志位跳过而不是DETACH。因为DETACH是硬禁用漏掉的触发补不回来标志位是软跳过中断照常触发只是逻辑不执行行为更可预测。还有一个细节ATTACH的时候如果事件源已经绑定在某个OB上会怎样实测是博途会报错或覆盖具体行为取决于固件版本。稳妥做法是ATTACH之前先DETACH确保干净状态。虽然多一步但避免了不确定性。最后说一个关于移植性的问题。S7-1200的中断机制和S7-1500基本一致DETACH/ATTACH的用法也相同所以在这两个平台之间移植代码中断部分通常不用大改。但和S7-200 SMART就差得比较远了200 SMART的中断是另一套体系没有DETACH这种动态绑定指令。如果你是从200 SMART转过来的这部分要重新学不能套用旧经验。我在实际项目里用外部中断最多的场景还是高速信号捕获和模式相关的逻辑切换。前者靠OB40的快速响应后者靠DETACH/ATTACH的动态管理。把这两块吃透S7-1200的中断功能基本就够用了。真正要小心的不是指令本身而是中断和主程序之间的数据交互——那才是最容易出问题、也最考验设计功力的地方。
