前面几篇，我们已经把结构化编程的基础框架搭起来了。
你已经开始逐渐从“画逻辑”过渡到“写逻辑”。但只会写 IF、CASE、FOR 还不够，因为 PLC 之所以是 PLC，关键就在于它总是在和“时间”“动作次数”“状态变化瞬间”打交道。

比如现场最常见的这些需求：

按下启动按钮后，延时 3 秒再启动电机
气缸伸出后，如果 2 秒内没有到位，就报警
某个传感器连续触发 5 次后，判定堵料
启动按钮只在“按下那一刻”触发一次，而不是一直触发
模式切换时，只在状态从 0 变成 1 的那一瞬间执行初始化
某个故障信号要持续 500ms 才认定为有效，防止抖动误报
某个脉冲信号来一次就加一，不允许长按时重复计数

这些逻辑，全都离不开：

定时器
计数器
边沿检测

所以这一篇你学到的，不只是几个指令怎么写，而是 PLC 里非常核心的一种控制思维：

不是只看“现在是什么状态”，还要看“它持续了多久”“它变化了几次”“它是不是刚刚发生变化”。

这就是 PLC 控制比普通条件判断更贴近现场的地方。

一、先建立一个总概念：定时器、计数器、边沿，本质上是在处理“时间、次数、变化瞬间”

这一点你先记住，后面就不会乱。

定时器处理的是时间维度

它关心的是：

某个条件持续了多久
什么时候该开始计时
什么时候计时完成
条件消失后计时是否清除
是否只输出一个固定宽度脉冲
计数器处理的是次数维度

它关心的是：

某件事发生了几次
到没到设定次数
是否该清零
是加计数还是减计数
边沿处理的是变化瞬间

它关心的是：

这个信号是不是刚从 0 变成 1
或者刚从 1 变成 0
不是看它现在一直为真，而是看“变化的那一瞬间”

你如果把这三个东西放在一起看，就会突然明白：

PLC 程序并不只是“当前状态判断”，它还必须处理“动态过程”。

这就是为什么这些内容如此重要。

二、为什么梯形图里你觉得定时器、计数器很自然，到了 SCL 里却容易有点别扭

这个感觉非常正常。

因为在梯形图里，定时器、计数器、上升沿、下降沿这些东西，往往以图形块的形式出现。
你看到它们时，会有一种很直观的感觉：

输入条件进来了
这个块开始工作
到时间了，输出成立
来一个脉冲，计数加一
信号刚跳变，边沿块给一次脉冲

也就是说，梯形图把这些对象呈现成了“功能器件”。

但在 SCL 里，你面对的更多是：

调用
参数
状态变量
当前值
上一次状态
触发条件
扫描周期中的执行关系

于是原本在梯形图里“看着就明白”的东西，到了 SCL 里开始需要你多想一步：

这个功能到底是怎样在程序里被调用、被保持、被判断的。

所以你会觉得 SCL 里这些内容稍微更“抽象”一点。
但一旦理解后，你反而会觉得它们更灵活、更清楚。

三、先说定时器：它到底在 PLC 里做什么

定时器最常见的用途，不是“让程序等一下”，而是：

让某个逻辑在满足条件一段时间后再成立，或者在条件消失后延迟消失，或者输出一个固定宽度的时间脉冲。

最常见的思路大概有三类：

1. 延时接通

输入条件成立后，不是立刻输出，而是等一段时间再输出。
这类逻辑很常见，比如：

电机启动前预吹扫 5 秒
故障持续 1 秒后才确认
传感器保持遮挡 300ms 后判定有料
2. 延时断开

输入条件消失后，不是立刻撤销输出，而是延迟一段时间再撤销。
例如：

风机停机后继续延时运转 10 秒散热
某个保持信号断开后，延时复位
3. 脉冲定时

某条件触发时，输出一个固定宽度的脉冲。
例如：

每次启动命令来时，给一个 200ms 的脉冲信号
某动作触发时，给蜂鸣器鸣叫 1 秒

这三类思路，在 PLC 里非常典型。

四、SCL 中定时器最重要的一个理解：它不是“写一行就过去了”，而是一个随扫描周期不断更新状态的对象

这是很多初学者最容易没真正理解的一点。

很多人刚学 SCL，会把定时器想成：

“我调用一次，它就自己计时。”

这个理解太粗了。

更准确地说，定时器在 PLC 中，通常需要在程序扫描过程中持续被执行和更新。
也就是说，它不是一个“按下按钮就单独跑出去的独立小人”，而是会随着每次扫描不断根据输入条件更新自己的状态。

这就是为什么你在 SCL 里用定时器时，不能只看“这一行代码长什么样”，还要理解：

输入条件什么时候给它
预置时间是多少
输出什么时候为真
当前已计时间是多少
输入断开后它如何恢复
这段逻辑是否每扫都在执行

所以，定时器在 SCL 里比在梯形图里更容易暴露出它“状态型”的本质。

五、最常见的延时接通定时器：TON

在很多 PLC 平台和工程习惯里，TON 都是最常见、最重要的一类定时器。
它的思路很简单：

输入条件成立后开始计时；
时间到了，输出才为真。

你可以这样理解：

不是“有条件就立刻动作”，而是“条件连续成立够久了，才承认它有效”。

这类逻辑在现场特别实用。
因为现场信号经常会抖、会闪、会短暂成立。
如果什么都立刻认定，误动作和误报警就会很多。

例如：

某个液位高位信号持续 500ms 才算高液位报警
某个堵料检测持续 2 秒才确认堵料
某个启动条件保持 1 秒后，才允许后续动作
六、TON 最重要的几个概念

虽然不同平台界面会略有差异，但从编程思路上，TON 一般你要关注这些内容：

1. 输入条件

也就是定时器什么时候开始计时。

2. 预置时间

也就是要持续多久才算“到时”。

3. 输出完成标志

到时间后，输出变为 TRUE。

4. 当前计时时间

也就是已经累计了多久。

这四个概念你理解了，TON 基本就不迷糊了。

七、一个最典型的 TON 场景：信号防抖动确认

现场传感器有时会瞬间抖动。
比如光电偶尔闪一下，液位开关偶尔跳一下，如果程序一有信号就立刻报警，现场会很烦。

这时候 TON 很合适。

思路上可以理解成：

如果故障信号持续 1 秒都还在，那才真正置故障。

示意逻辑可以理解为：

IF FaultSignal 持续成立达到 1 秒 THEN
    FaultAlarm := TRUE;
END_IF;

这就是延时确认。

你会发现，这类逻辑和“立刻判断”最大的区别就在于：
它引入了时间维度。

这也是定时器在 PLC 里的核心价值。

八、延时断开定时器：TOF 的核心意义是什么

如果说 TON 是“条件成立后延迟输出”，
那么 TOF 的思路就是：

条件消失后，延迟一段时间再撤销输出。

这类逻辑虽然没有 TON 那么常见，但在很多控制场景中也非常有用。

例如：

排风机在主设备停机后继续跑 10 秒
某个保持信号断开后，延迟释放
某个检测信号消失后，不马上认为物料离开，而是保留一小段时间

你可以把 TOF 理解成“慢一点再放掉”。

它适合那些不希望输出随着输入一断就立刻消失的场景。

九、脉冲定时器：TP 的核心意义

TP 的思路是：

某个触发来时，输出一个固定时间宽度的脉冲。

例如：

按一下按钮，蜂鸣器鸣叫 1 秒
启动命令来时，给下级设备一个 200ms 脉冲
某动作开始时，输出一个固定宽度触发信号

TP 特别适合做这种“触发一下，给固定时长输出”的逻辑。

它和 TON 的区别很明显：

TON 更像“条件保持够久才承认”
TP 更像“只要触发，就给你一个固定时间脉冲”
十、在 SCL 中使用定时器时，一个特别重要的思维变化：你开始更频繁地面对“定时器实例”和“输出状态”

这就是它和梯形图不完全一样的地方。

在梯形图里，你经常看到的是一个现成的定时器块，条件接进去就感觉很自然。
在 SCL 里，你通常会更清楚地意识到：

这个定时器本身需要一个实例或状态容器
你要给它输入条件
你要指定预置时间
你要取它的输出
有时候还要看它当前计时值

也就是说，SCL 让你更直接地面对“定时器不是魔法，而是一个有状态的功能对象”。

这其实是好事。
因为一旦你把这个底层理解透了，以后不管写定时器、计数器还是功能块，思路都会更成熟。

十一、定时器在 SCL 中最容易犯的几个错误
错误一：把定时器当成“阻塞等待”

很多人会潜意识觉得：

“我这里启动一个定时器，程序就先等 3 秒，再往下走。”

这不是 PLC 程序的正常扫描思维。
正确理解应该是：

程序每扫都继续执行，只是定时器的完成条件还没满足，所以某些后续逻辑暂时不成立。

这两种理解差别非常大。

PLC 不是写成“停在这里等时间过完”。
而是写成“只要没到时间，后续条件就还不成立”。

这点非常关键。

错误二：条件没理顺，导致定时器反复被清掉

比如某个 TON 的输入条件时有时无，结果它一直计不上去。
表面上看你明明写了 3 秒延时，但实际永远到不了完成。

这通常不是定时器坏了，而是你的触发条件本身没稳定。

所以一旦定时器表现不对，要先看：

它的输入条件到底有没有持续成立
是不是某个地方每扫都在把条件打断
是否存在条件互相覆盖
错误三：只看输出，不看当前计时过程

很多人调试时只盯着定时器输出是否为真。
但有时更有价值的是看：

定时器当前是否已经开始计时
已计时间有没有增长
是不是输入刚成立又断掉
是不是根本没触发进去

工程调试时，这一点很实用。

十二、再说计数器：它和定时器有什么不同

如果说定时器关心的是“持续了多久”，
那么计数器关心的就是：

发生了几次。

比如：

传感器触发了几次
产品通过了多少个
故障连续出现多少次
某个动作尝试了几次
某个脉冲来了多少个

所以计数器的核心不是时间，而是事件次数。

PLC 里很多控制逻辑其实都离不开计数。
只是有时候你在梯形图里用现成计数块用习惯了，到了 SCL 后容易忘记：
计数的本质并不是“有一个块”，而是“事件发生一次，数值变化一次”。

十三、计数器最关键的一点：不能用“电平”直接当“次数”

这句话非常重要。

很多初学者一上来会写出这种逻辑：

IF SensorOn THEN
    CountValue := CountValue + 1;
END_IF;

表面看没问题。
但实际上一旦 SensorOn 持续为 TRUE，这段代码会在每个扫描周期都加 1。

也就是说，你本来想要“来一次加一次”，结果变成了“只要一直有信号，就疯狂累加”。

这就是为什么计数器和边沿信号往往要配合使用。

正确的计数思路通常不是：

“信号现在为真就加一”

而是：

“信号刚刚从假变真那一瞬间，加一。”

这就是边沿检测的重要性。

十四、PLC 计数最常见的两个场景
1. 对脉冲或事件进行累计

例如：

光电传感器每检测到一个产品，计数加一
编码器脉冲累计
某个动作完成一次，工件数量加一
2. 达到次数后触发某个逻辑

例如：

连续 3 次抓取失败后报警
连续 5 次堵料后停机
产量达到 100 后切换箱号

也就是说，计数器不只是记录数量，还经常参与控制逻辑。

十五、SCL 中计数器的实用理解：有时是调用专用计数器，有时是自己用变量加逻辑实现

在工程实践里，计数未必只有一种写法。
有的平台支持现成计数器功能块；
有时工程师也会结合边沿检测，直接用一个数值变量自己做累计。

例如思路上：

检测到上升沿
就让 PartCount := PartCount + 1

只要逻辑清楚，这也是非常常见、非常实用的方式。

所以你不要把“计数器”理解得太死。
它的本质是：事件到来一次，数值按规则变化一次。

十六、边沿信号是什么，为什么它在 SCL 里比你想象得还重要

边沿处理，是很多 PLC 工程师从梯形图转到 SCL 时最容易忽视、也最容易突然顿悟的内容。

因为在梯形图里，你往往习惯了：

放一个上升沿触发块
放一个下降沿触发块
接上去就能用

但在 SCL 里，你会更直接地理解到边沿的本质：

边沿不是“某个信号为真”，而是“某个信号刚发生变化”。

这句话非常关键。

上升沿

表示信号刚从 FALSE 变成 TRUE 的那一瞬间。

下降沿

表示信号刚从 TRUE 变成 FALSE 的那一瞬间。

所以边沿信号不是持续状态，而是一个“变化事件”。

你可以把它理解成：

普通信号是在说“现在亮不亮”
边沿信号是在说“刚刚点亮那一下”或者“刚刚熄灭那一下”

这就是为什么它特别适合：

按钮触发一次性动作
计数
模式切换初始化
状态变化时记录事件
防止长按重复触发
十七、为什么边沿检测在 PLC 里如此重要

因为 PLC 是循环扫描的。

假设某个按钮被按下保持 1 秒，而 PLC 每 10ms 扫描一次。
那这一秒里，程序可能会看到这个按钮为 TRUE 大约 100 次。

如果你写的是：

IF StartPB THEN
    StartCount := StartCount + 1;
END_IF;

那一秒里它可能就加了很多次，而不是你想要的一次。

可如果你检测的是“上升沿”，那么只有按钮从未按下变成按下的那一瞬间，才会触发一次。

这就是边沿的价值。

所以你以后只要遇到下面这些需求，就要立刻想到边沿：

只触发一次
只计一次
只在变化那一刻做动作
不允许长按连续执行
十八、边沿检测最本质的思路：拿“当前状态”和“上一周期状态”做比较

这点非常值得你真正吃透。

边沿不是神秘魔法，它最本质的实现思路其实就是：

上升沿

当前为 TRUE，上一周期为 FALSE。

下降沿

当前为 FALSE，上一周期为 TRUE。

例如，上升沿的思路本质上就是：

当前为真 并且 上一次为假

下降沿则是：

当前为假 并且 上一次为真

所以边沿处理为什么离不开“状态保持”你现在就明白了。
因为你必须记住上一次是什么，才能知道这一次是不是刚刚发生变化。

这也说明了一个很重要的事：

边沿检测从根上就不是单纯的组合逻辑，它带有时序和记忆性质。

十九、一个最典型的上升沿应用：按钮只触发一次启动动作

假设你希望：

按下启动按钮那一瞬间，系统进入启动流程。
但按钮如果一直按着，不要每个扫描周期都重新触发启动。

这时候上升沿就特别合适。

逻辑本质上是：

只有按钮刚刚从 0 变 1 时，才给一次启动脉冲。

这类思路非常适合：

启动命令置位
复位命令触发
参数确认
菜单切换
事件记录
二十、一个最典型的边沿应用：计数

前面已经提过，计数不能直接看电平，而要看事件。

例如产品经过一个光电时，你想每过一个加一。
那通常就应该是在光电上升沿时加一，或者根据现场结构在下降沿时加一。

比如：

物体进入检测区，用上升沿计数
物体离开检测区，用下降沿计数

这取决于你实际想统计的是“进入瞬间”还是“离开瞬间”。

这在包装线、输送线、分拣线里非常常见。

二十一、边沿检测在 SCL 里和梯形图最大的思维差异

这点必须明确说出来。

在梯形图里，你往往把边沿块当成一个现成元件。
你把信号接进去，它吐出一个脉冲，事情就结束了。

但在 SCL 里，你会更容易意识到：

为什么会有这个脉冲
它其实是当前值和上次值比较出来的
为什么必须保存上一次状态
为什么某些变量不能是临时的
为什么边沿结果往往只持续一个扫描周期

这其实是个很大的进步。

因为一旦你真正理解边沿是怎么来的，后面你在写：

状态机
一次性触发逻辑
计数
翻转控制
初始化逻辑

都会更稳。

二十二、定时器、计数器、边沿这三者之间，经常是配合出现的

这点特别重要，不要把它们当成三个完全独立的知识点。

在实际项目里，它们常常是连在一起用的。

例如：

场景一：按钮上升沿触发一个脉冲定时器

按下按钮那一下，只触发一次 500ms 输出。

这里就有：

上升沿
定时器
场景二：某故障信号持续 1 秒才确认，并且确认 3 次后报警停机

这里就可能有：

TON 做延时确认
计数器记录故障发生次数
某些地方可能还会配合边沿防止重复计数
场景三：每次产品通过光电上升沿计一次，累计到 20 个后启动打包动作

这里就有：

边沿检测
计数
条件判断
可能还有动作延时

所以实际工程里，这三者往往不是分开孤立使用，而是共同组成时序控制逻辑。

二十三、SCL 中处理这些功能时，一个特别重要的习惯：先分清“状态”和“事件”

很多程序之所以写乱，是因为把状态和事件混在一起了。

状态

是可以持续存在的东西。
例如：

AutoMode
Fault
MotorRun
CylinderOutFB
事件

是变化瞬间。
例如：

StartPB 的上升沿
Fault 从无到有
模式切换刚刚发生
计数脉冲来了一次

定时器常常服务于状态持续时间。
计数器常常记录事件次数。
边沿则专门用来提取事件。

你把这层关系理顺，程序思路会清楚很多。

二十四、初学者在这部分最容易踩的几个坑
坑一：把定时器当阻塞等待

前面已经讲过，这是最典型的大坑。
PLC 程序不是“停在这里等”。

坑二：按钮长按导致重复触发

本来想启动一次，结果一直触发。
根源通常是忘了用边沿。

坑三：计数按电平累加，导致一秒钟加几十次

这也是非常典型的错误。
计数应该围绕事件，而不是简单围绕持续为真的状态。

坑四：边沿所依赖的“上一状态”没保存好

如果上一状态变量没用对、没更新好，边沿结果就会乱。

坑五：定时器输入条件不稳定，结果一直不到时

这在故障确认、防抖动逻辑里特别常见。

坑六：把所有时间逻辑都想写成循环等待

这不仅不推荐，而且容易把扫描周期搞坏。

二十五、从工程角度讲，什么时候你应该本能地想到这三类工具

下面这些场景，你以后最好一遇到就能联想到对应思路。

遇到“持续多久才成立”

优先想到定时器。

遇到“发生几次后再动作”

优先想到计数器。

遇到“只在变化那一瞬间触发一次”

优先想到边沿检测。

这三个判断习惯，会让你在现场写逻辑时快很多。

二十六、这一篇最后，给你一个非常实用的理解框架

以后你看到一个控制需求时，可以先用下面这个方式拆解：

第一步：这是状态问题，还是事件问题

如果是“现在有没有成立”，那更偏状态。
如果是“刚刚变化那一下”，那更偏事件。

第二步：这个需求关心的是时间、次数，还是变化瞬间
时间：定时器
次数：计数器
瞬间：边沿
第三步：它需不需要和条件判断配合

绝大多数都需要。
因为这些工具本身不是全部逻辑，只是逻辑的一部分。

第四步：它会不会因为扫描周期被重复执行

如果会，就要特别考虑边沿、防抖、锁存、状态保持。

只要你养成这个拆解习惯，后面遇到现场需求时，不会一上来就乱写。

小结

这一篇你最应该记住这些核心点：

定时器处理的是时间维度，计数器处理的是次数维度，边沿信号处理的是变化瞬间。
梯形图里这些功能常常表现为直观的功能块，而在 SCL 里你会更直接地面对它们的状态和调用本质。
TON 适合延时接通，TOF 适合延时断开，TP 适合输出固定宽度脉冲。
定时器不是阻塞等待工具，而是在扫描周期中不断更新状态的时序逻辑。
计数不能简单按电平累加，很多情况下应结合边沿检测，否则一个持续信号会在多个扫描周期里重复计数。
边沿检测的本质是比较当前状态与上一周期状态，因此它天然依赖状态保持。
在实际工程中，定时器、计数器和边沿往往配合使用，而不是孤立存在。
写这类逻辑时，一定要先分清状态和事件，否则程序很容易重复触发或判断失真。