Time Synchronization and Timestamp Analysis for B&R Diagnostics

Time synchronization is the single most critical prerequisite for meaningful diagnostics on any PLC system. On a B&R X20CP1584 system, every alarm, every log entry, every I/O error, and every drive fault carries a timestamp. If those timestamps are not trustworthy, the entire diagnostic chain collapses. This document covers NTP/SNTP configuration on B&R, ensuring accurate timestamps across PLC, IO cards, drives, and HMIs, how to correlate events across multiple devices using timestamps, and how to use time-based analysis to find the root cause of intermittent faults. Cross-references: alarm-logging.md for alarm timestamp formats, system-variables.md for time-related system variables, and network-architecture.md for network timing implications.

1. Overview

Why Time Sync Matters for Diagnostics

• Event correlation: When a drive faults, the PLC logs a power bus warning, and the HMI shows a communication timeout, you need to know whether these events happened within milliseconds of each other (same root cause) or minutes apart (coincidence).
• Root cause analysis: Intermittent faults often leave breadcrumbs across multiple subsystems. Without synchronized clocks, those breadcrumbs cannot be ordered into a causal chain.
• Log integrity: Regulatory and quality systems require auditable timestamps. An unsynchronized PLC clock undermines all log credibility.
• Scheduled events: Recipe changes, shift handovers, and maintenance windows all reference wall-clock time. A drifting PLC clock can trigger actions at the wrong time.

The Undocumented Machine Challenge

When you inherit a B&R system from a defunct OEM, there is no documentation describing which devices use NTP, which rely on manual time setting, and whether any time synchronization exists at all. You must assume clocks are wrong until proven otherwise. The diagnostic workflow on such a system always starts with verifying time synchronization across all devices before attempting any event analysis.

Timestamp Scope on B&R Systems

Internal real-time clocks (RTC) are battery-backed but drift significantly. A 30-second-per-day drift means a PLC can be 15 minutes off within a month if NTP fails silently.

2. B&R NTP Client Configuration

2.1 Configuration Location

In Automation Studio:

1. Double-click the CPU object in the Physical view (or the logical CPU in the Configuration view).
2. Navigate to CPU Properties > Time Synchronization.
3. Enable the NTP client checkbox.
4. Enter the NTP server address (hostname or IP).

Configuration path:
  Physical View
    └── X20CP1584 (CPU)
          └── Properties
                └── Time Synchronization
                      ├── ☑ Use NTP client
                      ├── NTP server: pool.ntp.org
                      ├── Time zone: UTC+01:00 (or local)
                      └── Poll interval: [default]

2.2 Required Prerequisites

NTP on B&R will fail silently if prerequisites are not met. Three conditions must all be true:

2.3 DNS Configuration

DNS is required because NTP server addresses like pool.ntp.org are domain names, not IP addresses. The PLC must resolve these names.

With DHCP:

1. CPU Properties > Ethernet > IP Configuration: DHCP
2. CPU Properties > DNS > “Get DNS from DHCP server”: ON

With Static IP:

1. CPU Properties > Ethernet > IP Configuration: Static
2. Set IP address, subnet mask, and default gateway
3. CPU Properties > DNS > DNS server: manual entry (e.g., 8.8.8.8 or your plant DNS server)
4. CPU Properties > DNS > “Get DNS from DHCP server”: OFF

Static IP configuration example:

  IP address:     192.168.100.10
  Subnet mask:    255.255.255.0
  Default gateway: 192.168.100.1
  DNS server:      192.168.100.1   (plant DNS)
  DNS server 2:    8.8.8.8         (Google public, fallback)

2.4 NTP Server Selection

For industrial environments, an internal NTP server is strongly preferred. It eliminates dependency on external internet connectivity and provides deterministic latency. Configure a Linux server or dedicated NTP appliance on the same VLAN as the PLCs, then point all PLCs to that server.

2.5 Time Zone Configuration

In CPU Properties > Time Synchronization:

1. Set the time zone offset (e.g., UTC+01:00 for CET).
2. Enable daylight saving time if applicable, with the correct transition rules.
3. The PLC stores time internally as UTC and applies the offset for display and logging.

Time zone configuration:
  UTC offset: +01:00:00
  Daylight saving: Enabled
    DST start: Last Sunday in March, 02:00
    DST end:   Last Sunday in October, 03:00
    DST offset: +01:00:00

2.6 Verifying NTP Operation

In Automation Studio with an active online connection:

1. Select the CPU in the Physical view.
2. Go to Online > Info > Time.
3. The dialog shows:
   • Current PLC time
   • NTP server address
   • Time difference (offset between PLC and NTP server)
   • NTP status (syncing, synchronized, error)

Expected Online > Info > Time display:

  PLC time:      2026-07-10 14:32:15.234
  NTP server:    pool.ntp.org
  Time difference: 0.002s
  Status:        Synchronized

A time difference under 100ms indicates good synchronization. Differences over 1 second suggest NTP is failing or the polling interval is too long. Differences measured in minutes indicate a configuration error (see Section 3.6).

2.7 NTP Polling Interval and Accuracy

B&R default NTP polling behavior follows the NTP specification:

On a stable LAN with a local NTP server, expect synchronization within 30 seconds of boot. The PLC will then maintain accuracy within ±10ms indefinitely as long as NTP polls succeed.

3. NTP Troubleshooting on X20CP1584

3.1 The Silent Failure Problem

The most dangerous aspect of B&R NTP is that failures are often silent. Automation Studio may show no errors at all while the PLC clock drifts. This means you cannot rely on AS error indicators alone to detect NTP problems.

Always verify NTP status proactively using Online > Info > Time on every maintenance visit.

3.2 DNS Not Configured (Most Common Failure)

Symptoms:

• NTP server field is populated in CPU properties
• No errors visible in Automation Studio
• PLC time drifts continuously
• AR logger contains no NTP-related entries (PLC never attempted NTP because DNS resolution failed)

Diagnosis:

Step 1: Verify DNS is enabled in CPU Properties > DNS
Step 2: Verify a DNS server address is configured (not blank)
Step 3: If using DHCP, verify "Get DNS from DHCP" is ON
Step 4: If using static IP, verify DNS server is manually set
Step 5: Test from PLC: can it resolve the NTP server hostname?

Fix: Configure DNS server address. If the plant has no DNS server, use a public DNS server (8.8.8.8, 1.1.1.1) or replace the NTP hostname with a direct IP address of the NTP server.

3.3 No Default Gateway

Symptoms:

• PLC can communicate with devices on the same subnet
• NTP server is on a different subnet or the internet
• NTP polls never reach the server
• No error in AS

Diagnosis:

Step 1: Verify default gateway in CPU Properties > Ethernet
Step 2: Ping the gateway from PLC (if possible via PVI or network tools)
Step 3: If NTP server is on the same subnet, gateway may not be needed

Fix: Set the default gateway to the router address that provides access to the NTP server’s network.

3.4 Firewall Blocking NTP (UDP Port 123)

Symptoms:

• NTP configured correctly, DNS working, gateway correct
• PLC cannot sync time
• AR logger may show timeout warnings

Diagnosis:

Step 1: Verify UDP port 123 is open from PLC to NTP server
Step 2: Check plant firewall rules between PLC VLAN and NTP server
Step 3: Check Windows Firewall on the NTP server (if it's a PC)
Step 4: Use network diagnostic tools:
    nmap -sU -p 123 <ntp_server_ip>
    tcpdump -i eth0 udp port 123

Fix: Open UDP port 123 in all firewalls between the PLC and the NTP server. Many industrial firewalls default to blocking all unsolicited inbound traffic; NTP responses may be blocked.

3.5 NTP Server Unreachable

Symptoms:

• All configuration correct
• NTP server does not respond
• Time difference in AS shows increasing divergence

Diagnosis:

Step 1: Ping the NTP server IP from the PLC's subnet
Step 2: nslookup <ntp_server_hostname> from a PC on the same subnet
Step 3: Check if the NTP server service is running (if it's a local server)
Step 4: Check for NTP server rate limiting (pool.ntp.org limits queries)

Fix: Verify NTP server connectivity. If using pool.ntp.org and the PLC is behind a NAT with many devices, you may be rate-limited. Switch to a dedicated internal NTP server.

3.6 The 24-Minute Offset Issue

A known B&R issue where the NTP client configuration results in a time offset of exactly 24 minutes (1440 seconds). This is caused by a mismatch between the configured time zone offset and the NTP server’s interpretation of the timezone.

Root cause: The NTP protocol transmits time in UTC. The PLC applies its local timezone offset. If the timezone configuration in CPU properties is incorrect (e.g., offset is set to UTC+00:00 when it should be UTC+01:00), the displayed time will be wrong by exactly the timezone difference. A 24-minute offset specifically suggests a configuration error where seconds were interpreted differently or a legacy timezone database entry.

Diagnosis:

Step 1: Check CPU Properties > Time Synchronization > Time zone
Step 2: Compare PLC displayed time with a known reference (phone NTP-synced clock)
Step 3: Calculate the offset: is it exactly 24 minutes? Or exactly 1 hour?
Step 4: An exact-hour offset = timezone configuration error
Step 5: An exact-24-minute offset = NTP client configuration error (possibly related to
         the NTP server's timezone handling or the PLC's NTP client firmware version)

Fix:

1. Correct the timezone configuration in CPU Properties.
2. If the issue persists, update the PLC firmware to the latest version.
3. If using a custom NTP server, verify the server’s timezone configuration.
4. As a workaround, use the PLC’s manual time setting to correct the offset after NTP sync.

3.7 Checking AR Logger for NTP Warnings

The AR (Automation Runtime) logger may contain NTP-related entries even when AS shows no errors. Access the AR logger:

1. In Automation Studio: Online > AR Logbook (or via System > Diagnostics > AR Logbook)
2. Filter for NTP-related entries

Search for these message patterns:

AR Logger NTP-related messages:

  "NTP client: no response from server"
  "NTP client: DNS resolution failed"
  "NTP client: server not reachable"
  "Time sync: offset too large, stepping clock"
  "Time sync: offset correction applied"
  "NTP client: authentication failed"

If no NTP entries exist in the AR logger, the NTP client may not be enabled or DNS resolution failed before the NTP client could even attempt a poll.

3.8 Network Diagnostic Steps

When NTP fails, follow this diagnostic sequence from a PC on the same subnet as the PLC:

Step 1: Verify basic connectivity
  ping <PLC_IP>
  ping <DNS_SERVER_IP>
  ping <DEFAULT_GATEWAY_IP>

Step 2: Verify DNS resolution
  nslookup pool.ntp.org <DNS_SERVER_IP>
  nslookup time.windows.com <DNS_SERVER_IP>

Step 3: Verify NTP server reachability
  ping <NTP_SERVER_IP>
  nmap -sU -p 123 <NTP_SERVER_IP>

Step 4: Verify NTP server functionality
  From a Linux PC: ntpdate -q <NTP_SERVER_IP>
  From a Linux PC: chronyc tracking (if chrony is used)
  Output should show server stratum, offset, and sync status

Step 5: Capture traffic from PLC perspective
  tcpdump -i <interface> host <PLC_IP> and udp port 123 -nn
  Look for NTP request packets from the PLC and responses from the server

Step 6: Verify PLC configuration
  Connect with AS, go Online > Info > Time
  Record: PLC time, NTP server, time difference, status

4. Configuring Time Sync Without Automation Studio

When you have no access to Automation Studio (no license, no project file), time synchronization must be configured through alternative interfaces.

4.1 Via PVI (Process Visualization Interface)

PVI allows programmatic access to PLC runtime variables. Using B&R’s PVI API via the pvipy Python library (install: pip install pvipy, requires Windows + PVI Development Setup):

from pvi import *

pviConnection = Connection()
line = Line(pviConnection.root, 'LNANSL', CD='LNANSL')
device = Device(line, 'TCP', CD='/IF=TcpIp')
cpu = Cpu(device, 'CP1584', CD='/IP=192.168.100.10')

cpu.errorChanged = lambda error: print(f"Connected, error={error}")
pviConnection.start()

Important limitation: NTP configuration parameters (server address, timezone, poll interval) are project configuration parameters, not runtime variables. PVI provides access to the PLC’s variable namespace, not to its configuration metadata. Changing NTP settings requires either:

• Automation Studio with the project loaded (preferred)
• Editing configuration files on the CF card (see Section 4.3)
• brsnmp for some network-related parameters (IP, gateway, DNS — see Section 4.2)

PVI CAN read/write runtime variables (process data, setpoints, flags) but CANNOT change CPU configuration properties like NTP server or timezone settings. See pvi-api.md for full PVI capabilities.

Note: The pylogix library is for Allen-Bradley ControlLogix/CompactLogix PLCs and is NOT compatible with B&R systems. For B&R, use pvipy (Python wrapper for PVI) or the OPC-UA path via asyncua.

4.2 Via SNMP (brsnmp Tool)

B&R provides an SNMP agent (brsnmp) that can be loaded as a runtime component. Once loaded:

SNMP configuration for time sync:

1. Load brsnmp component in the PLC configuration
2. Configure SNMP community string
3. Query or set time-related OIDs

B&R SNMP OID for system time (example):
  .1.3.6.1.2.1.25.1.2.0  hrSystemDate.0 (system date and time)

SNMP set example (using snmpset from net-snmp tools):
  snmpset -v2c -c private <PLC_IP> \
    .1.3.6.1.2.1.25.1.2.0 s "$(date +%Y%m%d)$(date +%H%M%S).00"

4.3 Via CF Card Configuration Files

B&R PLCs can load configuration from files on the CompactFlash/SD card:

CF card file structure for time configuration:

  /CF/System/
    ├── config.ini          (main configuration file)
    ├── dns.cfg             (DNS server configuration)
    ├── ntp.cfg             (NTP client configuration)
    └── timezone.cfg        (timezone and DST settings)

Example ntp.cfg:

[ntp]
Enabled=1
Server=pool.ntp.org
Server2=time.windows.com
PollInterval=64
MaxPollInterval=1024

Example dns.cfg:

[dns]
Enabled=1
Server1=8.8.8.8
Server2=8.8.4.4
SearchDomain=local
FromDHCP=0

To deploy: copy files to the CF card, insert into PLC, reboot. The PLC loads configuration files during startup.

4.4 Via OPC-UA

If the OPC-UA server is running on the PLC and time-related variables are exposed:

import asyncio
from asyncua import Client

async def configure_ntp():
    url = "opc.tcp://192.168.100.10:4840"
    async with Client(url=url) as client:
        ns = await client.get_namespace_index("B&R Automation")

        ntp_enabled = client.get_node(f"ns={ns};s=NTP.Enabled")
        await ntp_enabled.write_value(True)

        ntp_server = client.get_node(f"ns={ns};s=NTP.Server")
        await ntp_server.write_value("10.0.0.50")

        timezone = client.get_node(f"ns={ns};s=System.TimeZone")
        await timezone.write_value(3600)

asyncio.run(configure_ntp())

Note: OPC-UA exposure of NTP configuration variables is not default. They must be explicitly mapped in the OPC-UA configuration of the B&R project.

4.5 Via FTP

B&R PLCs expose an FTP server (default port 21) that provides access to the file system:

FTP access to PLC configuration:

  ftp 192.168.100.10
  Username: admin (default)
  Password: <configured password>

  Remote directories:
    /CF/                    - CompactFlash card contents
    /System/                - System configuration files
    /User/                  - User files and logs
    /Log/                   - AR logbook files

  To modify time configuration:
    1. Download current configuration files
    2. Edit locally (dns.cfg, ntp.cfg, etc.)
    3. Upload modified files back
    4. Reboot PLC for changes to take effect

Warning: FTP access may be disabled on security-hardened PLCs. Check if FTP service is running by attempting connection. Modifying configuration files via FTP and rebooting is an unsupported method; use it only when no other option is available.

5. B&R as NTP Server

5.1 Configuration

The X20CP1584 can act as an NTP server, providing time to other devices on the network. This is useful when you have no external NTP server and need to synchronize HMIs, drives, secondary PLCs, or data loggers.

Configuration in Automation Studio:

1. CPU Properties > Time Synchronization
2. Enable “NTP server” checkbox
3. Configure the PLC’s own time source (NTP client pointing to an external server, or manual time)
4. Optionally restrict which subnets can query the NTP server

CPU as NTP server configuration:

  Time Synchronization:
    ☑ Use NTP client
      NTP server: 10.0.0.1 (corporate NTP server)
    ☑ Act as NTP server
      Allowed clients: 192.168.100.0/24

5.2 Use Cases

5.3 Verification

To verify the PLC NTP server is functioning:

From a Linux PC on the same network:

  ntpdate -q <PLC_IP>

Expected output:
  server 192.168.100.10, stratum 3, offset 0.003123, delay 0.02567
  10 Jul 14:32:15 ntpdate[1234]: adjust time server 192.168.100.10
            offset 0.003123 sec

If the query fails:
  ntpdate: no server suitable for synchronization found
  -> Check UDP 123 is not blocked
  -> Verify NTP server is enabled in CPU properties
  -> Check PLC has a valid time source (its own NTP client must be synced)

5.4 Limitations

• The PLC NTP server is only as accurate as its own time source. If the PLC’s NTP client loses sync, all downstream devices will also drift.
• B&R NTP server is based on the SNTP (Simple NTP) protocol. It is suitable for industrial synchronization (±10-50ms) but not for applications requiring sub-millisecond accuracy.
• A PLC reboot will cause the NTP server to be unavailable for 30-120 seconds until the PLC re-establishes its own NTP sync.

6. Multi-CPU Time Synchronization

6.1 Time Sync via POWERLINK

POWERLINK is B&R’s real-time Ethernet protocol. It supports time synchronization between CPUs connected on the same POWERLINK network.

Configuration:

1. In the POWERLINK configuration of the primary CPU, enable time synchronization.
2. Secondary CPUs configured as POWERLINK nodes will automatically synchronize to the primary CPU’s time.
3. The primary CPU must have a valid time source (NTP client or manual setting).

POWERLINK time sync hierarchy:

  Primary CPU (X20CP1584)
    ├── NTP client → external NTP server
    └── POWERLINK master
          ├── Secondary CPU 1 (CN node)
          ├── Secondary CPU 2 (CN node)
          └── Secondary CPU 3 (CN node)

  Time flows: NTP Server → Primary CPU → POWERLINK → Secondary CPUs

POWERLINK time synchronization accuracy: ±1-10 microseconds (depending on network topology and configuration). This is significantly better than NTP over Ethernet and is suitable for coordinating motion and process events across CPUs.

6.2 Time Sync via Ethernet

For CPUs on a standard Ethernet network (not POWERLINK), time synchronization relies on NTP:

1. All CPUs configure their NTP client to point to the same NTP server.
2. Alternatively, one CPU acts as NTP server (see Section 5).
3. All CPUs independently sync to the NTP server.

Ethernet NTP sync:

  Corporate NTP Server (10.0.0.1)
    ├── PLC-01 (192.168.100.10) - NTP client
    ├── PLC-02 (192.168.100.11) - NTP client
    ├── PLC-03 (192.168.100.12) - NTP client
    └── PLC-04 (192.168.100.13) - NTP client

  Each CPU syncs independently. Maximum inter-CPU time difference
  depends on NTP polling and network conditions: typically ±50-200ms

6.3 PTP (IEEE 1588 / IEEE 802.1AS) — Precision Time Protocol

PTP support on B&R controllers is limited to newer hardware and TSN (Time-Sensitive Networking) configurations.

For the CP1584 specifically: PTP is not available. The CP1584’s Ethernet interface and AR 4.x runtime do not implement IEEE 1588. Time synchronization is limited to NTP (for Ethernet) or POWERLINK internal sync (for X2X/POWERLINK bus devices). If you need sub-millisecond synchronization on a CP1584 system, use POWERLINK time sync (Section 6.1) between CPUs and accept NTP-level accuracy for non-POWERLINK devices.

B&R’s PTP implementation uses IEEE 802.1AS (gPTP), which is part of the TSN protocol suite. It requires a TSN-capable Ethernet switch as the PTP grandmaster. The switch distributes time to all connected controllers with sub-microsecond accuracy.

Source: B&R OPC UA over TSN whitepaper — “IEEE 802.1AS (gPTP) allows very accurate time synchronization. B&R controllers make it possible to synchronize.” Source: https://www.br-automation.com/en-gb/downloads/

6.4 NTP Authentication

The CP1584 NTP client does not support NTP authentication (symmetric key or autokey).

Security implication: Any device on the same network that responds to NTP queries on port 123 could potentially spoof time to the CP1584. For hardened environments, place the CP1584 on an isolated VLAN with only the designated NTP server reachable (see cybersecurity-hardening.md for VLAN segmentation procedures).

On newer AR 6.x controllers, B&R has added NTP authentication support — but this does not help the CP1584.

6.5 DHCP Option 42 (NTP Server Auto-Configuration)

The CP1584 does not support DHCP Option 42.

Many industrial networks use DHCP Option 42 (NTP Servers) to automatically configure NTP server addresses for devices. The CP1584’s DHCP client does not request or process Option 42 — NTP server addresses must be manually configured in the CPU properties.

If your plant uses DHCP with Option 42, you will still need to manually configure the NTP server address in each CP1584. Consider using the B&R CPU as NTP server (Section 5) and configuring only the CP1584 with a static NTP server address while other devices use DHCP Option 42.

6.6 B&R Time Synchronization Function Blocks

B&R provides function blocks for explicit time management in user programs:

PROGRAM _CYCLIC
  VAR
    fbGetTime   : TcGetTime;
    fbCheckSync : mcTimeSync;
    currentTime : DT;
    syncStatus  : BOOL;
  END_VAR

  fbGetTime(enable := TRUE);
  IF fbGetTime.ready THEN
    currentTime := fbGetTime.time;
  END_IF

  fbCheckSync(enable := TRUE);
  syncStatus := fbCheckSync.isSynchronized;
END_PROGRAM

6.7 Cross-Referencing Timestamps Across CPUs

When analyzing events across multiple CPUs:

1. Record each CPU’s last known NTP sync status and time difference.
2. Apply a time correction factor based on the measured offset for each CPU.
3. Sort all events by corrected timestamp to build a unified timeline.
4. Account for network latency between the event occurrence and the log entry timestamp.

Cross-CPU timeline correction example:

  CPU-01: time_diff = +0.005s (ahead)
  CPU-02: time_diff = -0.012s (behind)
  CPU-03: time_diff = +0.003s (ahead)

  Event on CPU-01 at 14:32:15.234 → corrected: 14:32:15.229
  Event on CPU-02 at 14:32:15.198 → corrected: 14:32:15.210
  Event on CPU-03 at 14:32:15.321 → corrected: 14:32:15.318

  Corrected order: CPU-01 (14:32:15.229), CPU-03 (14:32:15.318), CPU-02 (14:32:15.210)
  → CPU-02 event actually happened first after correction

6.8 Strategies When CPUs Drift Apart

When NTP fails and CPUs drift apart:

1. Detect drift: Periodically log each CPU’s time relative to a reference. A simple method is to have all CPUs write their current time to a shared variable on a common data connection, then compare.

2. Controlled resync: When NTP is restored, do not let the PLC step its clock forward by a large amount during production. Use the NTP slew mode (gradual adjustment) instead of step mode to avoid triggering time-based events out of sequence.

3. Fallback strategy: If external NTP is unreliable, designate one CPU as the master time source and have others sync to it via POWERLINK or by setting time programmatically.

7. Timestamp Analysis for Diagnostics

7.1 AR Logbook Timestamps

The AR logbook is the primary diagnostic log on a B&R PLC. Every entry carries a timestamp:

AR logbook entry format:

  Timestamp (DT format): 2026-07-10 14:32:15.234
  Log level:              WARNING
  Source:                 Network Manager
  Message:               "Connection timeout to node 5 (X20BC0083)"
  Additional data:        Node=5, Timeout=5000ms, RetryCount=3

  Raw format in exported log:
  [2026-07-10 14:32:15.234] [WARNING] [Network Manager] Connection timeout

The timestamp is the PLC’s local time at the moment the log entry was created. If the PLC clock is wrong, this timestamp is wrong. There is no embedded UTC reference or NTP offset in the log entry itself.

7.2 AR Logbook Timestamp Format

B&R uses the DATE_AND_TIME (DT) data type internally:

DT type breakdown:

  #2026-07-10:14:32:15.234

  Year:     2026
  Month:    07 (July)
  Day:      10
  Hour:     14 (24-hour format)
  Minute:   32
  Second:   15
  Millisecond: 234

  Total bytes: 8 (two 4-byte words: date + time_of_day)

When exporting AR logbook entries, timestamps may appear in different formats depending on the export method (AS web interface, FTP, PVI, OPC-UA). Always confirm the format and timezone of exported data.

7.3 Alarm Timestamp Format

Alarm timestamps in B&R are stored separately from the AR logbook. See alarm-logging.md for detailed alarm timestamp handling.

Key points:

• Alarm timestamps use the same DT type as the AR logbook.
• Alarm logging has its own timestamp source, which may differ from the system clock if a dedicated alarm logging component with its own time base is used.
• The MpAlarmX component stores timestamps for alarm acknowledgment, occurrence, and disappearance.

7.4 SDM Timestamp Usage

The System Diagnostics Manager (SDM) generates diagnostic events with timestamps. See diagnostics-sdm.md for SDM-specific timestamp handling.

SDM timestamps are derived from the system clock at the moment the diagnostic event is detected. SDM events include hardware diagnostics (module insertion/removal, power supply monitoring, watchdog events) and software diagnostics (task overflow, communication errors).

7.5 POWERLINK Cycle Counter vs Wall Clock Time

POWERLINK provides two time references:

The POWERLINK cycle counter increments every cycle and wraps around. It is useful for measuring intervals within a single POWERLINK cycle period (up to several hours depending on cycle time). For longer periods or correlation with external events, wall clock time is required.

Conversion between POWERLINK cycle time and wall clock time:

PROGRAM PLK_Time_Calc
  VAR
    cycleCount : LWORD;
    cycleTime  : LINT;  (* microseconds *)
    wallTime   : DT;
    startTime  : DT;
    elapsedTime: TIME;
  END_VAR

  cycleCount := PLK_GetCycleCounter();
  cycleTime  := cycleCount * 200; (* 200us per cycle for 5kHz POWERLINK *)
  elapsedTime := cycleTime / 1000; (* convert to milliseconds *)
  wallTime := startTime + elapsedTime;
END_PROGRAM

7.6 Correlating PLC Events with External Equipment

To correlate PLC timestamps with events from non-B&R equipment:

1. Common NTP source: Ensure all devices (PLCs, drives, HMIs, PCs, third-party equipment) sync to the same NTP server. This is the most reliable approach.

2. GPS time reference: For facilities with no reliable network NTP, a GPS-based NTP server provides time accurate to ±1μs without network dependency.

3. Manual timestamp recording: When analyzing a specific event, record the exact time from a phone or PC (synced to NTP) at the moment the event occurs. Then search the PLC logs for entries near that time.

4. Network packet capture: Capture network traffic with tcpdump or Wireshark using an NTP-synced capture system. The packet timestamps in the capture file are wall-clock time, and PLC-related packets can be correlated with PLC log entries.

External event correlation workflow:

  1. Motor VFD faults at 14:32:15 (verified on VFD display, time unknown)
  2. Check PLC AR logbook around 14:32:15 ± 5 minutes
  3. Found entries:
     14:32:14.891  [INFO]  Motion command completed (axis 1)
     14:32:14.902  [WARN]  Analog input 3 out of range
     14:32:15.001  [ERROR] POWERLINK node 7 comm timeout
     14:32:15.234  [WARN]  Network Manager: connection lost node 7
  4. Correlation: Analog input fault preceded VFD communication loss by 99ms
  5. Hypothesis: Power supply issue on analog input caused VFD comm failure

7.7 Building a Timeline from Multiple Sources

When reconstructing events from multiple timestamp sources:

Timeline reconstruction template:

  Time (UTC)     | Device    | Event
  --------------- | --------- | ----------------------------------------
  14:32:14.891   | PLC-01    | Motion command completed (axis 1)
  14:32:14.895   | Drive-01  | Speed setpoint received
  14:32:14.897   | Drive-01  | Current limit warning (logged in drive)
  14:32:14.902   | PLC-01    | Analog input 3 out of range
  14:32:15.001   | PLC-01    | POWERLINK node 7 comm timeout
  14:32:15.100   | HMI-01    | Communication timeout alarm displayed
  14:32:15.234   | PLC-01    | Network Manager: connection lost node 7
  14:32:16.500   | SCADA     | Data gap in historian (tag: Drive01_Speed)

  Causal chain: Analog input fault → Drive protection → POWERLINK timeout → HMI alarm → SCADA data gap

  Notes on timestamp corrections:
    PLC-01 time_diff: +0.005s → subtract 5ms from PLC timestamps
    Drive-01 time_diff: unknown (no NTP) → estimated ±500ms accuracy
    HMI-01 time_diff: +0.012s → subtract 12ms from HMI timestamps
    SCADA time_diff: synced to PC NTP → accurate within ±10ms

8. Practical Diagnostic Workflows

8.1 Diagnosing Intermittent Faults with Timestamps

Workflow for finding the root cause of intermittent faults:

Step 1: Verify time synchronization across all devices
  - Check NTP status on every PLC (Online > Info > Time)
  - Check HMI time vs PLC time
  - Check drive time vs PLC time (if accessible)
  - Record the time difference for each device

Step 2: Collect all log entries spanning the fault event
  - Export AR logbook entries for the time window (±10 minutes around fault)
  - Export alarm history for the same period
  - Export SDM diagnostic events
  - Collect drive fault logs (if accessible)
  - Collect HMI alarm history

Step 3: Apply timestamp corrections
  - Add/subtract each device's measured time difference
  - Convert all timestamps to a common timezone (UTC recommended)

Step 4: Build a unified timeline
  - Merge all events into a single sorted list
  - Add device source to each entry
  - Add severity/importance flag to each entry

Step 5: Analyze the timeline for causal patterns
  - Look for the earliest event (root cause candidate)
  - Look for cascading sequences (cause → effect → effect)
  - Look for recurring patterns across multiple fault instances

Step 6: Validate the hypothesis
  - Can the identified root cause explain all observed events?
  - Are there events that don't fit the pattern? (may indicate additional issues)
  - Can the fault be reproduced by triggering the root cause?

8.2 Post-Failure Timeline Reconstruction

After a machine stop or failure with no live monitoring available:

Post-failure reconstruction checklist:

  [ ] Record the exact time the operator reported the failure
  [ ] Check PLC AR logbook for entries ±30 minutes around reported time
  [ ] Check alarm history for the same period
  [ ] Check SDM diagnostics for hardware events
  [ ] Export all logs with timestamps
  [ ] Verify PLC time was correct (compare with external reference)
  [ ] If PLC time was wrong, calculate correction offset
  [ ] Apply correction to all timestamps
  [ ] Build timeline in chronological order
  [ ] Identify the first anomalous event
  [ ] Cross-reference with maintenance records
  [ ] Cross-reference with power monitoring data (if available)
  [ ] Cross-reference with upstream/downstream equipment events

8.3 Correlating I/O Errors with Power Events

A common diagnostic scenario: I/O modules report errors that correlate with power events.

Correlation method:

  1. In the PLC program, log power supply voltage (if monitored) with timestamps
     Example: Log 24V supply voltage every 100ms to a cyclic data logger

  2. In SDM diagnostics, check for power-related events:
     - "Power supply voltage below threshold"
     - "Power supply brownout detected"
     - "Module power-on reset"

  3. Cross-reference I/O error timestamps with power event timestamps

  Example finding:
    14:30:45.100  SDM: 24V supply voltage dropped to 19.2V
    14:30:45.102  SDM: Module X20DI9371 (node 3) reset
    14:30:45.234  AR:  Digital input channel 4 signal loss
    14:30:45.500  AR:  POWERLINK node 3 communication error
    14:30:46.000  SDM: 24V supply voltage restored to 23.8V
    14:30:46.234  AR:  POWERLINK node 3 communication restored

  Conclusion: Momentary power dip caused I/O module reset and communication loss

8.4 Cross-Device Event Correlation Workflow

Cross-device correlation workflow:

  1. Create a device inventory with time sync status
     | Device        | IP            | NTP Server    | Time Diff  |
     |--------------|---------------|---------------|------------|
     | PLC-01       | 192.168.100.10| pool.ntp.org  | +0.005s    |
     | PLC-02       | 192.168.100.11| pool.ntp.org  | -0.012s    |
     | Drive-01     | 192.168.100.20| PLC-01        | +0.008s    |
     | HMI-01       | 192.168.100.30| pool.ntp.org  | +0.015s    |
     | SCADA-PC     | 192.168.100.50| time.win.com  | +0.002s    |

  2. Export logs from all devices for the analysis period

  3. Normalize all timestamps to UTC
     - Subtract each device's time_diff from its timestamps
     - Convert from local time to UTC using known timezone offset

  4. Merge into a single chronological list

  5. Apply filtering to reduce noise
     - Exclude low-priority events
     - Exclude expected periodic events
     - Focus on events in the failure window

  6. Analyze the filtered timeline for patterns

8.5 Time Drift Detection and Correction

Implementing ongoing time drift monitoring:

PROGRAM TimeDriftMonitor
  VAR
    fbGetTime : TcGetTime;
    driftLog  : ARRAY[1..100] OF DT;
    driftIdx  : UINT;
    refTime   : DT;
    maxDrift  : TIME := T#5S;
    driftAlarm: BOOL;
  END_VAR

  fbGetTime(enable := TRUE);
  IF fbGetTime.ready THEN
    IF fbGetTime.time - refTime > maxDrift THEN
      driftAlarm := TRUE;
    END_IF

    driftIdx := driftIdx + 1;
    IF driftIdx > 100 THEN
      driftIdx := 1;
    END_IF;
    driftLog[driftIdx] := fbGetTime.time;
  END_IF
END_PROGRAM

For automated drift detection across a network:

Scheduled drift check script (run from a Linux server):

  #!/bin/bash
  for plc in 192.168.100.10 192.168.100.11 192.168.100.12; do
    plc_time=$(snmpget -v2c -c public $plc .1.3.6.1.2.1.25.1.2.0 2>/dev/null)
    echo "$(date -Iseconds) PLC=$plc SNMP_TIME=$plc_time" >> /var/log/plc_drift.log
  done

9. Cross-References

10. Key Findings

1. NTP failures on B&R PLCs are silent by default. Automation Studio shows no errors when NTP is not working. You must proactively check Online > Info > Time on every maintenance visit. A PLC that has not synced NTP for months may be drifting by minutes or hours.

2. DNS is the most common NTP failure point. The NTP client requires DNS to resolve server hostnames. If DNS is not configured in CPU properties, NTP polls never leave the PLC. This is the first thing to check when NTP is not working.

3. Default gateway is required for external NTP servers. Without a gateway configured, the PLC cannot route NTP packets to servers outside its own subnet. For internal NTP servers on the same subnet, the gateway is not required.

4. Use a local NTP server for industrial reliability. External NTP servers (pool.ntp.org) introduce dependency on internet connectivity and plant firewall configuration. A dedicated NTP server on the same VLAN eliminates these failure points.

5. The 24-minute offset is a configuration error, not a hardware fault. If the PLC time is off by exactly 24 minutes, check the timezone configuration in CPU Properties. The NTP protocol works in UTC; incorrect timezone offsets produce exact time differences.

6. Check the AR logger, not just Automation Studio, for NTP issues. The AR logbook may contain NTP-related warnings that are not surfaced as errors in the AS IDE. Search for “NTP” and “Time sync” patterns in the AR logbook.

7. Cross-device time correlation requires documented time differences. When building diagnostic timelines from multiple devices, record each device’s NTP time difference at the time of the event. Apply corrections to timestamps before merging timelines. Without corrections, events may appear out of order.

8. POWERLINK provides microsecond-accurate time sync between CPUs. For multi-CPU systems on POWERLINK, time synchronization is orders of magnitude more accurate than NTP over Ethernet. Use POWERLINK time sync for motion coordination and tight inter-CPU event correlation.

9. Time-based diagnostics are only as reliable as the clocks. Before any event correlation or root cause analysis, verify that all involved clocks are synchronized. A single device with a wrong clock can invalidate an entire diagnostic timeline. This is the first step in any diagnostic workflow on an undocumented machine.

10. Implement a time drift monitoring routine. Add a simple programmatic check in your PLC code that flags when the time difference from the NTP server exceeds a threshold. This catches silent NTP failures that would otherwise go undetected until the next manual check.

Key Findings

1. Time sync is the foundation of all diagnostic correlation. Without trustworthy timestamps across PLC, drives, IO, and HMIs, it is impossible to determine event causality or perform root cause analysis on intermittent faults.

2. The 24-minute offset is a timezone configuration error. If the PLC time is off by exactly 24 minutes, the timezone setting in CPU Properties is incorrect. NTP operates in UTC; timezone conversion errors produce exact time differences.

3. NTP over the plant network requires firewall configuration. NTP uses UDP port 123 outbound. Ensure plant firewalls allow this and that DNS resolution works for the configured NTP server.

4. POWERLINK provides microsecond-accurate time sync between CPUs. For multi-CPU systems, POWERLINK time synchronization is orders of magnitude more accurate than NTP over Ethernet. Use it for motion coordination and tight inter-CPU event correlation.

5. Silent NTP failures go undetected without monitoring. If the NTP server becomes unreachable, the PLC continues running with its local clock — which drifts. Implement a time drift monitoring routine in your PLC code to flag NTP failures.

6. Cross-device time correlation requires recording time offsets. When building diagnostic timelines from multiple devices, document each device’s NTP time difference at the time of the event and apply corrections before merging timelines.

11. Sources

• B&R Automation Studio documentation: CPU Properties > Time Synchronization configuration
• B&R Automation Runtime (AR) manual: NTP client configuration and behavior
• B&R POWERLINK specification: Time synchronization over POWERLINK networks
• B&R PVI (Programmable Vision Interface) reference: Programmatic PLC configuration access
• B&R SDM (System Diagnostics Manager) documentation: Diagnostic event timestamps
• B&R OPC-UA implementation: Timestamp handling in OPC-UA server/client
• NTP protocol specification (RFC 5905): Network Time Protocol version 4
• NTP pool project documentation: pool.ntp.org usage guidelines and rate limiting
• Industrial network security practices: Firewall rules for NTP (UDP port 123)
• Field experience: 24-minute NTP offset issue on X20CP1584, firmware-dependent configuration behavior
• B&R Knowledge Base: Silent NTP failure behavior, AR logger NTP warning messages
• Community reports: NTP configuration requirements (DNS, gateway, firewall) on B&R X20 systems