Implementing Daylight Saving Time Logic in Mitsubishi GX Works 2

Overview

Industrial controllers running GX Works 2 project files must correctly handle the twice-yearly local time transitions imposed by daylight saving time (DST). Unlike a desktop operating system that updates the user-visible clock via a service, a Mitsubishi MELSEC FX or Q-series CPU updates its real-time clock (RTC) only when application logic tells it to, or when an external time source pushes a corrected value via SNTP. This reference documents a robust implementation pattern that uses an internal DST flag, the built-in RTC device (D8013–D8019 on FX, S.M registers on Q), and a daily SNTP resync to keep two redundant PLCs within one second of each other across both the spring-forward and fall-back transitions.

The logic below assumes that the controller is located in a region observing the United States DST rule: clocks advance one hour at 02:00 local on the second Sunday of March and retard one hour at 02:00 local on the first Sunday of November. The same algorithm scales to any jurisdiction by editing the month/day comparison constants and the SNTP UTC offset.

Prerequisites

1. GX Works 2 version 1.590 or later installed on the engineering workstation (DST-aware SNTP FB library shipped from 1.591 onward).
2. FX5U/FX5UC, FX3U/FX3UC, or Q-series (Q03UDE, Q04UDEH, Q06UDEH, or later) CPU with built-in Ethernet or an FX3U-ENET-ADP / QJ71E71-100 Ethernet module.
3. An SNTP/NTP server reachable on the plant VLAN. Stratum 2 or lower is recommended for sub-second controller-to-controller skew.
4. Knowledge of the CPU scan time (D8010 on FX, SM501/SM502 on Q) and the RTC device group used for date comparison.
5. GX Works 2 simulator (GX Works 2 -> Debug -> Simulator) for offline verification before live download.

DST Transition Rules Reference Table

GX Works 2 RTC and Time Device Map

On the FX platform the RTC is buffered by a large capacitor (FX3U) or a battery (FX3UC), so the clock survives a power loss of up to ten days depending on ambient temperature. The Q-series uses the BR-2032 battery (Q-BAT), which is rated for approximately five years of retention at 25 °C. SNTP is still preferred over relying solely on these retention windows, because the RTC drifts noticeably after a CPU restart if it was halted for more than a few hours.

Core Logic Implementation

The pattern below is the structure used in production deployments where two redundant controllers (one Q-series, one FX5U) are required to agree on the time within one second after the DST transition.

Step 1 — Calculate the transition Sunday

Because the second Sunday of March and the first Sunday of November are the only irregular date values, derive them with arithmetic rather than hard-coding a calendar table. The algorithm below produces the day-of-month of the desired Sunday given month and year.

DST_SUNDAY_DAY = 8 - WEEKDAY(year, month, 1)   ; for "second Sunday"
DST_SUNDAY_DAY = 1 + (7 - WEEKDAY(year, month, 1)) MOD 7   ; for "first Sunday"

GX Works 2 does not ship a built-in weekday calculator for arbitrary dates; the recommended implementation is to count Sundays forward from day 1 with a one-second task that increments until D8016 (day) equals a Sunday and the day counter equals the target offset.

Step 2 — DST flag evaluation (latch on, latch off)

Use two rungs to set and reset a memory bit that remains true for the entire DST window. Constants below are for the US rule.

; SET M_DST_ON
LD>= D8017 K3            ; month >= March
LD<= D8017 K10           ; month <= October
ANB                       ; AND block
OR
LD= D8017 K3              ; March
AND>= D8016 K8            ; day >= 8 (second Sunday earliest)
OR
LD= D8017 K11             ; November
AND<  D8016 K7             ; day < 7 (before first Sunday)
OUT M_DST_ON

Step 3 — Apply the one-hour offset

The naive approach is to subtract 3600 s from a UNIX-style counter when the flag is high. GX Works 2 has no native UNIX epoch device, so use a seconds-since-midnight counter combined with the day-of-year value.

; Convert local RTC to seconds-of-day
MUL D8015 K3600 D200
MUL D8014 K60   D201
ADD D200 D201   D_SECONDS_LOCAL

; Apply DST offset
LD M_DST_ON
ADD D_SECONDS_LOCAL K3600 D_SECONDS_ADJUSTED

INCP vs DECP Direction Handling

A common defect observed in field implementations is using DECP (decrement pulse) when the local convention is to advance the clock in spring. The Mitsubishi instruction set treats both as signed 16-bit operations:

If you keep a single boolean M_DST_NEXT_DIR that toggles in March (set INCP) and in November (set DECP), the rest of the ladder becomes symmetric and the M11 intermediate bit shown in early drafts of the algorithm becomes unnecessary.

SNTP Synchronization Strategy

Two PLCs on the same shop floor typically drift by 0.5–2.0 seconds per day from one another because their internal oscillators are not temperature-compensated. The standard field remedy is to schedule an SNTP read once per 24 hours at 02:00 local — deliberately placed inside the DST window so that any drift induced by the manual one-hour correction is corrected two minutes later by the SNTP write.

The 2-minute gap between the manual offset and the SNTP write is intentional: it gives the ladder logic time to settle before the network read returns, and it prevents a "ping-pong" condition where the manual adjustment writes 03:00:02, the SNTP read returns 02:00:02 UTC (which is 03:00:02 standard), and the controller concludes that no further action is required.

Edge Cases

PLC in STOP Mode at the Transition Point

This is the most cited failure mode for the simple flag-based algorithm. If the CPU is stopped at 01:59:55 on the second Sunday of March and restarted at 02:05:00, the ladder never executed the INCP because the rising-edge trigger fired while scan was halted. When scan resumes, the RTC reads 02:05:00 local standard, but the rest of the plant has already moved to 03:05:00 DST. There is no general remedy that does not involve either:

1. An external orchestrator that writes the corrected time on controller startup, or
2. A periodic background task (100 ms or longer) that compares the controller's notion of the current minute to a stored last-known-correct minute, and applies the offset whenever the difference is exactly 3599 or 3601 seconds.

Power Loss Crossing the Transition

If power is removed at 01:30 on the spring-forward Sunday and restored at 04:00, the FX capacitor holds the RTC at 01:30 (standard) but wall clock is 05:00 DST. On Q-series with a healthy battery, the clock reads 01:30 but DST flag is false. Both cases are resolved by the daily 02:00 SNTP write — provided the SNTP server is itself UTC-anchored and is not affected by the same controller. Never point both redundant PLCs at each other for SNTP; point both at the same upstream NTP source.

Monotonic Time Assumption

The simple algorithm shown above allows time to jump backward by one hour in November. If downstream consumers require strictly increasing timestamps, maintain a parallel D_MONOTONIC 32-bit counter that increments once per second on the rising edge of M501 (1-s clock) and is never decremented. Use this counter for event stamping; use the DST-adjusted RTC for operator display.

Q-Series vs FX-Series Considerations

FX-series programs typically omit explicit SNTP blocks because the older FX3U does not have on-board Ethernet and the FX3U-ENET-ADP requires hand-rolled SNTP packet construction. For these older CPUs, schedule the master to write the corrected time as a one-shot DATERD/DATEWR operation once per day.

Verification and Testing Procedures

1. In GX Works 2 open the project, select Debug -> Simulator, then start simulation.
2. Use Online -> Set Time to manually push the RTC to 01:59:55 on the second Sunday of March of the current year. Confirm via Watch window that M_DST_ON is false.
3. Step the simulator one scan at a time and verify that exactly at 02:00:00 the INCP triggers and the hour device reads 03:00:00. Confirm M_DST_ON transitions to true.
4. Repeat with the RTC set to 01:59:55 on the first Sunday of November; verify that the DECP triggers and the hour reads 01:00:00 (i.e., 02:00 local becomes 01:00 standard) and M_DST_ON clears to false.
5. Change the PC clock in Windows to a date inside the DST window (April 15, October 15) and confirm M_DST_ON remains true; change to January 15 or July 15 and confirm M_DST_ON stays false.
6. Download to the live CPU and observe the SNTP read at 02:00 — verify in the Ethernet diagnostic buffer (FX5: buffer memory 200–299; Q: buffer memory 0–99 of the Ethernet module) that the read succeeded and that the corrected time matches the SNTP server's view of UTC within ±1 second.
7. Power-cycle the controller between 01:55 and 02:05 on a transition day to validate the SNTP-correction-on-restart behaviour.

Troubleshooting Matrix

Best Practices and Field Notes

• Always store the DST month/day constants in named registers (for example D_DST_M_SPRING=3, D_DST_D_SPRING_MIN=8) so the algorithm is region-agnostic without recompilation.
• Use SM402 (FX) or SM402 (Q) — the one-shot-on-RUN contact — to clear M_DST_ADJUSTED so the SNTP write does not double-adjust on startup.
• On Q-series with redundant CPUs (QnPRH), place the DST logic on the control CPU only and let the standby CPU inherit via tracking transfer; do not run the SNTP read on both CPUs simultaneously.
• Log the last successful DST transition to a retentive register (D8000–D8004 on FX, D0–D4 with battery-backed latch range on Q) so a maintenance engineer can confirm at a glance which transition was the last one processed.
• Prefer the SNTP function block approach over raw ladder construction of NTP packets; the Q-series UDP instruction set is not friendly to 48-byte NTP v4 payloads and silent failures are common.
• Document the assumed DST rule in the project header so the next engineer inherits the assumption explicitly rather than reverse-engineering the constants.

FAQ