Vision sensor timestamp wrong: NTP time sync fixes it

A vision sensor that names its archive files from its own clock will put Monday's parts in a folder dated years ago, and nothing on the naming screen fixes it. Compact vision sensors and industrial code readers usually carry no battery-backed real-time clock, so the clock restarts from a fixed default at every power-up and counts seconds from there. This guide shows you how to confirm the reset with two power cycles, sync the device from an NTP server on your plant network, fall back to a host-side time command on older device software, and prove the result with one triggered image. The same checks apply whether the device writes images to an FTP server, streams results to a PLC, or both.

Why does a vision sensor save FTP images with a date years in the past?

Because the sensor has no battery-backed real-time clock: at each power-up its clock starts from a fixed default — often midnight on 1 January of a set year — and counts seconds from there, so the calendar in the filename stays wrong while the seconds advance normally.

The stamp in the filename comes from the device's internal clock, not from the FTP server or your PC. With no battery to hold the clock between sessions, the software starts it at a default moment and increments from there. That is why the minutes and seconds look plausible while the year is off by a wide margin: only the count since boot is real.

Two sensors powered on different days disagree with each other by exactly the gap between their boot dates. That signature separates this fault from a server fault, where every file shifts together. For the frame-level cousin of the problem, where timestamps inside the live stream freeze or jump instead of sitting in filenames, the same missing-clock-source logic applies, and camera image timestamps frozen or jumping: fix the clock source works through it.

A typical vision sensor running this kind of archive job:

Does the device clock survive a power cycle?

No: on a clock without RTC backup the reset happens at every power-up, so the same sensor lands on the same default date after each cold start, and two sensors switched on months apart show dates months apart.

The test costs two boots. Read the device clock immediately after power-up and write the value down, then power-cycle and read again the next morning. The same default date after both boots is a resetting clock.

A clock that holds time drifts instead. A plain crystal typically sits 20 to 50 ppm from its rated rate, so a device that has run 30 days (2,592,000 s) drifts 2,592,000 s × 20 ppm = 51.84 s at the good end and 129.6 s at the other. A month-old date within a couple of minutes of true time means the clock holds; a default date means no amount of hand setting survives the next shutdown, which is why setting the time once is not a fix.

The same boot-time readback separates a reset from a rollover elsewhere too: IMU timestamp jumps: reset, rollover or conversion fault applies it to inertial units.

Is the device clock wrong, or the FTP server?

Most often the device: sort the FTP folder by the server's file-modified time and compare it with the dates in the filenames — a server clock problem shifts both, while a device clock problem shifts only the names.

Work down these causes in order; the first explains most sightings.

1. Device clock never synced. Read the clock right after a cold start; a default year proves it. The fixes below cover this cause.
2. Timezone offset after a good sync. Filenames land exactly one UTC offset away from local time — 8 h at UTC+8, 5 h 30 min at UTC+5:30 — or exactly one hour across a daylight-saving change. The clock is right; the names are UTC.
3. Server clock wrong. Compare the FTP server's own date with a reference and put the server on NTP too; a wrong server shifts archive pruning and dashboards as well.
4. Stale naming template. A job edited long ago can carry a date captured at save time rather than read per image. Re-save the job and retrigger once.

How does NTP time sync fix the timestamp?

Point the device's NTP client at a server on your network: at startup and then on a poll cycle of 64 s to 1024 s, it requests time over UDP port 123 and steers its clock to the true date, typically landing within milliseconds on a local network.

Three things must be in place: device software that exposes the client, a reachable server address, and UDP port 123 open from the device to that server. Recent releases across several vision-sensor and code-reader lines have added manual date and time settings plus NTP sync, where older builds only offered functions that read or write the time through a connected host. The release notes listing those features are your evidence the setting now exists; take updates from the manufacturer or its distributors.

What does one NTP exchange tell you?

The four timestamps of one request-and-reply pair give the clock offset and the path delay directly:

Worked example: a device sends its request at t0 = 100.000 s on its own (wrong) clock; the server receives it at t1 = 86,400,100.050 s and replies at t2 = 86,400,100.060 s; the device logs the reply at t3 = 100.030 s. Then θ = ((86,400,100.050 − 100.000) + (86,400,100.060 − 100.030)) / 2 = 86,400,000.040 s, and 86,400,000.040 s / 86,400 s per day = 1000 days, so this clock is 1000 days behind.

The path delay is δ = (100.030 − 100.000) − (86,400,100.060 − 86,400,100.050) = 0.030 s − 0.010 s = 0.020 s, a 20 ms round trip. After correction, filenames move forward 1000 days and the residual error is the server's own accuracy, not the network path.

What if the device software has no date, time or NTP setting?

Three fallbacks exist: upgrade the device software to a release that adds manual date and time plus NTP settings, write the host's clock into the device over its own communication functions at startup, or stop trusting the clock and name images from a trigger counter your host logs.

Upgrade first if a release offers it. Release notes are the evidence: a line whose current software lists date/time settings and NTP sync among new features turns the workarounds below into checkboxes. Take software only from the manufacturer or its distributors, and power-cycle after the update so the new settings apply from boot.

Set the clock from the host. Most device SDKs and ASCII command sets include a time-write call. Run it as soon as the connection opens, then once per shift, and prove the write with a readback:

# Pseudocode; these names are ours - match the time-set and time-read calls in your device SDK.
t = now_utc # host clock, itself synced from the NTP server
device.set_time(t) # write host time into the device clock
assert abs(device.read_time - t) <= 1 # readback proves the write landed, in seconds

Or stop trusting the clock. Name each file from a part ID and trigger counter, and log the pair on the host. Save a triggered image to disk with a numbered filename shows the naming pattern, and camera timestamp clock rollover and monotonic time mapping covers mapping a free-running counter back onto wall-clock time when someone does need a date.

A code reader that files an image per part lives or dies by the filename:

Where should the time come from on a plant network?

From one source the whole cell shares: a GPS- or radio-disciplined NTP server feeding the plant network with every device as its client, or, on an isolated cell network, an always-on PC or edge box running an NTP service as the local reference.

A disciplined server holds itself within microseconds of UTC. Clients on the same switch settle to single-digit milliseconds; a routed plant network adds tens of milliseconds. On an isolated cell, a local reference keeps every device agreeing with every other, which is what matching NG images to PLC events needs, even though the cell is then not traceable to national time.

Keep the PLC on the same source. If results reach the controller as OK/NG signals, vision sensor OK/NG output to a PLC: wiring it so results arrive covers that link, and one shared clock keeps the image archive and the PLC's event log in one order.

Everything else on the cell network needs the same three decisions — server address, upstream source, poll interval — and an NTP time-sync setup for an industrial edge device shows those settings end to end.

Test every device type once instead of trusting a good first result. At least one HMI panel family has shipped with a time-sync fault that silently ignores a working server whose address falls outside a configured IP range — see IP-range time-sync bug of one HMI panel family.

How do I prove the fix holds on the line?

Trigger one image and make three clocks agree within a second: the stamp in the filename, the FTP server's file-modified time, and the host log line for the same trigger; once NTP settles, filename and server times differ by single-digit milliseconds on the same switch.

1. Set the clock source and power-cycle. Read the device clock right after boot; the default year must be gone.
2. Trigger one image and confirm it reaches the server. If nothing lands, clear the classics first: device not set online, a firewall on the receiving PC, or missing write rights on the target folder.
3. Put the three times side by side. Under one second apart passes; single-digit milliseconds is typical across one switch.
4. Shut the cell down for a weekend and repeat on Monday morning. Boot-time sync is the failure mode only a cold start exposes.
5. Leave a watchdog behind: alarm when the device reports a year other than the current one, and re-check after any software update or network change.

If the archive job also ships NG images to an HMI for review, push NG images from a vision system to an HMI over FTP builds the transfer side; those filenames inherit whatever this clock now reads.

When does a wrong sensor clock actually matter?

It matters whenever a person or program reads the time later: traceability filenames, date-based archive pruning, matching NG images to PLC or MES events, and audit records. It does not matter when images are consumed live and overwritten, because nothing ever reads the stamp.

Decide per case:

• Regulated traceability (automotive, food, pharma): the filename is the record, so a wrong date breaks it. NTP from the plant source is mandatory.
• Event correlation: you need the NG image beside the PLC event that caused it. One shared source, or counter naming with a host-side log, is enough.
• Live-only viewing: the operator watches rejects as they occur and nothing reads the time later. Spend nothing here.

If you are standardising devices for a new cell, on-device inspection with FTP archiving looks like this:

Line up the rest of the station in the camera finder, browse smart cameras and fixed code readers, or walk the whole chain in the configurator starting at the camera step. The systems topic page collects the other clock, trigger and integration guides, and contact us with device questions before you order.