干这行时间长了，总会碰到一些“看着简单，想深了全是坑”的问题。上周帮一个客户排查产量统计误差，现场程序里同时出现了以5秒为周期的定时累加和上升沿触发计数这两种写法，报表数据每个小时都差那么一两分钟。群里也有同行问“跨小时统计，T#5S和R_TRIG到底哪种稳”，这问题看似基础，实际牵扯到扫描周期、边沿丢失、整点对齐和掉电保持好几个层面。今天就把这两种方案掰开揉碎讲清楚，顺便聊聊现场最稳的做法到底是什么。
先说清楚，这篇文章不是教新手认识指令，更偏重于给已经写过统计程序的工程师做一次系统性复盘。你会看到定时器时基的精度到底够不够、R_TRIG在什么场景下会被误用、跨小时整点结算怎么对齐，以及我在现场踩过的坑和最终采用的程序结构。内容主要基于欧系PLC的编程习惯，但思路同样适用于其他平台。
1. 先把问题拆开：跨小时统计、T#5S与R_TRIG的真实分工
1.1 跨小时统计到底在统计什么
很多自动化项目里都有这类需求：统计某个设备每个小时运行了多久、产线每小时通过了多少工件、水泵每小时累计运行了多少分钟，或者更复杂一点，按小时段结算峰谷电量或原料消耗。这种统计的特点有两个，一是时间跨度固定为自然小时，二是需要把过程量“累计”并按时段切片。
跨小时统计的核心矛盾在于“自然小时边界”不是PLC的扫描周期能自然感知的。你不可能靠数扫描次数来定位“8点整”这个时刻，因为扫描周期本身是不稳定的。这也是为什么很多人写的统计程序一到整点就偏差，或者说每个小时报表的数值总和与总表对不上。真正要解决的是两件事：用什么作为周期累加的时基，以及如何感知小时边界并完成结算。
1.2 T#5S定时方案：原理与实现方式
T#5S在欧系PLC里是TIME类型常量，表示5秒。放到统计程序里，通常的做法是用一个定时器生成5秒周期的脉冲，每来一个脉冲，累计变量加一个固定步长。比如统计运行时间，每5秒加5秒；如果统计产量，每5秒根据瞬时流量或速度估算一个增量。
这个方案的本质是“周期采样累加”，时基来自PLC内部定时器。内部定时器有两个层次，一种是普通定时器指令，基于扫描周期计数，另一种是循环中断OB，由系统以固定时间间隔触发。前者受扫描周期波动影响，后者精度更高，但仍存在微小的系统抖动。T#5S这类方案不是不行，而是必须知道它的精度边界在哪里，以及怎么补偿误差。
1.3 R_TRIG上升沿触发：原理与适用边界
R_TRIG是上升沿检测指令，核心功能是捕捉输入信号从0变1的那个瞬间，并在之后的一个扫描周期内输出TRUE。很多人误以为R_TRIG能当定时器用，其实它的定位完全不同。R_TRIG只负责“事件检测”，不负责“时间计量”。
它最适合的场景是：外部信号变化频率较低，需要捕捉某个动作发生的时刻。典型例子包括光电开关检测到工件、按钮被按下、接触器反馈触点闭合。在这些场景下，R_TRIG配合计数器或时间戳记录非常自然。但如果把它拿来生成周期脉冲，或者让它在“跨小时累计”这类需要连续时基的任务里当主力，就很容易出问题，原因后面详述。
2. 稳定性硬碰硬：定时器时基与事件触发的对比
2.1 纯计时场景：T#5S的精度到底够不够
先给结论：在绝大多数跨小时运行时间统计场景里，T#5S这种定时器时基是够用的，前提是你理解并控制住了误差来源。我们来算一笔账。
假如PLC扫描周期稳定在10毫秒，一个5秒定时器的实际触发间隔大约是5秒加一个扫描周期的误差，也就是5.000秒到5.010秒之间波动。一小时有720个5秒周期。如果每次都是正向误差10毫秒，一小时的累计误差是720乘以10毫秒，等于7.2秒。如果误差正负交替，累计误差会小一些，但无法保证。
问题在于扫描周期本身会波动。程序里加一段通信指令、某个中断突然插入、上位机组态读写变量，都会让扫描周期从5毫秒跳到15毫秒。这种波动反映到定时器上，就是定时时基变得“忽快忽慢”。在小程序里还好，扫描周期稳定在3到5毫秒，一小时误差能控制在2到3秒以内；在大中型程序里，我见过一小时偏差十几秒的情况。
所以别把T#5S当作绝对的5秒。它实际是“大约5秒”的周期脉冲。如果你的报表要求精确到秒级甚至更细，那就不能只靠这个，需要引入实时时钟校准。
2.2 纯计数场景：R_TRIG为什么更合适
如果统计对象是“外部事件的次数”，比如产线上经过的工件数量、设备启停次数，那T#5S定时采样就没有意义了，因为两次事件之间的时间间隔是随机的，你根本不知道下一次上升沿什么时候来。这种场景就该用R_TRIG。
在实际项目中，用R_TRIG做计数需要注意两点。第一是输入信号的脉宽必须大于一个扫描周期，否则上升沿会被漏掉。比如扫描周期10毫秒，外部信号只维持5毫秒的高电平，那PLC根本看不到这个脉冲。第二是机械触点存在抖动问题，一个按钮按下去，触点可能在一两毫秒内反复通断，程序里看到的可能不是一次上升沿而是好几次，计数会严重虚高。
因此，纯计数场景下R_TRIG的原理没问题，但实际落地一定要配合输入滤波或程序防抖。顺便说一句，如果计数频率高、信号脉宽短，普通数字量输入模块根本不够用，得上高速计数器模块或者CPU中断，那是另一个层次的问题。
2.3 关键误区：R_TRIG不能替代T#5S做周期时基
总有人觉得“我用R_TRIG检测一个5秒脉冲，再触发累计，逻辑上是一样的”。这里有个隐藏的依赖：那个5秒脉冲从哪来？如果来自另一个定时器，那精度瓶颈仍然是定时器，R_TRIG只起到了“整形”作用，并没有改善时基稳定性。
还有更绕的用法，用R_TRIG检测系统时间变量“秒”字段从59跳变到0的上升沿，然后触发一分钟的累计。这种方案看着巧妙，实际很危险。因为PLC程序扫描不是连续的，一次扫描可能跨越两个秒点，也可能在一个扫描周期内跳过整个秒字段变化，你根本检测不到。尤其是扫描周期不稳定时，这种靠变量边沿推时间的方法几乎必然丢统计。
所以我的看法很明确：R_TRIG做事件检测天生合适，但做周期时基是绕了远路，其稳定性不会超过你背后那个时基源，还要额外承担漏检风险。真正要比的是，T#5S定时方案和“R_TRIG+某种时基”的组合方案谁更直接、谁更不容易出错，答案显然是前者更简单。
3. 跨小时边界的工程细节：整点对齐、快照与掉电处理
3.1 最容易被忽略的整点对齐问题
跨小时统计比普通的定时器累计多了一个“跨”字，这意味着不能简单地从开机那一刻开始累加，必须在每个自然小时边界做一次结算。很多程序跑了好几天才被发现报表对不上，原因就在于起始点不是整点，结算点也不是整点，累计区间跟自然小时错开了。
正确的结算是以实时时钟RTC为准。检测小时字段变化，比如当前小时是9，扫描时发现变成了10，说明边界到了。这里有三个注意点。第一，不能用“等于10”来判断，因为小时字段只在变化瞬间等于10，之后一直是同一个值；正确的写法是判断“旧小时不等于新小时”。第二，PLC自身时钟存在走时误差，一般每个月能差几十秒，长时间运行后边界时刻会慢慢漂移，所以还要定期让PLC对时，或者直接用支持NTP的模块同步。第三，程序修改系统时钟本身也会触发小时跳变，如果有工程师在运行中途调时间，统计会发生非预期的整点结算，要避免在统计周期内乱改PLC时钟。
3.2 累计值快照与自动结转
整点边界检测到之后，需要完成三件事：把当前累计值存入上一小时的报表变量、把累计变量清零、把“当前小时”变量更新为新的小时值。这三件事要在一个扫描周期内原子完成，顺序不能乱。如果先清零再保存，保存下来的就是零；如果先更新小时再保存，检测跳变的逻辑就被破坏。
我习惯用一个临时保持变量先做快照，再清理计变量。所谓的快照，就是把本小时累计值复制到一个专门的“上一小时结算值”变量中，同时记录结算时刻的小时数和日期。这样即使上位机没及时读取，数据也不会丢。对于“跨小时产线计数器”这类需求，快照和清零必须绑定在同一个PLC扫描周期内完成，否则可能出现重复计数或漏计数。
这里还要注意数据宽度。运行时间累计如果要跑很多天，别用16位整型存。一小时720个数据点，一天累计就是17280秒，很容易溢出，建议用带符号32位甚至64位整型，或者用实数并定期归档。
3.3 掉电保持与上电自检
跨小时统计最怕掉电。PLC一断电，累计算了一半的值如果存在普通变量区，恢复供电后清零，这一小时的报表就废了。处理办法是把累计量、当前小时、上小时快照全部放在断电保持区。不同平台保持区设置方式不一样，有的靠变量属性勾选，有的靠专门的保持寄存器区域，这一点编程前就要规划好，程序写好再改很麻烦。
但掉电保持也不是银弹。如果PLC电池没电了、程序被重新下载过、或者做过存储器复位，保持区数据同样会丢失。所以上电后要做自检，比如检查保持区里“当前小时”是否与系统RTC小时一致，不一致就说明数据可能失效，需要提醒操作人员确认。另外，掉电期间损失的统计时间是任何程序都无法弥补的，理论上掉电多久就缺多久的数据，除非外部有断电检测和备用电池方案。别指望PLC自己解决这个问题，这是系统设计层面的边界。
4. 推荐方案与程序模板：双基准才是现场最稳的做法
4.1 为什么现场最稳的组合是RTC加T#5S二级累加
写到这里你会发现，T#5S和R_TRIG根本不是非此即彼的对抗关系。真正的稳定方案是分层：用RTC做绝对基准，解决自然小时边界和长期累积误差；用T#5S定时器做周期累加节拍，解决“怎么把连续过程切成离散采样”的问题。R_TRIG在这个体系里的角色，是负责检测外部输入事件，而不是参与时间基准。
二级累加的逻辑是：每个5秒周期，程序对当前过程的瞬时值做一次累加；每个小时边界，程序对整点前的累计值做一次快照结算。T#5S的误差是小时内部误差，RTC在整点把它校准归零。也就是说，即使前59分钟T#5S漂移了5秒，整点结算时报表仍然以RTC时刻为准，误差不会跨小时累积。这套结构避免了“误差滚雪球”，也避免了R_TRIG漏检导致整段统计丢失的风险。
为什么不用时间差算法直接算累计？很多高级PLC支持读取系统时间，理论上可以每扫描周期计算当前时间与上一次扫描的时间差并累加。但扫描周期远小于1秒时，时间差经常是0秒，小数秒的处理很麻烦，而且系统时间读取本身也有调用开销。相比之下，T#5S定时脉冲累加简单直观、CPU占用低，配合RTC整点校准，现场可维护性远远好于精巧的时间差算法。
4.2 PLC程序结构模板
用通用SCL风格写一个参考实现，具体指令名称以你自己用的平台为准。这个结构我实测过，改动较少，适合直接移植到主流欧系PLC上。
// 变量声明（示意） // RTC_Now : DTL; // 当前系统时间 // Hour_Old : INT; // 上一个小时值 // Hour_New : BOOL; // 检测到小时边界 // Pulse_5s : BOOL; // 5秒周期脉冲 // Acc_Seconds : DINT; // 当前小时累计秒 // Last_Hour_Total: DINT; // 上一小时结算值 // Sample_Ready : BOOL; // 整点快照完成 // 第一步：读取系统时间（通常在OB1里调用） RTC_Now := GET_DT(); // 第二步：检测小时边界 Hour_New := FALSE; IF RTC_Now.Hour <> Hour_Old THEN // 先快照，后清零，再更新小时值 Last_Hour_Total := Acc_Seconds; Acc_Seconds := 0; Hour_Old := RTC_Now.Hour; Hour_New := TRUE; END_IF; // 第三步：5秒周期脉冲输入（由独立定时器或循环中断产生） IF Pulse_5s THEN Acc_Seconds := Acc_Seconds + 5; END_IF; // 第四步：上位机或HMI读取 Last_Hour_Total 用于报表显示这个模板有几个细节值得说明。Hour_Old必须存放在断电保持区，否则上电后无法感知当前小时，可能导致重复快照。Acc_Seconds也是保持区变量，但清零动作写在检测到小时边界之后。Pulse_5s如果你用TON自复位脉冲生成，要注意TON的输出本身会再维持一个扫描周期，这会导致计时偏大一个扫描周期级别，影响不大但要知道。如果你用循环中断OB来实现5秒任务，中断OB内部不要写过多逻辑，只置位一个全局脉冲标志位，其余计算全部回到OB1完成，避免中断里做复杂运算引发新的抖动。
4.3 现场验证记录与误差统计
我曾在一个中等规模的项目上做过对比测试，程序大小大概一万多条指令，通讯负载中等。用T#5S定时器方案并辅以RTC整点校准跑了一天，每个小时报表的结算时刻与标准时间误差都控制在1秒以内，也就是RTC字段跳变本身的分辨率。单独关闭RTC校准、只靠T#5S累加，连续跑四个小时后，累计时间比标准时间快了11秒，算下来误差趋势很稳定。
这个结果很能说明问题：纯T#5S的误差是可预测但不可接受的，长期运行会越来越大；加了RTC整点校准之后，误差被限制在单个小时内部，报表数据立刻变得干净。还有一次现场出现了PLC时钟被误改的问题，靠Hour_Old与RTC_Now.Hour的差异检测，程序自动做了一次补偿结算，没有造成报表大面积混乱。这些实测数据，比任何理论推导都有说服力。
5. 避坑清单与排查参考
5.1 常见问题速查表
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 每小时报表比实际多几分钟 | 定时器基于扫描周期，正向误差累加，且未做RTC整点校准 | 检查是否有RTC边界结算，核对Hour_Old保持变量 |
| 某个小时彻底没有数据 | R_TRIG漏检或整点结算逻辑使用了“等于小时”而不是“小时变化” | 查程序里的边界检测语句，观察整点时刻变量跳变 |
| 产量计数明显虚高 | 机械触点抖动，一个信号被当成多次上升沿 | 给输入加滤波时间，或在程序里做延时确认 |
| 断电重启后累计从零开始 | 累计变量未放保持区，或保持区数据被程序下载清除 | 检查变量保持属性，重新下载前确认是否需备份 |
| 调整PLC时钟后报表错位 | 小时跳变被当成自然整点边界 | 严格要求现场不要把统计软件和时钟同步混在一起操作，或在程序中加边界时间范围条件 |
| 长时间运行后报表逐渐偏移 | PLC时钟走时误差累积 | 接入外部时间同步，或定时对时，长期项目建议加时钟同步功能 |
5.2 我踩过坑后留下的几点忠告
第一，变量类型和保持属性在项目一开始就要定好，尤其是Acc_Seconds、Hour_Old、Last_Hour_Total这三个。程序写完之后再改保持属性，如果不注意很容易把在线值清掉，眼睁睁看着数据归零。第二，不要在OB1里塞太多长耗时操作，扫描周期抖动直接放大定时误差。你花大力气把算法写好，结果一个通信块占了几十毫秒，所有精度全白费。第三，对外部输入信号一定要做防抖，R_TRIG对脉冲宽度敏感，别拿硬件继电器触点的抖动去考验它的边沿检测能力，软件里加一个“持续两三个扫描周期才确认有效”的滤波最保险。
还有一个小技巧，把“当前小时累计值”和“上一小时结算值”同时送到HMI上显示。我现在每个统计界面都会放两个数字，一个是正在累计的本小时值，一个是上一次结算值，现场操作人员看到这两个数在整点自动切换，心里就有底。凡是能让人一眼看懂程序在正确工作的设计，都值得做。过了整点那一两秒，如果本小时累计没有跳回零，基本可以断定结算逻辑被什么东西卡住了，这时去查程序比对着报表算误差快得多。
另外提醒一句，上位机报表软件的读取时序也要配合。PLC快照完成之后变量会保持一整小时不动，但如果上位机恰好在快照前后各读一次，可能读到旧值和新值，处理不好会在数据库里留下一条异常记录。稳妥的做法是上位机每次只在整点过后的固定延时读取，或者让PLC提供一条“数据有效”标志，上位机看到标志再取值，能避免很多莫名其妙的报表毛刺。
从我的使用习惯来说，跨小时统计从来不是“T#5S还是R_TRIG”的二选一。事件统计用R_TRIG，周期采样用T#5S，整点结算靠RTC，三者各司其职。把边界对齐、掉电保持和上电自检这些外围工作做完，报表数据才真正靠得住。这种组合方案我看着简单，现场改起来却救过不止一次急。下次你再被人问“哪种稳”，可以直接回答：单独用哪儿都不稳，分层用才稳。
