The manual defines SP3 as a 1-minute clock, on 30 seconds and off 30 seconds, and publishes no accuracy for it. Counter clocks built on it have measured from about 1 minute a year to about 17 minutes a month fast, so run a week-long check against a reference. Keep the counter clock only if drift stays under about 10 minutes a month through the hot season; otherwise timestamp from a clock you can set.
SP3 is the 1-minute clock contact in the special-relays appendix of the PLC user manual: on for 30 seconds, off for 30 seconds. The appendix publishes the pattern and no accuracy, and that gap matters the moment a counter clock built on SP3 becomes the timestamp for an entry log. Reported drift on units running this arrangement runs from about 1 minute a year to about 17 minutes a month, a spread too wide to borrow either number for your panel. The number that counts is the one your PLC produces. Run a week-long check against a reference clock, project the drift to a month, and compare it with the error the records can absorb. Inside that tolerance through the hottest weeks, the counter clock stays. Outside it, timestamp from a clock you can set and resynchronize instead.
What the manual documents about SP3
The special-relays appendix defines three clock contacts. SP3 toggles once a minute, on for 30 seconds and off for 30 seconds. SP4 toggles once a second, on for 0.5 second. SP5 toggles every 100 ms, on for 50 ms. The appendix gives each period and its on/off split and no accuracy figure for any of the three, so the documented basis for a timestamp is a nominal period: 60 seconds per SP3 cycle.
A software clock counts those cycles. The minute counter increments once per cycle, carries into the hour counter at 60, and hours carry into days at 24. Two things set the clock's accuracy: the pulse period and the counting logic. The logic is yours to verify and fix. The pulse period is whatever the hardware delivers, and reported units differ by orders of magnitude. Temperature is the likely driver, and the hot-week repeat below is the test that confirms or clears it on your cabinet.
Symptoms and what each points to
- Timestamp gains a few minutes a month, steadily: pulse-source drift. Measure it against a reference, next section.
- Timestamp runs about double speed, gaining roughly 1,440 minutes a day: the logic increments on both phases of the SP3 cycle, the 30-second on and the 30-second off, so every real minute counts twice. Fix the edge logic first; no drift measurement means anything while it stands.
- Timestamp jumps or steps by hours: a carry fires at the wrong value, for example hours carrying at 100 instead of 60, or a carry or preset constant left wrong in the program from an earlier edit.
- Timestamp clears after a power cut: the counters are not retentive as programmed. Cycle the power and read the counters back to find out before trusting the log.
- Drift small in winter, large in summer: the pulse source follows cabinet temperature. Take the acceptance number from the hot season, the worst case the log will see.
Sort the double-speed case out first. A fixed 2x error is a logic fault with a definite fix, and measuring while it is present hides the true drift figure.
Measure the drift before you trust the log
- Pick a reference tighter than the tolerance. A phone or PC clock set from the network is close enough that its own error never registers next to a minutes-per-month figure.
- Write down both clocks at the start and let the PLC run normally for a week: 7 days x 24 h x 60 min = 10,080 reference minutes.
- Read the minute counter's accumulated value and subtract the reference. Drift = PLC elapsed time - reference elapsed time, and positive means the clock is fast.
- Project to a month: weekly drift x 30 / 7, because a month is about 4.3 weeks.
- Compare the projection with the tolerance the records need; for entry logs that is often 5 to 10 minutes a month.
- Run the same week once more through the hottest weeks the cabinet sees, and once after a power cut, so the number you accept covers the worst case.
Keep test readings off the live history. An entry written just to check the clock makes the record wrong in exactly the way the timestamp exists to prevent.
Example: a 7-day drift check on a shop entry clock
The inputs: a network-set reference clock; one week of running, 7 days x 24 h x 60 min = 10,080 reference minutes; the PLC minute counter read back at the end showing 10,084 accumulated; and a 10-minute-a-month tolerance, set by what the entry log is used for.
The rule: drift = PLC elapsed time - reference elapsed time, projected to a month as the weekly drift x 30 / 7.
The arithmetic: 10,084 - 10,080 = 4 minutes fast over the week. 4 x 30 / 7 = 17.1, so about 17 minutes a month. Over a year, 17 x 12 = 204 minutes, about 3 h 24 min.
The decision: 17 minutes a month exceeds the 10-minute tolerance, so the counter clock fails as this unit's timestamp and the timestamp moves to a clock you can set and resynchronize. Had the same check returned under 10 minutes a month, including the hot-week repeat, the counter clock would stay, with the check repeated each season.
Check the counting logic before judging drift
Drift is only measurable after the chain counts correctly. Watch the counters online while the plant runs and check three things:
- One SP3 cycle, 60 seconds on the reference clock, produces exactly one increment of the minute counter, cycle after cycle.
- The minute counter carries into the hour counter at 60 and the hour counter into days at 24, once per boundary, nothing left over.
- The accumulated values come back after a power cut if the timestamps must come back after one.
That carry chain is the same arithmetic any elapsed-time total uses, and adding minutes and seconds to a PLC total covers it in detail. Leave the rollover constants at 60 and 24. Stretching a carry to absorb drift, hours at 61 to hide a slow clock, turns one known error into a skew on every hour of every day.
Choose the timestamp source
Two arrangements pass the record test:
- The counter clock, when the hot-season check projects drift inside tolerance and the counters hold through a power cut. Write the measured figure into the program comments so the next person inherits it, and repeat the check when the seasons turn.
- A clock the panel or PLC keeps and you can set. Decide once which device owns time; one panel reading the PLC clock while another writes it shows the two arrangements side by side. Set the clock from the panel and re-check it at the daylight-saving changes, the job setting a PLC clock from an operator panel walks through.
A floor board that displays the time or a shift total inherits the clock that feeds it, so apply the same tolerance there; our shop-floor screens and andon-style boards cover that side of the installation. When you set a clock, note the correction next to the entries it affects, because an undocumented change scrambles the order of the history.
Recommendation: Keep the SP3 counter clock as your timestamp only if the week-long check, repeated in the hottest weeks, projects drift under 10 minutes a month and the counters survive a power cut; then document the measured figure and recheck each season. Above that line, as in the 17-minute example, timestamp from a clock you can set from the operator panel and resynchronize on a schedule, and prove the carry logic before trusting either source.
Questions
Why does a counter clock built on SP3 drift?
The special-relays appendix defines the pulse pattern, on 30 seconds and off 30 seconds, and nothing else. No accuracy class, temperature coefficient or drift limit is published for the timing source, so every counted pulse carries an unknown error. The counting chain adds its own faults: a double increment per cycle or an hour carry at a value other than 60 moves the clock faster than any oscillator. Pass the event and rollover checks first, then measure what remains.
How far off is 17 minutes a month after a full year?
17 x 12 = 204 minutes, so the timestamp runs about 3 hours and 24 minutes fast over a year. Entries logged in January and entries logged in December then disagree with real time by that much, enough to reorder a dispute over who entered when. Even a drift inside tolerance deserves the same projection so the yearly number is known.
Do the faster special-relay clocks make a better timestamp?
The same appendix lists SP4 as a 1-second clock, on 0.5 second and off 0.5 second, and SP5 as a 100 ms clock, on 50 ms. A faster pulse shortens the timestamp step, but it publishes no accuracy for those sources either, so the same week-long check and month projection decide the question.
What drift tolerance should an entry log use?
Set it from the consequence of an error. If 10 minutes a month is the most the record can absorb, that is 120 minutes a year (10 x 12). When a weekly check projects near the limit, run two more weeks before deciding, because a short sample turns a small reading error into a large monthly projection.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.