OEE Timestamps and Clock Sync: Why Stop Times Drift

Key takeaways

• Stamp at the source: use the PLC or gateway clock at the moment the state changes.
• One time source for PLCs, gateways, SCADA, the historian, cameras and tablets.
• Keep the raw edge, and filter flicker as a separate step.
• Count over intervals instead of sampling the speed at one instant.
• Store times in UTC and convert them for shifts and plants.

An OEE system is a stopwatch. When its clocks disagree, the stops it records start late, end early or land in the wrong shift. Two habits fix most of it: stamp each event where it happens, and keep every clock on one time server.

Fabrico, OEE and light MES software with AI cameras, puts PLC data, sensor signals and camera events on one timeline of stops. That timeline is only as true as the clocks behind it. Clock sync is a plant setting as much as a software one.

Why do stop times drift?

There are four common causes, and most plants have at least two of them.

• Clock drift. A controller with no time sync slowly runs fast or slow. Practitioner guides quote about 2 seconds a day for a modern controller. Check the datasheet for yours.
• Arrival time. If the database stamps events when they arrive, any network delay or buffer moves the stop.
• Filters on the signal. A short on-delay timer stops a chattering run signal from creating fake stops. But if it is applied before stamping, each stop start shifts by the filter time.
• Sampling the speed. A speed read at fixed moments can catch a zero by chance. That one reading then looks like a stop across the whole interval.

What is the right timestamp for a stop?

The right timestamp for a stop is the moment the machine state changed. It comes from the clock of the device that saw the change: the PLC or the gateway next to it.

Everything after that point can be late without harm. The event can wait in a buffer, cross a slow link or reach the server an hour later. It still carries its true time.

How do you set up clock sync for OEE?

1. Pick one time source. Use the plant's own NTP server, in the OT zone or the DMZ, synced to a trusted source upstream.
2. Point every device at it. PLCs, gateways, SCADA, the historian, cameras and tablets.
3. Alarm on drift. Flag any device whose clock moves beyond an agreed limit.
4. Check after a power cut or a battery change, when controller clocks often reset.
5. Plan time zones. Store UTC, show local time, and decide how the night shift that loses or gains an hour is counted.

Your gateway's firewall rules need to allow that time server. Our guide to the OEE time model explains how planned time, run time and stops fit together.

Worked example: two weeks without time sync

Sample line (illustrative numbers, not a customer). A filler has an ideal cycle of 12 seconds. The plant counts any pause over twice the ideal, 24 seconds, as a stop. The camera and the gateway use the plant's time server. The filler's PLC has no time sync and runs 2 seconds a day fast.

The arithmetic is simple: 2 seconds a day x 12 days = 24 seconds, the same as the stop cutoff. From then on, a 24 second jam the camera filmed from 09:00:00 to 09:00:24 shows in the PLC data from 09:00:24 to 09:00:48. The two records never touch.

After a month the offset is 60 seconds. A stop that started at 05:59:30 is booked to the next shift. The operator who confirms it never saw it happen.

With the PLC on the time server too, all three sources agree, and the clip matches the stop it explains.

Which other habits keep stop times true?

• Keep the raw edge. Store the moment the signal changed, then apply the filter as a separate step.
• Count, do not sample. Use the count over each interval instead of the speed at one moment.
• Keep seconds. Never round stop times to the minute in the database.
• Keep the history. If someone corrects a stop time, store the original next to the new one.

Short stops suffer most from bad timing, so read our guide to micro stops next. If you also run a historian, historian vs database explains where time series data should live.

Who should own time in the plant?

Someone has to, or nobody will. In most plants the OT team owns the time server and the device settings. IT provides the trusted source upstream and keeps the firewall rule open. The OEE vendor should show each device's offset, so drift is seen before it spoils a week of data.

Where does Fabrico fit?

Fabrico is a computer vision enabled Manufacturing Performance Platform. It is the OEE and downtime layer of a light MES, with AI cameras on stops.

• Automatic downtime logging from the machine signal, stop by stop.
• A camera clip as evidence for a stop, on the same timeline as the signal.
• The operator confirms the reason in one tap, close to the moment it happened.
• OEE live by line and shift, with every loss priced in money.

Time settings for your devices are part of the setup Fabrico's technical team agrees with your plant. See how live numbers work in our guide to real-time OEE. There is no free plan and there are no tiers: each plant gets a quote.

Frequently asked questions

How do you synchronize PLC time?

Point the PLC at the plant's NTP time server if it has a time client. Older controllers can often take their time from SCADA or a gateway instead. Then check the offset now and then, and after every power cut or battery change, because controller clocks can reset.

Why don't my OEE stops line up with my camera clips?

Usually because the PLC and the camera run on different clocks, or because one system stamps events when they arrive instead of when they happen. Put every device on one time server and stamp each event at its source. Then a stop and its clip cover the same seconds.

Should OEE timestamps be in UTC or local time?

Store them in UTC and show them in local time. UTC never jumps, so the night the clocks change does not create a missing or doubled hour. It also lets a group compare plants in different time zones without converting anything by hand.

How exact do OEE timestamps need to be?

Much more exact than your stop cutoff. If a pause over 24 seconds counts as a stop, a clock that is 10 seconds off already blurs the short stops. Aim for clocks that agree within a few seconds, and check them with an alarm rather than by hand.

What is debounce in downtime logging?

It is a short delay that ignores a run signal flickering on and off, so the flicker is not logged as many tiny stops. Apply it as a separate step after you store the raw signal. Otherwise each stop you record starts a little later than it really did.

Check your line's timeline in a demo

Bring one shift's stop log and a few camera clips. We will show how the stops and clips line up once the clocks agree.

Request a demo · Contact us