干这行时间长了总会碰到一些“看着简单想深了全是坑”的问题。上周帮一个客户排查产量统计误差现场程序里同时出现了以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三者各司其职。把边界对齐、掉电保持和上电自检这些外围工作做完报表数据才真正靠得住。这种组合方案我看着简单现场改起来却救过不止一次急。下次你再被人问“哪种稳”可以直接回答单独用哪儿都不稳分层用才稳。