LBR iiwa System Clock: Set in Windows, Not Sunrise UI

Before anything else, confirm where the timestamp comes from. On a Sunrise Cabinet the smartPAD interface handles station setup, safety configuration, application selection and diagnostics — there is no date/time field anywhere in it, and no amount of searching the application manuals will produce one. The controller PC runs a Windows operating system underneath the real-time motion layer, and that OS clock is the single source for every timestamp the robot emits: diagnostic log entries, project synchronization records, file timestamps in the project directory, and anything a RoboticsAPI application writes using system time. Fix it at the Windows level and everything above it follows.

Reading the Offset Before Touching the Clock

A correct date with a wrong time is diagnostic information, not a random fault. The real-time clock is counting properly — otherwise the date would have drifted too — so the error is almost always in how the OS renders that count. Measure the error against a known-good reference (phone, plant clock, an NTP-synced PC) and classify it before you open any dialog.

Do not move on until you know which row you are in. Correcting a time-zone offset by dragging the clock hands leaves the machine wrong again at the next DST transition or the next successful time sync.

Access Paths Compared

Four routes reach the same clock. They differ in what access they demand and in whether the correction survives a reboot and a season change.

Use RDP. It is the fastest path on a cell that is already networked, it lets you fix the time zone and the clock in one session, and it puts you on the same desktop where the time service is configured. Reserve the BIOS route for the case where the hardware clock itself is wrong — setting it there and then letting Windows own the offset avoids a double correction.

Procedure: RDP Session and Clock Set

Prerequisites: robot in a safe state with the application stopped, and an account with local administrator rights on the controller. Changing the system time is a privileged operation, and a backwards time jump while an application is running corrupts the ordering of your own log entries.

1. Confirm the controller address. Use the same IP that Sunrise Workbench targets for project synchronization — if Workbench or WorkVisual reaches the controller, the network path for RDP already exists. Neither tool carries a clock function, so the only thing you need from them is that address.
2. Verify reachability: ping <controller-ip>, then open a Remote Desktop session to it. A refused connection points at the RDP service or a firewall rule on TCP 3389, not at the robot.
3. Log in with the administrator account and open an elevated command prompt.
4. Read the current state before changing anything: date /t, time /t, tzutil /g, and w32tm /query /source. Record all four. The source query tells you immediately whether something else will overwrite your manual set.
5. Set the time zone first. List valid identifiers with tzutil /l, then apply the site zone with tzutil /s "<TimeZoneId>". Re-check with tzutil /g.
6. Re-read the clock. If the zone was the whole problem, the time is now correct and you are done with the manual portion — skip the next step.
7. Close the session cleanly by logging off rather than disconnecting, so no orphaned session holds the desktop.

Making the Correction Permanent

A hand-set clock on a free-running RTC drifts, and on a controller that already has a time source it gets pulled back at the next sync interval. That is why step 4 reads w32tm /query /source before anything else. If the source is a domain controller or an existing peer that is itself wrong, fix the upstream server — the robot will follow it regardless of what you type locally.

To point the controller at a plant time server from the elevated prompt:

w32tm /config /manualpeerlist:"<ntp-server>" /syncfromflags:manual /update
net stop w32time
net start w32time
w32tm /resync

Recurring pitfalls on this class of controller:

• Editing the network adapter while you are in Windows. The KLI configuration belongs to the Sunrise project's station setup. Changing the Windows adapter directly puts the project and the machine out of step and breaks synchronization. Set the clock and nothing else.
• Correcting DST by hand every spring and autumn. If you are doing this twice a year, the time zone identifier is wrong. Fix it once with tzutil.
• Setting the clock with an application running. Stop it. Timers, cycle measurements and your own logged timestamps all read the same OS clock you are about to move.
• Assuming a reboot preserves the change. It preserves it only if the RTC battery holds charge. A controller that reverts on every power-up is telling you about hardware, not configuration.
• Trusting UDP 123 is open. Plant firewalls and segmented cell networks block NTP routinely; w32tm /resync failing with no peer is the symptom.

Verification

Four checks, in order. Each one has to pass before the next is meaningful.

1. In the RDP session run tzutil /g and confirm the returned identifier is the site zone, then date /t and time /t against your reference clock. Tolerance: seconds, not minutes.
2. If NTP is configured, run w32tm /query /status and confirm a named source, a recent successful sync time and a small clock offset. A status showing "Local CMOS Clock" means the configuration did not take.
3. Generate a fresh entry in the controller's diagnostic log — stop and start an application, or trigger any logged event — and read the timestamp on the smartPAD. This proves the Sunrise layer picked up the corrected OS clock rather than a cached offset.
4. Power-cycle the controller, let it boot fully, then re-read the time on the smartPAD without opening an RDP session. Matching wall-clock time after a cold start is the only result that confirms the hardware clock, the time zone and the time service all agree.

FAQ