A one-hour error around SUN_TIME can look like a UTC-to-local-time problem, but the supplied case also contains a separate data-unit fault. In PC Worx, date and time values represented as UDINT can be wired together even when their meanings differ: TOD is milliseconds since midnight, while DT/DATE_TIME is seconds since 1 January 1970. Resolve that factor-of-1000 mismatch before evaluating the 60-minute local-time offset.
Separate the time-zone issue from the unit mismatch
The available documentation is described inconsistently: one description calls the SUN_TIME result local time, while another calls it world time. Do not select either interpretation silently. First identify the actual output representation, then compare it with a known UTC value and a known local clock value on the same date.
| Value | Meaning in this case | Unit |
|---|---|---|
TOD |
Elapsed time since 00:00:00 | Milliseconds |
DT/DATE_TIME
|
Elapsed time since 1 January 1970 | Seconds |
A direct connection can therefore be numerically accepted while remaining semantically invalid. The relevant scale relationship is:
TOD_milliseconds = seconds_since_midnight × 1000
seconds_since_midnight = TOD_milliseconds ÷ 1000Correct the conversion path
- Trace the
SUN_TIMEoutput and record whether the downstream block expects milliseconds since midnight or seconds from the epoch. - Normalize the source and destination to compatible units. Apply the factor of 1000 only when converting between seconds and milliseconds; it is not a time-zone correction.
- After the units and time basis match, apply the configured 60-minute offset through the existing UTC-to-local-time conversion.
- Compare the result against both UTC and local time. This determines whether the disputed
SUN_TIMEoutput is actually UTC or already local time.
Why PC Worx accepts the invalid connection
In the reported PC Worx environment, the date and time representations are consolidated as UDINT. That removes type-level protection: two connectors can have the same storage type while representing different epochs or units. Treat every time connection as a contract containing the epoch, unit, and time basis—not merely as a compatible integer.
The case used an ILC131, PC Worx Express 6.30, and OSCAT Basic 3.33. These identifiers describe the reported setup; they do not establish that every version has identical time handling.
Limit execution to the required update
The solar-time result in this application needs recalculation only when the day changes. Store the previous YEAR_DAY, compare it with the current value, execute the solar-time function block when they differ, and then store the current value. A timer is unnecessary when the day-change comparison already supplies the trigger.
The reported PLC cycle time increased from 5 ms to 15 ms after the function block was added. That observation suggests checking whether the block is enabled every scan, but it does not by itself prove the cause. Monitor the enable condition and cycle time together, then verify that execution occurs once at the day transition.
FAQ
Why does UTC_TO_LTIME still give the wrong result with a 60-minute offset?
Verify the input representation first. A 60-minute offset cannot correct a connection where one value is expressed in seconds and the other in milliseconds.
What is the difference between TOD and DATE_TIME in this PC Worx case?
TOD represents milliseconds since 00:00:00, while DT/DATE_TIME represents seconds since 1 January 1970. Converting their numeric scales requires multiplication or division by 1000, depending on direction.
How can I run the SUN_TIME calculation only once per day?
Compare the current YEAR_DAY with a stored previous value. Execute the calculation and update the stored value only when the two values differ.
