PLC定时器TONR累计时间偏差原因与S7-200 SMART解决方案

1. 先把TONR这个"累加器"的脾气摸清

干自动化这行十来年，PLC定时器可以说是天天见，但真要说清楚TONR为什么累计时间老是对不上，很多人第一反应还是"程序逻辑没问题啊"。我印象特别深的一次是给某设备做运行时长统计，程序写得很简单，就是TONR累计继电器吸合时间，结果现场跑了半天，数据和秒表差了将近两成，操作工说设备一天到底跑了多久全凭感觉。问题最后查出来不是逻辑写错，而是扫描周期与时基的关系没搞明白——TONR的累计值并不是"物理时间的忠实记录员"，它只是按自己的刷新节奏在数数，你的程序节奏跟它对不上，数出来的当然不准。

这篇文章就围绕PLC定时器里最容易翻车的TONR展开，重点讲累计时间出错的几类真实原因，并给出S7-200 SMART上可以直接照抄的解决方案。适合刚上手PLC编程、正在做设备运行时长统计、故障计时、累计产量节拍这类功能的朋友；也适合已经写了两三年程序，但一直没细究过定时器刷新机制的老手——后面几个坑，我见过不少干了很久的人照样踩。

1.1 TON、TONR、TOF三兄弟，差的不只是一个字母

先把三个最常用的接通延时类指令摆在一起看，很多累计错误其实源于"用错了指令"。

指令	使能条件断开后的行为	复位方式	典型用途
TON	当前值立即清零，位复位	自动	普通延时启动、延时报警
TONR	当前值保持不变，继续"记着"	必须用复位指令或复位线圈	累计运行时间、累计故障时长
TOF	使能接通时清零，断开后开始延时	自动	延时停止、风机后吹

TONR最关键的特性就是那行"保持不变"。它的设计意图很明确：让你把多次、断续的接通时间攒起来。比如一台设备一天里启停几十次，你想知道它总共跑了多久，就得靠TONR。

但问题也恰恰出在这里。因为TONR不会自动清零，程序里就必须有一个明确的复位动作，而这个复位动作放在哪、用什么条件触发，直接决定了累计值准不准。我见过最常见的写法是把TONR自己的常开触点串回去做复位，看起来"到点清零重新开始"很合理，实际上是个隐藏的坑，后面第2章会展开说。

另外还有一点必须提前说清楚：TONR的当前值是16位有符号整数，最大32767。这个上限对累计类应用来说非常要命，具体影响在第2.5节细讲。

1.2 时基选错，精度和量程一起丢

S7-200 SMART的定时器按时基分成三档，编号是固定分配的，不是你想用哪个就用哪个。

时基	TONR可用编号	TON/TOF可用编号	单只定时器最大计时
1ms	T0、T1	T32、T96	32.767秒
10ms	T2～T17	T33～T36、T97～T100	327.67秒
100ms	T18～T31	T37～T63、T101～T255	3276.7秒（约54.6分钟）

这张表建议直接打印贴在工位上。我见过有人拿T0做设备运行时长累计，跑了三四十秒数值就卡在32767不动了，还以为是程序被干扰，查了一下午。1ms时基的TONR量程只有32秒出头，拿它做时长统计，等于用一把30厘米的尺子量操场。

时基选择的核心逻辑是：精度要求和量程要求是一对矛盾。你要毫秒级精度，量程必然短；你要几小时的累计，只能牺牲精度。实际项目里我的习惯是，累计类应用优先用100ms时基，除非工艺明确要求误差小于100ms。

还有个小细节：不同固件版本的编号分配可能略有出入，写程序前在编程软件的指令树里点一下定时器，编号提示会直接告诉你哪段是1ms、哪段是100ms，比你翻手册快。

1.3 设定值PT不是秒，是"时基的个数"

这是新手最容易懵的地方。S7-200 SMART里TONR的PT引脚填的是整数，单位不是秒，也不是毫秒，而是"多少个时基"。

换算公式很朴素：

实际延时 = PT × 时基

举几个例子对照：

时基	PT值	实际延时
100ms	10	1秒
100ms	600	60秒
10ms	100	1秒
1ms	1000	1秒

我遇到过一次现场争议：程序里TONR T37写的是PT=3600，工程师坚持说"我设的是一小时"，结果实际只有6分钟——他用的是100ms时基，3600×100ms=360秒。这种错误在调试阶段还能发现，要是放在无人值守的设备上跑一个月，统计数据全废。

2. 累计时间出错的七个真实原因

下面这七条，基本覆盖了我这些年遇到过的TONR累计异常。你可以对着自己的程序一条条过，命中率很高。

2.1 原因一：扫描周期大于时基，时间被"吞"掉

这是最隐蔽、也最容易被忽略的一条，必须先讲。

S7-200 SMART的定时器刷新机制按时基不同而不同：

• 1ms定时器：由系统以1ms为间隔异步刷新，跟扫描周期没关系，相对最准；
• 10ms定时器：在每个扫描周期开始时刷新一次；
• 100ms定时器：在执行到该定时器指令时刷新。

关键在于"刷新一次只加一个时基"。假设你的程序扫描周期是30ms，用100ms定时器，一个100ms窗口内程序会扫过三四次，总有一次执行到指令时已经过了100ms，于是当前值加1，误差不超过一个扫描周期，可以接受。

但如果扫描周期因为程序庞大、通讯任务重、或者加了大量浮点运算而涨到120ms，情况就变了：每120ms才执行一次指令，每次只加100ms，实际过了120ms却只记了100ms，累计值系统性偏小，跑得越久差得越多。这就是典型的"时间被吞掉"。

TONR做累计时这个问题被放大得更明显，因为累计本身就是长时间行为，百分之十几的偏差在几分钟内看不出来，跑一天就成了大问题。

判断方法很简单：在编程软件里看扫描周期（状态图表或系统信息里都有），如果最大扫描周期接近或超过你的定时器时基，基本可以锁定原因。

解决思路有两条：一是换更小的时基（比如从100ms换到10ms），让扫描周期远小于时基；二是干脆别用定时器直接累计，改用第3章的方案二或方案三。我个人的选择是，只要累计时长超过十几分钟，一律不用TONR直接累，直接上双字方案，省心。

2.2 原因二：把IN断开当成复位，复位逻辑写反

TONR的IN引脚断开只是"暂停累计"，不是"清零"。这个特性手册上写得明明白白，但实际程序里出错的比比皆是。

典型的错误写法是这样的：用TONR的常开触点去复位自己。

LD T37 R T37, 1

看起来逻辑闭环了：到时间就复位，然后重新开始累。实际运行时会出现两种诡异现象：一种是累计值永远停在设定值附近上不去；另一种是每个扫描周期都在复位与计时之间来回横跳，监控里数值疯狂跳动。

更常见的是复位条件写成了常闭。比如操作工按一下复位按钮，你写的是LDN I0.1，按钮没按时这个条件一直为真，定时器每个周期都被清零，累计永远是0。这种错误在监控画面上表现为"数值一动不动"，很容易被误判成程序没执行。

我的写法习惯是：复位用独立的复位指令，条件用上升沿，并且和使能条件做互锁。复位按钮按下的那个扫描周期清零，松手后重新开始累计；同时保证复位和IN不会同时有效，避免"清零后立刻重新计时"造成的时间丢失。

还有一点，复位指令应该放在累计判断之后。如果放在前面，本周期刚判断完的时间点会被下一次清零覆盖，边界上会丢一个时基。

2.3 原因三：断电保持区没设，一上电全归零

这个问题在调试阶段几乎发现不了，因为调试时你很少断电。等到设备交付、现场断电重启，累计值归零，用户立马投诉。

S7-200 SMART的定时器当前值属于T区，能不能掉电保持，取决于系统块里"保持性范围"的设置。默认情况下，只有一部分区域被划入保持范围，如果你的TONR编号不在这个范围内，断电后当前值就丢了。

设置路径大致是：编程软件里打开系统块，找到保持性范围设置，里面可以分别配置V区、M区、定时器、计数器的保持范围。把用到的TONR编号段纳入保持区，然后下载系统块。

这里有个必须提醒的点：修改保持区之后要重新下载系统块，部分情况下还需要断电重启才完全生效。我见过工程师只下载了程序块，没下载系统块，改了半天没反应，最后以为是硬件问题。

另外要有个心理预期：这类小型PLC的掉电保持靠内部储能元件维持，短时间断电没问题，长时间断电（比如设备停产一周）数据还是会丢。如果你的应用对"断电多久都不能丢"有硬要求，那就别指望定时器，直接用第3.3节的RTC方案，或者把数据写到EEPROM里定期保存。

2.4 原因四：T编号重复占用，两个逻辑抢一个定时器

S7-200 SMART的定时器编号是全局资源，整个项目里同一个编号只能被一个逻辑使用，主程序、子程序、中断程序都共享这套编号。

我排查过一次特别典型的案例：主程序里用T37做1秒脉冲发生器，子程序里又用T37做某个阀门的延时。结果主程序的秒脉冲忽快忽慢，累计值自然一塌糊涂。原因是子程序每次调用都会改写T37的当前值，两个逻辑互相踩。

还有一种更隐蔽的情况：同一个子程序被多次调用，子程序内部用了定时器。第一次调用时定时器开始计时，第二次调用进来直接把当前值改了，两次调用的计时互相干扰。这种情况在多工位、多轴控制的程序里很常见。

我的做法是维护一张定时器编号分配表，写程序前先规划好：哪几个给脉冲发生器，哪几个给累计，哪几个给报警延时，子程序专用哪一段。表贴在项目文档里，团队共用。

编号段	用途	责任人
T37～T40	系统秒脉冲、分脉冲	主程序
T41～T45	工位一延时	子程序1
T46～T50	工位二延时	子程序2
T51～T60	报警延时	报警子程序

表看着土，但真能省下大量排查时间。

2.5 原因五：16位当前值到32767就到顶了

前面提过，TONR的当前值是16位有符号整数。这意味着不管你用时基多少，当前值最大就是32767，到了就停住，再怎么计时也不涨。

换算成实际时间：

时基	累计上限
1ms	32.767秒
10ms	327.67秒（约5.5分钟）
100ms	3276.7秒（约54.6分钟）

也就是说，用TONR直接累计，最长只能记54分钟多一点。超过这个时间，数值就卡死，而PLC不会给你任何报错提示，位输出照常置位，程序照常运行，只有你知道数据是假的。

这个坑的杀伤力在于"看起来正常"。设备运行一小时，累计显示54分36秒，操作工可能以为是显示问题，工程师可能以为是换算问题，很少有人第一反应是"定时器溢出"。

解决办法只有一个：长时间累计必须用双字（32位）。用定时器产生基准脉冲，再用双字加法或自增指令累加，量程直接上到21亿秒，够用了。

2.6 原因六：PT和时基单位混着用，换算全乱

这条前面提过一半，这里补充几个实战中见过的具体错法。

第一种：把PT当成毫秒填。想要10秒延时，100ms时基，PT填了10000，实际是1000秒。程序跑起来延时长得离谱，还以为是定时器坏了。

第二种：换时基忘了改PT。原来用100ms定时器，PT=100是10秒；后来因为精度不够换成10ms定时器，PT还是100，变成1秒了。程序行为突变，查半天。

第三种：累计值的单位没统一。有的人累计用秒，有的人用毫秒，显示的时候除以1000还是除以60全凭感觉，最后画面上的数字和实际对不上。

我的习惯是全项目统一用秒做累计单位，PT换算写在注释里，显示的时候再按需转成时、分、秒。这样即使换时基，改的也只是产生秒脉冲的那一段，累计和显示部分完全不用动。

2.7 原因七：监控看到的数字，不一定是真实累计

最后这条不算程序错误，但确实误导过不少人。

在状态图表里监控TONR的当前值，看到的是一个整数在跳。这个整数需要乘以时基才是时间，而且受扫描周期影响，监控刷新本身也不是实时的。有人盯着监控看，发现数值"跳着走"、"有时候停一下"，就断定程序有问题，其实是监控刷新和定时器刷新不同步造成的视觉误差。

还有一种情况：程序里对累计值做了整数除法显示。比如VD100存的是秒，显示分钟时用VD100 / 60，余数直接丢掉。结果画面上分钟数从59跳到60之前会卡很久，操作工以为计时停了。正确做法是除法取商显示分钟，再取余数显示秒，两个都用上。

3. S7-200 SMART上的三种累计方案

理论讲完，下面给可以直接抄的方案。三种方案适用场景不同，我按从简单到可靠的顺序排。

3.1 方案一：TONR直接累计，只适合短时间粗精度

适用场景：单次累计不超过几十分钟、精度要求±100ms、逻辑越简单越好。比如某个动作的超时报警累计。

// 累计条件接通时开始累加，断开保持 LD I0.0 TONR T18, 600 // 读取当前值并换算成秒（100ms时基，除以10） LD SM0.0 MOVW T18, VW100 ITD VW100, VD102 DTR VD102, VD106 DIV VD106, 10.0, VD110 // VD110即累计秒数 // 复位按钮，上升沿清零 LD I0.2 EU R T18, 1

这段程序有几个点要注意：T18属于100ms时基的TONR段；复位用上升沿，且和累计条件I0.0在工艺上互锁；换算用浮点除，避免整数除法丢精度。

这个方案的局限很明显：上限54.6分钟，扫描周期不能超过100ms，精度受刷新机制影响。只建议用在短时、非关键的场合。

3.2 方案二：定时器加双字累加，通用性最强

这是我日常项目里的默认方案。核心思路是把"计时"和"计数"拆开：定时器只负责产生一个稳定的秒脉冲，累计交给双字指令。

产生秒脉冲的写法有两种。用SM0.5最省事，它是1秒周期的时钟脉冲（0.5秒通、0.5秒断），取上升沿就是1秒一次。但SM0.5同样受扫描周期影响，扫描周期超过0.5秒时会漏脉冲。所以更稳的写法是用定时器自复位：

// 1秒脉冲发生器，T37为100ms时基，PT=10即1秒 LDN T37 TON T37, 10 // T37接通的那个扫描周期，累计秒数加1 LD T37 EU INCD VD200

LDN T37的意思是T37没到时间时保持输入有效，到时间后T37置位，下一个扫描周期输入断开，定时器自动复位，如此循环。T37的触点只接通一个扫描周期，所以后面加个EU更保险。

有了秒脉冲，剩下的就是换算和显示：

// 总秒数换算成时、分、秒 LD SM0.0 DIV VD200, 3600, VD204 // 商为小时 MOVD VD204, VD300 MUL VD204, 3600, VD208 - VD200, VD208, VD212 // 余数 DIV VD212, 60, VD216 // 商为分钟 MOVD VD216, VD304 MUL VD216, 60, VD220 - VD212, VD220, VD224 // 余数为秒 MOVD VD224, VD308

VD300、VD304、VD308分别存时、分、秒，画面上直接绑这三个变量就行。VD200作为总秒数保留，做报表统计、导出历史数据的时候用得上。

这个方案的优势是量程大、精度稳定、断电保持也好处理。缺点是要多写几行程序，但一次性写好，后面所有累计需求都能套用。

还有一个变体：如果工艺要求分钟级精度就够，可以把秒脉冲改成分钟脉冲，PT改大一点，累计变量直接存分钟。不过我还是建议底层存秒，显示层再换算，原始数据粒度细一点，后面想做任何统计都方便。

3.3 方案三：BGN_ITIME/CAL_ITIME与RTC，做长时间精确统计

如果对精度要求更高，或者需要跨断电统计，S7-200 SMART还提供两个更好用的工具。

第一个是BGN_ITIME/CAL_ITIME指令对。BGN_ITIME用来记录一个起始时刻，CAL_ITIME用来计算当前时刻与起始时刻的差值，单位是毫秒，结果存放在双字变量里。分辨率是1ms，量程足够覆盖几十天。这个组合特别适合测量单次动作的耗时，比如一个气缸从伸出到到位用了多少毫秒、一次焊接过程耗时多长。用法上，动作开始时触发BGN_ITIME，动作结束时触发CAL_ITIME，输出直接就是毫秒数，不用自己换算。

第二个是读写实时时钟。PLC内部有RTC，走的是年月日时分秒。做超长时间统计时，我的做法是每隔一段时间（比如每分钟）读一次RTC，和上一次的记录做差，把差值累加到双字变量里。这样即使断电重启，RTC还在走，累计逻辑可以从断点续上。代价是精度只到秒级，而且要做RTC数据的BCD码转换，程序稍复杂。

三个方案横向对比：

方案	精度	量程	断电保持	实现难度	推荐场景
TONR直接累计	±1个时基	最长54.6分钟	需设保持区	低	短时超时判断
定时器+双字累加	±1个扫描周期	21亿秒	需设保持区	中	常规运行时长统计
BGN_ITIME/RTC	1ms/1s	极大	RTC天然保持	中高	精确测时、跨断电统计

实际项目里我经常混用：秒脉冲累计做总量统计，BGN_ITIME做单次动作分析，两个数据互相印证，出问题时很容易定位是哪一层出了偏差。

3.4 掉电保持与上电初始化，收尾的两步

不管用哪个方案，这两步不能省。

保持区设置：打开系统块，找到保持性范围，把V区中存放累计值的地址段、以及用到的定时器编号段纳入保持范围。比如累计值放在VD200～VD230，就把V区保持起始地址设到200之前，长度覆盖到230之后。设置完下载系统块，最好断电重启一次验证。

上电初始化：用SM0.1（首次扫描标志）做初始化的判断。但注意，如果你希望累计值掉电保持，就绝对不能用SM0.1去清零累计变量，否则每次上电都归零，保持区白设了。SM0.1只用来初始化那些不需要保持的中间变量。

需要清零的时候，用画面上的清零按钮，条件用上升沿，加个确认提示，避免误操作把几个月的统计数据一下抹掉。这个细节我吃过亏——早年间做的设备，清零按钮没做防抖也没做确认，操作工擦屏幕时误触，一个月的产量统计数据没了。

4. 现场排查实录：五步定位累计偏差

程序写完不代表结束，现场对不上数才是常态。下面这套流程是我这些年反复用的，基本能在半小时内定位问题方向。

4.1 第一步：先看偏差的方向和量级

拿到"累计不准"的反馈，第一件事不是改程序，是问清楚怎么个不准法。

偏差偏小，可能是扫描周期大于时基导致漏计、复位误动作、或者当前值到32767封顶。偏差偏大，多半是重复计时、多个脉冲源叠加、或者逻辑里同一个累计变量被加了两次。数值直接归零，往掉电保持区、上电初始化、复位逻辑三个方向查。数值来回跳，优先怀疑编号冲突或子程序重复调用。

量级也很重要。差百分之几，是精度问题；差几倍，是换算或时基错了；差一个固定值，可能是初值没清。

我一般会让现场配合做一次简单验证：用秒表掐10分钟，对比PLC里的累计值，算出偏差百分比。这个数据比任何描述都直观。

4.2 第二步：拿一个独立基准做对照

不要用被怀疑的定时器去验证它自己。我的做法是临时加一段对照程序，用SM0.5或者RTC做一个独立的时间基准，和被怀疑的累计值同时跑，两个数据一起看。

如果基准正常、累计异常，问题在累计逻辑；如果两个都异常，问题在扫描周期或者CPU负载；如果两个都正常但画面显示不对，问题在显示换算。

这一步能省掉大量猜测。有一次现场反馈"累计快了一倍"，我加了基准一对比，发现累计值每个扫描周期加了两次——原因是有个自保持逻辑让秒脉冲的上升沿被重复触发。没有基准对照，这个很难看出来。

4.3 第三步：查编号和复位

编号冲突和复位逻辑是最高频的两个问题，建议直接翻程序做静态检查，不用等运行。

编号检查：把程序里所有用到定时器的地方列出来，看有没有重复。特别注意子程序里的定时器，以及带参数调用的子程序——同一个子程序被多处调用时，内部定时器会互相干扰。

复位检查：找到所有复位指令，看触发条件。常闭条件、没有上升沿、复位和使能同时有效，这三种都是雷。另外确认复位指令的位置，应该在累计判断之后。

4.4 第四步：查保持区和上电逻辑

如果现象是"运行中正常、断电重启后归零"，直接去系统块看保持范围。确认三点：地址段覆盖了累计变量、定时器编号段在保持范围内、系统块已经下载。

再用SM0.1检查一遍上电初始化逻辑，看有没有把不该清的量清了。这个错误很常见，尤其是程序从别的项目复制过来的时候，初始化段里一堆MOV指令，把保持区里的数据全冲了。

4.5 常见问题速查表

把上面的排查经验整理成表，现场可以直接对着看。

现象	最可能原因	快速验证方法	处理动作
累计值偏小约10%～30%	扫描周期大于时基	查看最大扫描周期	换小时基或改双字方案
累计值到某数就不动了	16位溢出32767	监控当前值是否停在32767	改双字累计
累计值永远为0	复位条件常闭或每周期触发	监控复位指令前的条件	改上升沿、加互锁
断电重启后归零	保持区未设置	检查系统块保持范围	设置并下载系统块
数值乱跳	定时器编号冲突	列出全部定时器使用点	重新规划编号
画面显示卡住不涨	整数除法丢余数	检查显示换算逻辑	商和余数分开计算
设定延时和预期差10倍	PT与时基单位混用	核对PT值和时基	按换算公式重填

5. 几条踩过坑才明白的经验

写到这里，技术点基本讲完了，最后聊几条不那么"正式"但很实用的体会。

5.1 时基选择上，宁可粗一点也别乱选

刚开始写程序的时候，总觉得时基越小越精确，什么都想用1ms。后来发现1ms定时器量程只有32秒，稍微长一点的延时就得级联，程序复杂不说，还容易出错。现在我选时基的顺序是：先看工艺要求的精度，再看量程需求，两个都满足的前提下选大的那个。100ms时基能覆盖绝大部分延时和累计需求，1ms时基留给真正需要精确测时的场合，比如高速计数、短脉冲捕捉。

5.2 累计数据统一单位，是省事的根本

项目做多了会发现，累计类程序出问题，八成不是算法难，而是单位乱。秒、毫秒、分钟、小时混着用，换个工程师接手就看不懂。我现在所有项目的规矩是：底层一律存秒，双字变量，变量名带单位后缀（比如RunTime_s），显示层再转成时分秒。这条规矩看着笨，但真的能省掉无数次沟通成本。

5.3 给累计变量留个"体检入口"

我习惯在HMI上做一个调试页面，把原始秒数、换算后的时分秒、定时器当前值、扫描周期最大值全放上去。这些数据平时没人看，一旦现场反馈数据不对，操作工截图发过来，我基本能远程判断方向。这个习惯来自一次深夜被叫去现场的教训——当时没有任何中间数据可看，只能一行行查程序，折腾到凌晨。

5.4 复位按钮一定要做防误触

前面提过一次，这里再强调。累计数据往往是几个月的成果，误清一次损失很大。我的做法是：清零按钮长按3秒生效，或者弹出二次确认，再或者加一个"清零使能"开关，平时锁着。多写几行程序，省掉的是没法挽回的麻烦。

5.5 交付时把编号规划表一起给出去

项目交付的时候，除了程序和图纸，我会额外给一份定时器、计数器、中间变量的编号规划表。后面设备改造、加功能、换人维护，接手的人照着表就能找到空闲资源，不用满程序翻。这个习惯是从一个改造项目开始养成的——前人没留任何文档，我花了两天时间才理清哪些编号能用、哪些不能用，那种感觉不想让别人再体验一次。

累计时间这件事，说到底是个"账要记清"的问题。定时器只是记账的笔，笔好不好用是一回事，账本怎么设计、什么时候对账、丢了怎么补，才是真正决定数据准不准的东西。把刷新机制、时基量程、保持区这三件事想明白，剩下的就是按规矩写程序了。