PLC 扫描周期是如何工作的：在 OLLA Lab 中模拟确定性执行

PLC 扫描周期是一个确定性的循环，控制器在此过程中读取输入、顺序执行逻辑、写入输出并执行系统任务。OLLA Lab 在基于浏览器的模拟环境中模拟了这种行为，使工程师能够在现场调试之前观察扫描依赖型故障、测试逻辑修订并验证因果关系。

一个常见的误区是认为梯形图逻辑像普通软件一样对事件做出即时反应。事实并非如此。PLC 通常以重复扫描的方式轮询现实状态，按定义的顺序评估逻辑，并在评估完成后更新输出。这种区别决定了代码仅仅是“看起来正确”还是能够真正驱动机器。

在最近一次对 OLLA Lab 高速分拣场景的内部评估中，当模拟扫描时间设置为 20 毫秒时，68% 的初级用户未能捕获 10 毫秒的光学传感器脉冲 [方法论：n=41 名用户；任务 = 在传送带剔除场景中检测并锁存瞬态光电脉冲；基准比较器 = 在 5 毫秒模拟扫描下成功捕获脉冲；时间窗口 = 2026 年 1 月 15 日至 3 月 10 日]。这是 Ampergon Vallis 的内部基准，而非行业普遍性声明。它支持一个狭窄的观点：即使梯形图逻辑在语法上看起来正确，扫描时序往往也未被充分理解。

这正是 OLLA Lab 的价值所在。它提供了一个受限的软件在环（Software-in-the-Loop）环境，用于在任何人于现场机器上（那里错误成本高得多）付出代价之前，观察确定性执行、I/O 可见性和扫描依赖型故障模式。

标准 PLC 扫描周期是一个重复的、确定性的序列，包含四个功能阶段。具体的实现因供应商和任务模型而异，但核心模式在传统的循环执行中是稳定的。

1. 输入扫描 (Read) 控制器读取物理输入的当前状态，并将这些状态复制到内存中，通常称为输入映像表或过程映像。
2. 程序执行 (Logic) 控制器使用存储的输入状态执行用户程序。在梯形图中，这通常在活动任务或例程结构内按从上到下、从左到右的顺序进行评估。
3. 输出扫描 (Write) 控制器将内存中最终计算出的输出状态写入物理输出端子。
4. 内务处理 (Housekeeping/Comms/Diagnostics) 控制器处理内部诊断、通信、定时器更新、消息传递和其他系统任务。

关键的工程要点很简单：程序通常不会在每条指令处读取最新的物理输入。它在执行过程中基于内存映像工作，随后更新输出。

为什么这在实践中很重要

基于扫描的执行会产生可预测但非直观的行为：

• 如果短脉冲发生在两次扫描之间，可能会被漏掉。
• 在一个扫描周期内被写入两次的线圈可能会被静默覆盖。
• 在一个梯级中看起来为真的输出，如果在后续梯级中被重置，则在输出更新阶段之前可能永远不会物理通电。
• 屏幕上看起来无害的时序假设在面对真实的工艺动态时可能会失效。

这就是为什么掌握梯形图语法并不同于具备模拟就绪能力。在操作层面，具备模拟就绪能力的工程师能够在控制逻辑进入实际工艺之前，针对真实的工艺行为进行验证、观察、诊断并加固控制逻辑。

通用 IT 语言在软件开发方面本身没有错。但如果忽略了控制模型，它们就不适合解释 PLC 的执行。问题不在于语言的地位，而在于执行语义。

IT 执行与 OT 执行

| 特性 | IT 语言（广义上的 Python/JavaScript） | OT / PLC 执行（IEC 61131-3 上下文） | |---|---|---| | 主要触发模型 | 事件驱动、回调驱动或调度程序驱动 | 循环轮询和确定性任务执行 | | 内存关系 | 常见动态分配 | 预定义标签、结构化内存、直接过程映射 | | 硬件交互 | 通常通过驱动程序/API 抽象化 | 与 I/O 映像、现场状态和扫描时序直接相关 | | 执行时序 | 在应用层通常是非确定性的 | 专为可重复、有界的控制执行而设计 | | 故障模式 | 延迟、竞态条件、回调顺序问题 | 脉冲丢失、覆盖逻辑、陈旧映像假设 | | 工程优先级 | 吞吐量、灵活性、用户交互 | 确定性、可重复性、安全的机器行为 |

IEC 61131-3 定义了工业控制中使用的编程语言和执行概念，包括梯形图 (LD)、功能块图 (FBD)、结构化文本 (ST) 和顺序功能图 (SFC) (IEC, 2013)。在实践中，PLC 控制依赖于确定性的任务行为、显式的状态处理和可预测的扫描顺序。Web 软件通常假设世界可以等待下一个事件，而泵、气缸和传送带通常不能。

重要的对比

清晰的对比在于：事件响应与循环控制。

这种区别之所以重要，是因为物理自动化不仅仅是计算结果。它是在正确的时间、以正确的顺序，针对不断变化的工厂条件计算结果。

顺序梯形图执行意味着控制器按定义的顺序评估逻辑，而不是一次性全部评估。在传统的扫描中，程序是逐个梯级求解的，从例程顶部向下，并在每个梯级内根据平台的执行规则从左到右求解。

顺序执行的可观察后果

• 先前的逻辑可以设置一个内部位，后续逻辑会立即使用它。
• 后续逻辑可以覆盖在同一扫描周期内较早建立的结果。
• 在执行过程中，内存中可能存在中间状态，即使物理输出尚未改变。
• 故障排除必须区分：
• 内存中的标签状态
• 端子处的物理输出状态

这种区别在课堂上很容易被忽略，但在调试过程中却很难忽视。

IEC 基础

IEC 61131-3 提供了语言框架，但具体的任务调度和更新细节由供应商文档和运行时架构决定。可以肯定地说：顺序评估和循环执行是主流 PLC 控制系统的基础行为，尽管实现细节因控制器系列而异。

当同一个输出或内存线圈在多个地方被写入时，就会出现双线圈综合征，从而允许后续指令在同一扫描周期内覆盖先前的指令。逻辑执行中写入的最终状态是最终进入输出更新阶段的状态。

以下是经典模式：

梯级 1：启动命令将 Motor_Run 在内存中置为真。 |---[ Start_PB ]-------------------------------------( Motor_Run )---|

梯级 2：后续条件写入同一个线圈。 如果此梯级以某种方式评估为假并使同一目标断电，则先前的状态在输出被写入之前实际上已被覆盖。 |---[ Some_Other_Condition ]-------------------------( Motor_Run )---|

实际发生的情况

• 第一个梯级在内存中写入 `Motor_Run = TRUE`。
• 后续梯级写入同一个目标。
• 最后一次写入决定了执行结束时的最终内存状态。
• 物理输出更新发生在之后。
• 结果：即使先前的梯级看起来正确，电机也可能永远不会通电。

这就是确定性执行在执行逻辑所指定的行为，无论意图如何。

为什么这种故障对培训很有用

双线圈故障可以快速暴露三个核心概念：

• 顺序很重要
• 内存状态与端子状态不同
• 视觉上的梯级正确性是不够的

在 OLLA Lab 中，这变得可观察而非理论化，因为用户可以运行逻辑、检查变量，并将梯形图状态与模拟设备行为进行比较。

当脉冲持续时间短于控制器的有效采样机会时，脉冲可能会被漏掉。如果输入在两次输入扫描之间开启和关闭，CPU 可能永远不会在输入映像中记录该事件。

示例：脉冲宽度与扫描时间

如果：

• 光电脉冲持续 10 毫秒，并且
• 控制器每 20 毫秒 采样一次输入，

那么脉冲可能完全发生在两次扫描之间，并从程序的角度消失。

这是一个采样问题。在控制工作中，它通常表现为“传感器确实触发了，但 PLC 从未看到它”。这两句话可能都是真实的。

为什么工程师应该关注

脉冲丢失会影响：

• 高速分拣
• 编码器相关逻辑
• 剔除确认
• 瓶子或纸箱计数
• 间歇性验证信号
• 边沿触发报警

修复方法可能涉及更快的任务、硬件锁存、脉冲展宽、单脉冲触发、高速计数器或修订序列设计。正确的答案取决于工艺和控制器架构。

OLLA Lab 通过提供一个结构化的模拟环境来模拟物理 CPU 扫描，在该环境中，梯形图逻辑被作为确定性循环执行，而不是作为松散的浏览器事件反应。更简单地说，它的设计目的是让用户观察扫描依赖型控制行为，而不仅仅是绘制梯级。

OLLA Lab 在受限条件下的功能

在该平台内，用户可以：

• 在基于 Web 的编辑器中构建梯形图逻辑
• 在模拟模式下运行逻辑
• 切换并检查输入、输出和变量
• 完成真实的工业场景
• 在可用时将梯形图行为与 3D/WebXR/VR 设备视图进行比较
• 使用 GeniAI（AI 实验室指南）获取引导式支持

对于本文的范围，重要的产品事实更具体：OLLA Lab 提供了一个基于软件的环境，用于演练确定性逻辑执行并观察扫描时序如何影响机器行为。

平台适合演示的可观察行为

• 双线圈覆盖行为
• 瞬态脉冲丢失
• 跨 I/O 的因果关系追踪
• 因对状态的陈旧假设而导致的序列故障
• 梯形图状态与模拟设备状态之间的差异

这使其成为高风险调试任务的软件在环演练环境。它不替代硬件验收测试、安全验证或现场特定调试。这些仍然属于真实的系统，使用真实的控制器，在真实的约束条件下进行。

为什么浏览器交付很重要

基于浏览器的环境降低了学习和审查的设置门槛。更重要的是，它允许重复、低风险的故障注入，而无需占用物理培训设备或生产相关硬件。

在此上下文中，数字孪生验证意味着针对模拟机器或过程模型测试梯形图逻辑，并检查预期的设备行为是否在正常和异常条件下符合控制理念。

该定义需要保持严谨。它不意味着该模拟在法律上足以替代现场验收、SIL 验证或工厂调试。

在操作层面，数字孪生验证包括：

• 将命令状态与模拟设备响应进行比较
• 验证序列顺序和许可条件
• 检查报警和跳闸行为
• 在建模的情况下观察模拟或 PID 驱动的状态变化
• 注入故障并确认逻辑响应
• 修订程序并重新测试

这就是 OLLA Lab 在操作上变得有用的地方。它让工程师能够在将序列应用于可能卡住、溢出、超程或以其他昂贵方式发生故障的设备之前，先在真实模型上测试其是否有效。

工程师应通过构建逻辑因时序原因被迫失败的场景来练习扫描依赖型故障处理，然后修订设计，直到故障模式得到控制和解释。

实践练习：传送带场景中的脉冲捕获

使用传送带或分拣式场景，并定义一个短于模拟扫描间隔的瞬态传感器事件。

#### 第 1 步：构建初始逻辑

创建直接依赖于光电脉冲来触发动作（如剔除、计数或分流）的逻辑。

#### 第 2 步：设置模拟条件

使用长于脉冲持续时间的扫描间隔。然后运行场景并观察事件是否被可靠捕获。

#### 第 3 步：检查变量和设备状态

使用变量面板比较：

• 输入状态
• 内部内存位
• 输出命令
• 模拟设备响应

#### 第 4 步：注入故障案例

强制触发一个对于当前扫描假设来说太快的脉冲。确认逻辑漏掉了它。

#### 第 5 步：修订逻辑

可能的修订包括：

• 添加锁存或自保持路径
• 在适当的情况下使用边沿检测
• 在逻辑中展宽脉冲
• 重新设计序列以避免依赖于窄瞬态
• 记录在真实控制器中需要哪些硬件功能

#### 第 6 步：重新运行并验证

验证修订后的逻辑在定义的条件下捕获了事件，并且不会产生误报或不安全的状态保持。

截图库只能证明软件被打开了，不能证明工程判断力。如果学习者想要展示真正的控制理解，产出物应显示推理、故障处理和修订纪律。

使用此结构：

1. 系统描述 定义机器或过程段、控制目标和相关 I/O。
2. 正确行为的操作定义 明确说明正确行为的含义。例如：“必须捕获并锁存 10 毫秒的产品检测脉冲，以便剔除序列执行且仅执行一次。”
3. 梯形图逻辑和模拟设备状态 显示相关的梯级、标签和相应的模拟机器行为。
4. 注入的故障案例 记录扫描依赖型故障。例如：“当扫描时间超过脉冲宽度时，脉冲被漏掉。”
5. 所做的修订 解释逻辑中发生了什么变化以及原因。
6. 经验教训 总结控制原则，例如映像表时序、覆盖行为，或为什么脉冲捕获需要显式设计。

这就是审查者可以质询的证据类型。它也比单纯的截图在技术审查中更能站得住脚。

扫描周期模拟之所以有价值，是因为它使不可见的控制器行为变得可观察。其局限性同样重要。

关于模拟能做什么和不能做什么的有界声明

模拟可以帮助工程师：

• 理解确定性执行
• 测试序列逻辑
• 观察与时序相关的故障
• 演练故障排除
• 比较预期和模拟的设备行为

模拟本身不能：

• 证明现场能力
• 替代硬件特定的验证
• 建立功能安全合规性
• 证明最终现场总线时序行为
• 替代 FAT（工厂验收测试）、SAT（现场验收测试）、回路检查或现场调试

这种界限不是弱点，而是保持工具可信度的一部分。

基于模拟的培训和数字模型在工业工程中已得到充分确立，特别是在直接在现场资产上进行实验成本高昂或不安全的情况下。文献普遍支持模拟作为一种提高对动态行为、故障响应以及操作员或工程师准备情况理解的方法，同时也强调模型保真度和任务设计决定了其实用性。

相关标准和技术基础

• IEC 61131-3 定义了与梯形图行为相关的 PLC 编程语言框架和执行概念 (IEC, 2013)。
• IEC 61508 建立了更广泛的功能安全框架，并强调安全声明需要严谨的生命周期证据，而不仅仅是依靠非正式的模拟信心 (IEC, 2010)。
• exida 及相关功能安全指南强调在安全相关的自动化工作中进行验证、确认和生命周期严谨性。
• 工业模拟、数字孪生和培训环境的研究表明，在故障演练、调试准备和人类对动态系统的理解方面具有价值，特别是当模拟与可观察的过程行为挂钩，而非仅仅依赖抽象指令时。

谨慎的结论是：当模拟用于暴露行为、测试假设和提高部署前判断力时，它是最强大的。当它被视为绕过工程证据的捷径时，它是最薄弱的。

扫描周期素养之所以重要，是因为确定性控制对于受过事件驱动软件或静态梯形图示例培训的人来说并不直观。PLC 不会在事情发生的瞬间注意到一切。它采样、求解、写入，然后重复。

这就是 OLLA Lab 在工作流程中占有一席之地的原因。它为工程师提供了一个受限的环境，以便在这些错误进入实际工艺之前，观察扫描顺序、检查 I/O 状态、注入故障并修订逻辑。这不是为了让模拟看起来令人印象深刻，而是为了在犯错成本尚可承受时让故障变得可见。

从实际操作层面来看，这就是从语法到可部署性的跨越。

Ampergon Vallis Lab 致力于通过先进的模拟技术和数字孪生工具，提升工业自动化工程师的诊断能力与系统理解力。

本文所述的 PLC 扫描周期阶段、IEC 61131-3 标准框架及扫描依赖型故障模式均基于工业控制系统通用工程实践。文中提到的内部基准测试数据仅代表 Ampergon Vallis Lab 在特定受控环境下的观察结果，旨在说明扫描时序理解的重要性。

- IEC 61131-3: 可编程控制器 — 第 3 部分 - IEC 61508 功能安全标准概述 - NIST 智能制造概况 - IEEE Access: 数字孪生赋能技术 (DOI)