Set the panel's clock from the PLC so panel and controller timestamps agree. The panel project takes an external clock source pointed at the PLC's clock registers, and a one-scan trigger handles time changes from an entry screen. A sample-count trend axis converts to elapsed time with T_span = N_samples × T_sample, so 600 samples at 1 second read as a 10-minute window.
A touch panel whose clock can only be stepped one hour at a time leaves the line with two bad options: a laptop trip for every correction, or a panel clock that drifts away from the controller's. There is a third way, and it is the one to keep. The panel project accepts an external clock source pointed at the controller's clock registers, so the cell has one time and both timestamps agree. The corner-touch setup screen stays useful as a one-minute restore on a spare panel. The trend axis is a separate problem: it counts samples, and no menu relabels it, but a sample interval turns counts back into time with one multiplication. This article gives both fixes, the arithmetic for the axis, and the checks that show the chain holds through a power cycle.
How do you set the clock without connecting a PC?
Touch the upper-left and lower-left corners of the screen together and hold until the setup screen opens; it sets hours, minutes, seconds and the date in about a minute, with no laptop, cable or project download.
Hold both touches until the setup screen appears. It carries contrast, system settings and the time and date entry. Set hours, minutes, seconds and the calendar date, leave the other entries alone, and back out. A wrong contrast value on that screen leaves the display hard to read, so touch nothing else while you are in there. Confirm that a clock or date object on a run screen shows the new time before you close up.
Treat this as the restore for a panel in hand, not the setup you keep. The two-corner gesture is open to anyone who learns it, and the same screen reaches system settings. It returns a correct clock in a minute on a night-shift call; the sections below remove the reason to open it again.
Why do the panel clock and the PLC clock disagree?
They disagree because each keeps time on its own crystal: a typical crystal is rated ±20 ppm, and 20 ppm × 86,400 s = 1.7 s per day of drift, about a minute a month, while daylight saving moves one clock a whole hour and leaves the other behind.
Both devices count seconds from their own crystal, and no two crystals sit exactly on nominal frequency, so the gap grows with nothing broken. The panel and the controller then timestamp the same event minutes apart, and afterwards nobody can say which stamp was right. The gap also jumps a whole hour at each daylight saving change, when someone adjusts one clock and misses the other.
Read the offset before you fix anything. Whole hours point to a daylight saving shift on one clock. Minutes or seconds point to drift, or to a clock that was never set at minute resolution. One master clock closes both cases: one drift rate to watch, and one daylight saving decision a year.
How do you make the PLC clock the panel's clock?
In the panel project, select the external clock option and enter the controller memory addresses that hold the clock; the panel software's synchronization function then matches date, time and time zone with the connected controller.
The clock source changes from the panel's internal clock to the external source, and the external source takes the controller addresses that hold year, month, day, hour, minute and second. Copy the addresses and their order from the clock memory map in the controller manual. Length and field order vary by family; one PLC manual documents its set-clock function at 4 words, so read the map for your controller instead of guessing the order.
Panel programming software documents this as clock synchronization: it matches the date and time and sets the time zone between the panel, the connected controller and any external clock source, so the panel follows the master from boot with nothing else to set.
Pick the master deliberately. A controller with no battery-backed clock can still hold plant time where its runtime reads the host system's time; read system time without an RTC covers that pattern.
How do you enter a new time once the PLC holds the clock?
Build a supervisor-level entry screen that writes the new date and time into spare registers, then add a controller routine that copies those registers into the clock with the controller's set-clock instruction, fired by an Apply bit that is cleared after one scan.
- Build an entry screen with numeric entry fields for date and time, writing to spare registers. Keep the clock registers themselves outside the write range.
- Add a controller routine that copies those spare registers into the clock with the controller's set-clock instruction.
- Fire the copy from a momentary bit set by an Apply button you add on the entry screen, and clear the bit after one scan so the clock is not rewritten every scan. A bit that lives a single scan is easy to miss on a running system; catch a status bit that is high for one scan shows the catching pattern.
- Put the entry page behind the panel's screen-level security. It now sets plant time for every device that reads the controller clock, so it is not an operator page.
Most controller families document clock writes in RUN as well as STOP, so you correct the time with the line producing. That is one more reason the entry screen beats the laptop.
What does the trend X-axis actually show?
It shows sample numbers, not clock time; there is no documented time-format setting for that axis, so you read the sample interval from the trend's sampling setting and label the elapsed span yourself with static text.
The marks count samples back from the newest one, so a fixed sample interval converts any mark into elapsed time:
T_at_mark = mark number × T_sample, the time back from the newest sampleT_span = samples displayed × T_sample, the time across the full width
T_sample is the sampling interval in seconds, read from the trend object's sampling setting in the panel project; the samples-displayed count sits in the same properties. Write the result as static text beside the chart in the form "full width = 10 min". If the interval changes in a later edit, change the text in the same edit; a stale span label sends operators backwards.
The same elapsed-time labeling is how you show the full test duration on a live trend chart.
Example: what time span does a 600-sample trend at 1 s per sample cover?
At 1 s per sample the full width covers 600 samples × 1 s = 600 s, which is 10 minutes, and the tick labeled 150 sits 150 s, or 2 min 30 s, back from the newest sample at the right edge.
A packaging line panel trends line speed with 600 samples on screen and a sampling interval of 1 s per sample in the trend properties. The arithmetic:
T_span = 600 samples × 1 s/sample = 600 s = 10 minT_at_mark = 150 samples × 1 s/sample = 150 s = 2 min 30 s
Static text beside the chart reads "full width = 10 min". An operator looking at the tick labeled 150 knows that point on the trace is 2 min 30 s old. Whoever needs absolute time reads it from the clock object next to the chart: the newest sample sits at the right edge of the scrolling trend, and the clock says when that edge is. The one assumption is the constant interval, which is what the sampling setting delivers. Widen the interval later to 2 s and the span doubles to 20 min, so the static text changes to 20 min in the same edit.
Which symptom points to which cause?
Match the symptom before touching anything: a whole-hour offset points to daylight saving on one clock, minutes of offset points to drift or an unset clock, and nonsense after a clock write points to wrong addresses in the external-clock setting.
| What you see | What it points to | What to do |
|---|---|---|
| Panel time off by whole hours | Daylight saving moved one clock | Set the master; the panel follows once it reads controller time |
| Panel time off by minutes or seconds | Drift, or a clock never set at minute resolution | Setup-screen restore now; move the master to the controller |
| Panel and controller timestamps disagree | Two clocks running | External clock source pointed at the controller's clock registers |
| Time turns to nonsense after an Apply | Wrong addresses or field order in the clock map | Recheck the addresses and field order against the controller manual |
| Trend X-axis counts samples | The axis is sample numbers | Label the span with T_span text and add a clock object |
| Display hard to read after the setup screen | Contrast value changed on that screen | Reopen the setup screen and restore the contrast |
Recommendation: point the panel's external clock source at the controller clock on every panel you commission, keep the two-corner setup screen as the restore for a spare panel, and label every trend with its calculated span before it goes on the wall.
How do you verify the clock chain end to end?
Verify from the panel outward: after an Apply the clock object should show the new time within a second or two, and after a panel power cycle it should come back on PLC time with no stale internal value.
- Apply a new time from the entry screen and confirm the controller's clock registers hold it; read them back in the controller programming software.
- Confirm the panel clock object shows the same time within a second or two.
- Cycle panel power. It should come back on controller time, with no stale internal value.
- Power-cycle the controller, or switch it to program mode and back. The clock should keep running and the panel should follow it.
- Watch both against a reference time over a full shift. A chain that holds within a couple of seconds across the shift holds.
A chain that passes all five leaves one clock in the cell, one daylight saving decision a year, and a trend whose span label tells the truth.
Questions
Do I still have to change the clock for daylight saving?
Once, at the master. Set the controller clock on the change dates your region uses and the panel follows, because it displays and stamps with controller time. Several controller vendors publish example programs that make this shift automatic on the set dates; load one in the controller and the twice-yearly visit disappears. The panel needs nothing, since it reads the controller's clock.
Can the plant network hand out the time instead of the PLC?
Yes, on systems that support it. Where the controller and the panel can both take time from a network time service (NTP) on the plant network, the server becomes the single master, and every device that reads it, line PCs included, shares one time. Where the network runs no time service, keep the controller as master; the one-clock principle is identical.
What if the controller loses time over a shutdown?
Most controllers back their real-time clock with a battery or capacitor, so the clock survives power-off. If the controller resets to a default date after a weekend shutdown, the clock cell is the suspect: replace it per the controller manual, set the time again, and repeat the power-cycle check in this article. The panel needs nothing new, because it comes back on controller time either way.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.