做运动控制的兄弟应该都遇到过这个场景：TIA Portal里面程序写了一半，下载到PLC，诊断缓冲区一打开，满屏的红色报错，什么“OB91未创建”“等时同步模式未激活”“同步循环中断超时”，看着就头疼。尤其是在调试多轴设备、伺服压机、飞剪或者任何对同步性要求比较高的设备时，这种报错一旦出现，整个项目都没法往下推。其实这个问题的根子，十有八九出在OB91组织块上——你没有在正确的位置、用正确的方式，把这个等时同步的中断组织块建出来。
这篇文章我就把等时模式报错这个问题彻底拆开，从OB91到底是什么、为什么非要它不可，到新建OB91的完整步骤、参数设置逻辑，再到现场常见的报错和排查思路，一次性讲清楚。内容不多废话，都是我自己在项目里反复试过、踩过坑之后沉淀下来的东西，适合正在调博途、做运动控制集成的工程师，也适合刚上手TIA Portal还没有系统理解中断组织块的初学者。
1. 等时同步模式报错到底在说什么
1.1 等时模式的核心价值：让运动控制“卡准拍子”
博途TIA Portal里的等时模式，英文叫Isochronous Mode，本质上解决的是“时间确定性”的问题。普通PLC循环扫描有抖动：程序执行到哪一行、通信什么时候刷新，都存在微秒甚至毫秒级的不确定性。这个不确定性和现场总线（比如PROFINET RT）的传输时间混在一起，就会让运动控制出现一个问题——驱动器执行指令的时刻和PLC计算指令的时刻，总是对不齐。
对单轴、低精度的应用来说，这点偏差忍忍也就过去了。但是到了多轴插补、电子齿轮、电子凸轮这种需要轴间严格同步的场景，差一个扫描周期，轴的相位可能就偏了，产品就跑废了。等时模式解决的正是这个问题：CPU和PROFINET总线在同一个“节拍”下工作，通信报文的发送、接收、处理都有固定的时间窗，误差被限制在微秒级。这个“节拍”，在TIA Portal里就对应着一个特殊的中断组织块——OB91。
1.2 等时模式报错和OB91组织块的关系
先说结论：OB91全称是“同步循环中断组织块”，在博途里属于组织块类型中的“等时同步循环中断”，代号91。它负责在每一个等时同步的周期内，自动启动一次中断程序，把运动控制指令放在这个中断里执行。换句话说，你的MC_MoveAbsolute、MC_MoveVelocity、MC_GearIn这些运动控制指令，正常情况下都不应该放在OB1主循环里乱跑，而是要放进OB91，让它卡着总线的“节拍”执行。
TIA Portal在新建PLC程序时，默认只生成OB1。如果你不手动添加OB91，很多运动控制指令就会失去等时同步的执行环境。此时CPU诊断缓冲区一般会给出错误信息，比如“MC_指令没有在等时同步中断OB中被调用”，或者“同步循环中断未设置”。很多工程师第一次遇到这个报错时都是一脸懵：硬件组态没错、轴配置没错、程序语法也没错，怎么就是跑不起来？问题恰恰出在你缺少了OB91这个“时间容器”。
1.3 常见的报错表现与触发场景速查
等时模式相关的报错，实际项目里我遇到过的表现大致有下面几类，你先对着看看是不是自己也踩过：
| 报错现象 | 可能原因 | 出错阶段 |
|---|---|---|
| 编译时报错：调用MC指令的组织块类型无效 | 把运动控制指令写在了OB1或普通OB100中 | 编译阶段 |
| 下载后诊断缓冲区提示：OB91不存在或未分配 | PLC程序中没有创建OB91组织块 | 运行阶段 |
| 等时同步中断超时/通信失败 | OB91执行时间超过了总线周期，或者看门狗参数太小 | 运行阶段 |
| PROFINET同步报文错误，站点闪红灯 | 等时模式相关设备参数没有统一配置 | 通信组态阶段 |
| 轴运动时周期性抖动或跟随误差报警 | OB91中的程序不稳定，中断周期和伺服驱动周期不匹配 | 调试阶段 |
有意思的是，上面最后一种情况往往不报OB91相关的故障代码，而是表现为跟随误差大、轴抖动这种“软故障”。很多工程师绕了一大圈，最后发现根源还是在OB91的周期设置和程序执行时间上。所以OB91不只是“建了就行”，还要建得对、用得对。
2. 为什么必须新建OB91：从中断机制看同步循环
2.1 OB91的中断优先级与调度逻辑
要理解OB91为什么“非建不可”，得先看懂TIA Portal组织块的调度机制。S7-1200/S7-1500的CPU在处理程序时，有主循环OB1，还有各种事件驱动的OB块，比如时间中断OB10、延时中断OB20、硬件中断OB40，以及咱们这里的主角——等时同步循环中断OB91。
CPU在每一个扫描周期里，OB1执行完之后，会去检查有没有待处理的中断事件。如果发现OB91对应的中断源触发了（也就是等时同步时钟的上升沿来了），CPU会暂停手头的OB1任务，跳转去执行OB91，OB91里跑完运动控制指令，再回到OB1继续执行。这就是中断调度的基本逻辑。
OB91在博途里的默认优先级是20级，高于OB1的优先级。这个优先级怎么理解？可以把它想成“生产线上的紧急工位”：OB1是正常的生产线，OB91是紧急工位，一旦等时同步的“哨声”响起，PLC必须放下手里的活，先去处理OB91里的内容。因为等时模式下，总线上每个时间窗都是固定的，错过一个时间窗，伺服走的位置就错了，所以OB91必须被CPU以最高确定性优先处理。
2.2 中断周期、相位偏移要与总线周期严格对齐
OB91有两个关键参数：中断周期和相位偏移。中断周期必须和PROFINET网络的等时同步周期一致，比如你组态里设的是4ms的IRT周期，那OB91的中断周期就必须是4ms。相位偏移（Phase Offset）一般设成0，除非你有多轴设备需要对不同的OB执行时机做错峰处理。
这两个参数的逻辑，其实有点像开会：所有参会者（CPU、IO设备、伺服驱动器）都按照同一个时钟（总线同步时钟）对表，但每个人发言的时间窗是错开的。CPU在周期开始阶段接收反馈报文，然后运行OB91做位置计算，再把设定值报文发出去。如果期间任何环节超时，下一个周期的数据就会来不及交换，系统就会报同步错误。
我碰到过一个非常典型的例子：某设备用的是S7-1500 + 6个S120伺服，总线周期按照伺服驱动的报文类型设置为4ms，但OB91的中断周期被默认设成了8ms。结果设备低速运行没大问题，一旦速度拉上来，轴就开始“咯噔咯噔”地响，还伴随跟随误差报警。原因很简单：OB91在每两个总线周期才执行一次，相当于驱动器每收两包报文才收到一次有效的设定值，中间那包就是旧值，控制系统自然就不稳定了。
2.3 没有OB91时，运动控制指令会遭遇什么
如果你就是不去建OB91，而是把MC指令放在OB1里调用，TIA Portal在V15以后的版本基本都会给出指令级报错，比如“The MC instruction is called in an invalid organization block”（运动控制指令在无效的组织块中被调用），编译直接过不了。V13、V14时代有些版本提示没那么明确，可能只是一个警告，但下载运行之后你会发现，轴还是能动，不过一旦涉及多轴同步，或者要求高动态响应，各种莫名其妙的问题就来了。
即便你把MC指令放在OB1里侥幸通过了编译，也别高兴太早。OB1的周期是“尽力而为”的——执行时间会根据程序逻辑变化，通信负载也会影响它的扫描时间。放在OB1里的运动控制指令，每一次执行的时间间隔是随机的，这等于让伺服按照一个“忽快忽慢的节拍器”来工作。工艺上要求严一点，废品率直接给你拉满。
所以OB91就是你给运动控制指令找的“固定节拍器”，也是CPU和总线之间的一座桥。没有这座桥，等时模式就是一句空话。
3. 手把手新建OB91组织块：从零到正常运行的完整流程
3.1 新建OB91之前的工程检查清单
动手新建OB91之前，先把工程里的基础工作检查一遍。OB91只有在硬件和组态都支持等时模式的条件下才有意义，否则你建了也是白建。
第一，CPU必须支持等时同步中断。S7-1500基本全程支持，S7-1200部分固件版本不支持，要确认你手里的1200型号和固件版本是否在支持清单里。第二，通信网络必须是PROFINET，而且最好使用IRT（同步实时）通信，普通RT通信的时间抖动太大，等时模式的效果会打折扣。第三，驱动系统和PLC的通讯周期必须规划好，比如S120伺服通过报文类型来设定通讯周期，这个周期值和OB91的中断周期要保持一致。
还有一点非常容易忽略：在组态驱动设备的工艺对象时，你需要在“轴”的组态界面里勾选“等时同步模式”或者“允许在等时同步中断中使用”，不同版本的中文翻译略有差异。这一步不勾选，即使你在OB91里调用了MC指令，系统照样会报错。我在项目里就见过好几个同事，OB91建好了程序也没问题，但就是轴不使能，查了半天发现是工艺对象里没勾选等时模式这个选项。
3.2 创建OB91并设置属性的详细步骤
下面以TIA Portal V16/V17为例，给出标准的操作步骤，其他版本基本大同小异。
第一步，打开项目，进入PLC变量与程序块管理界面。在左侧的项目树中找到“程序块”节点，右键选择“添加新块”。在弹出的对话框左侧选择“组织块”，然后在右侧的块类型下拉列表中找到“等时同步循环中断”或者“同步循环中断”，有的版本显示为“Isochronous mode interrupt”。给它命名，建议直接用默认的OB91，名字改成“OB_SyncCycle”之类的也可以，但编号必须是91。
第二步，设置中断属性。在OB91的属性窗口中，找到“中断”或者“循环中断”选项卡，把“循环时间/周期”（Cycle time）设置为和总线IRT周期相同的值，比如4ms。如果总线周期是2ms，这里就设2ms。再把“相位偏移”设成0。优先级保持默认的20，如果没有特殊的多OB协调需求，不建议去改它。
第三步，确认OB91的启动行为。在属性里把“启动信息”之类的选项按需设置，一般保持默认就可以。有些版本里可以设置是否在启动时调用，建议保持允许状态。
第四步，切换到OB91的编程界面，你会看到程序段1（Segment 1）是空的。这里就是运动控制指令的“主场”。
3.3 在OB91中正确调用MC指令与典型代码示例
进入OB91的编辑区后，把需要用到的运动控制指令拖进来。需要注意，并不是所有MC指令都必须在OB91里调用——像MC_Power这种使能大轴断电的指令，有些工程师放在OB100或OB1里也能工作；但凡是涉及运动控制计算的核心指令，尤其是速度/Torque控制、绝对/相对定位、齿轮同步、凸轮同步这类，最好都放进OB91。这样出来的轨迹曲线才平滑。
下面是一个典型的OB91程序片段，用STL/SCL的写法展示大致逻辑：
注意：以下代码用于展示指令调用的结构，实际项目中请根据你组态的轴名称和接口变量做替换。
// OB91 等时同步中断组织块 // 虚拟轴A：作为电子齿轮主动轴 // 虚拟轴B：作为电子齿轮从动轴 IF "MC_Power_Instance_B".Status = FALSE THEN // 先使能从动轴B "MC_Power_Instance_B"( Enable := TRUE, StopMode := 0, Status => "MC_Power_Status_B", Error => "MC_Power_Error_B" ); END_IF; // 主动轴A运行速度模式 "MC_MoveVelocity_Instance_A"( Execute := "AxisA_Start_CMD", Velocity := "AxisA_Speed_Setpoint", Acceleration := "AxisA_Acc", Deceleration := "AxisA_Dec", DirectionOfRotation := 1 ); // 从动轴B通过齿轮同步跟随主动轴A "MC_GearIn_Instance_B"( Execute := "GearIn_CMD", RatioNumerator := 2, RatioDenominator := 1, MasterAxis := "AxisA_Ref", SlaveAxis := "AxisB_Ref" );在实际项目中，我更推荐在OB91里只做三件事：读轴反馈、执行运动控制指令、写轴设定值。辅助逻辑（按钮处理、报警处理、模式切换）放到OB1或OB100里去做。这样OB91的执行时间最小，中断周期内能留下足够的余量，系统更稳定。
3.4 设置好PROFINET总线与等时同步参数
OB91建好了，运动控制指令也放进去了，接下来要回头检查总线设置。在设备组态里选中CPU的PROFINET接口，进入属性，找到“实时性/同步”相关的设置，确认IRT通信已经勾选，等时同步模式也是“启用”状态。
对于S120驱动，需要在驱动器设备属性里把“同步帧”和“通讯周期”配置好。通常驱动器的通讯周期在报文配置的时候会自动带入，你只需要确保它和OB91的中断周期一致。这里特别容易出现的一个坑是：驱动器的通讯周期设为4ms，但OB91的中断周期还是默认的20ms甚至更大，这种不一致在组态保存时不一定报错，但运行起来一定会出同步问题。
再强调一遍，所有参与等时同步的设备，它们的周期设置必须“口径统一”：CPU的IRT发送时钟、OB91的中断周期、驱动器的通讯周期，三者必须完全一致，否则系统的同步机制就无法建立。调这个参数时，可以借助TIA Portal的“拓扑视图”看看所有设备是否在同一网络下，避免因为网络拓扑分段导致同步信号无法到达。
3.5 编译下载与在线验证的关键步骤
完成以上设置后，先点击“编译”按钮，重点看编译输出窗口有没有OB91相关的错误或警告。常见的三种编译结果需要区分对待：
第一，编译完全通过，没有任何和OB91有关的提示。这种情况下可以下载程序。第二，编译提示MC指令调用无效，说明你的指令不在OB91里，或者OB91没有被正确创建识别。第三，编译提示周期不一致，说明OB91的中断属性和总线周期没对齐，回到属性里重新核对。
下载程序到CPU之后，不要急着跑轴。首先打开“在线与诊断”视图，查看诊断缓冲区。正常情况下，你会看到OB91以等时同步模式启动成功的提示。接着，把CPU切到RUN模式，观察OB91的运行状态——在“程序资源”里可以看到OB91的周期时间统计、最长执行时间、最小执行时间等数据。
我习惯在在线状态下重点看两个值：OB91的实际执行周期是否稳定，以及最长执行时间是否明显小于中断周期。比如周期是4ms，如果最长执行时间已经到了3ms以上，说明OB91程序太“重”了，要么裁剪逻辑，要么把中断周期调大（比如调到8ms）。这个余量经验值，我认为至少要有30%~50%，不然现场稍微有一点外部干扰，CPU就可能在某个周期里处理不过来，报同步超时。
这里提供一段通过TIA Portal在线查看OB91运行信息的简化说明：在项目树里找到OB91，右键“在线”并打开“属性”，可以看到“运行时间”和“周期时间”等实时统计。若不具备在线监控条件，也可以在OB91里把执行时间根据系统时钟存储到全局变量，便于后期排查。
4. 常见问题排查与避坑实录
4.1 等时模式常见报错速查表
在多个项目里摸爬滚打之后，我把遇到过的等时模式相关报错整理成了一张速查表，方便你到现场快速定位问题。
| 报错文本或现象 | 排查方向 | 解决办法 |
|---|---|---|
| OB91不存在 / 组织块无效 | 是否真的创建了OB91 | 在程序块中添加OB91，编号必须为91 |
| MC指令调用组织块无效 | MC指令在OB1/OB100中 | 将MC指令移动到OB91中 |
| 同步循环周期错误 | OB91周期与总线IRT周期不一致 | 核对所有周期参数，强制统一 |
| 等时同步模式未激活 | PROFINET接口未勾选IRT或等时模式 | 在接口属性中使能IRT与等时同步 |
| 同步报文看门狗超时 | OB91执行过长或驱动通讯异常 | 压缩OB91代码、调整周期、检查总线负载 |
| 运动控制轴抖动/跟随误差大 | OB91中逻辑过多，周期余量不足 | 精简OB91内容，优化执行时间 |
| 下载后CPU报警“通信失败” | PN网络拓扑、交换机不支持IRT | 使用支持IRT的交换机/直连拓扑 |
4.2 看门狗与通信超时问题为什么总在OB91之后才暴露
OB91牵扯出的问题里，最有迷惑性的就是“看门狗超时”。有些工程师把OB91创建好之后，程序能下载了，但运行没多久就报类似“同步报文看门狗超时”的错误，这时第一反应是查PROFINET通信线缆、查交换机，结果折腾半天一无所获。
实际项目中，这往往是因为OB91的执行时间超过了中断周期，导致等时同步中断还没跑完，下一个总线同步周期就已经来临。驱动侧的看门狗发现没有更新报文，就会认为通信断开。这时候真正要优化的是OB91里的程序——把那些耗时长的库函数挪出去，或者精简运动控制指令的执行频率。另一个技巧是在OB91里避免使用运行时间不确定的指令，比如某些字符串处理、动态数组访问，它们在极端情况下执行时间可能翻倍，直接影响中断周期稳定性。
4.3 多OB共存时的优先级冲突与资源竞争
S7-1500/1200里可以同时存在多个OB，除了OB91，可能还有时间中断OB10、硬件中断OB40、所有的OB50/OB60之类的。多个中断都会抢占CPU资源。如果某个低优先级中断把CPU占得太久，OB91的启动就可能受到影响。虽然OB91优先级默认20，已经很高了，但依然会被更高优先级的OB（比如OB83、OB84系统错误中断）抢占。
这就牵扯出一个设计原则：系统OB、错误OB和用户自定义中断OB不要“互相打架”。比如你把高速计数器的硬件中断OB40优先级调得比OB91还高，并且OB40里写的程序很重，那等时同步的节拍就乱了。调试时可以先试试把所有不必要的用户中断临时禁用，只保留OB91，看看是否恢复正常，再从增量上定位是谁在干扰。
4.4 等时模式调优与周期选择的个人经验
关于OB91的周期到底选多大，没有标准答案，看工艺需求。高速定位、多轴插补的设备，周期越短越好，但周期短了CPU压力大，留给OB91的执行时间也短。这里我给一个负责任的建议：如果设备最高转速和动态响应要求不是特别苛刻，4ms是一个折中方案；要求更高的可以用2ms甚至1ms，但此时CPU的选型、固件版本、总线拓扑都必须同步提升，否则容易出现周期丢失。
如果遇到CPU已经选了最顶配、但OB91执行时间还是压不到周期以内的情况，可以考虑“软同步”的替代思路——把轴控制放在支持独立同步周期的运动控制器或伺服驱动器里完成，PLC只是负责逻辑与参数下发。这种方案在我的某些高端装备项目里用过，效果很直接，只是要多学习一套驱动器的编程软件。
4.5 一个完整的诊断实例：抱闸电机试运行时的同步异常
最后分享一个比较典型的诊断过程，也许能帮你看清OB91在真实设备中的作用。有一台绕线设备，使用了4个S120驱动，设备上电后轴能回零，但运行程序后跟随误差越来越大，偶尔还报警“同步循环中断超时”。
我当时的排查顺序是：先看诊断缓冲区，发现OB91确实已经在运行了，没有报组织块缺失，但周期时间测出来忽高忽低，明显不稳定。于是我先禁用OB1里一个数据解析的功能块，周期时间立刻稳定下来。进一步定位后发现，该功能块里使用了大量的指针寻址与字符串拼接，执行时间波动非常大，为了等它，OB1的扫描周期被拉长，间接搅乱了OB91的中断节拍。
把数据解析功能块迁移到时间中断OB10里（设定成100ms执行一次），再把OB91周期改为4ms，轴运行立刻流畅，跟随误差下降了一个数量级。这个案例的价值在于提醒你：OB91本身的代码也许不复杂，但整个CPU的程序结构如果设计不当，任何部分都可能成为拖垮等时同步的元凶。
5. 关于OB91和等时模式，最后再掏几句心里话
OB91这个东西，说大不大，说小不小。用好了，它就是整个运动控制系统的“心脏起搏器”，让总线、CPU、驱动器在同一个节拍下协同工作；用不好，它就是报错集合体的中心，牵一发而动全身。很多刚接触博途的工程师总觉得报错就是某个参数没填对，其实真正的难点在于理解CPU的中断机制和总线同步的时序关系，只要把这些原理吃透了，OB91的创建和配置其实不难。
我个人在实际操作中最深的体会是：TIA Portal的报错有时候“太客气”了，很多等时模式问题不直接报OB91的错，而是以抖动、超时、跟随误差这种间接方式出现。所以调试时别只盯着诊断缓冲区和报错代码，要学会用OB91的在线运行数据当“体检报告”，周期稳不稳、执行时间有没有余量，一眼就看得出来。
如果你正在被等时模式报错折磨，不妨按本文的顺序走一遍：检查硬件支持、确认总线周期、新建OB91、填入MC指令、统一各设备的同步周期、下载到PLC后在线盯一下OB91的运行时间。这一套流程下来，绝大多数同步循环问题都能解决。
最后再分享一个小技巧：项目交付前，把OB91的最长执行时间和所属CPU型号、总线周期一起写进调试记录存档，以后设备现场出问题，这份记录就是你排查的第一把钥匙。设备换型、固件升级之后，也要回头复查一遍OB91的运行时间，别等到现场抖得没法生产了才想起来还有这么个组织块。
