Let me count the ways
The most commonly found in code (also the most inaccurate, but good enough for Motor Run Times
AUX OneSecTmr.DN OneSecTmr
+------TON --+
---| |------------|/|-----------| PRE: 1000 |
+------------+
Use the OneSecTmr.DN bit as your pulse.
The inaccuracy in this code is on the order of 2% ± short. You lose one full scan, plus the overrun of the scan time when the TON was last executed.
Since the "Run Time" is mostly for guestimating ("That's a lot of time; we should get ready to service it") or comparison ("Motor A has more run time than Motor B"), accuracy isn't an issue.
The code that John Morris posted is a more, but not perfectly accurate. It eliminates the missed scan (for not-true TON to reset the .DN bit), but still loses scan elapsed time (as daba pointed out)
Presumably you are counting seconds to display hours. If you use a TON to actually time hours, you lose lots of fractional hours each time the motor turns off. A Retentive timer prevents that loss, and putting the reset before the timer means that the DN bit will be on for one scan.
OneHrPulse.DN OneHrPulse
----------| |-------------[ RES ]
AUX OneHrPulse
+----------RTO--+
--------| |------------| PRE: 3600000 |
+---------------+
The amount of inaccuracy in this timer is on the order of .001%. More than good enough for Run Time, and if you want to include fractional hours, just add your integer hour count + ACC/PRE.
The most accurate 1 sec pulse counter is to
AUX RUNNING_TMR
+-------------RTO--+
--------| |------------| PRE: 2147483647 |
+------------------+
+-----------GRT---+ +------------SUB---+ OneSecPulse
----| RUNNING_TMR.ACC |--------| RUNNING_TMR.ACC |---------( )-
| 1000 | | 1000 |
+-----------------+ | RUNNING_TMR.ACC |
+------------------+
The timer never DONEs out, and is never reset. But it also never accumulates more than 1 second of total elapsed time. It never loses the scan overruns.
Overkill for a Running Time counter, but is as accurate or more as using a Timed Task.