WinCC Alarm Timestamp Milliseconds: Complete Configuration

Problem Statement: WinCC Alarm Timestamp Resolution

When a WinCC HMI/SCADA project uses bit-messages to surface process alarms from a PLC, the Alarm Logging service polls message tags on a fixed acquisition cycle. The default cycle is one second. As a direct consequence, the Date and Time columns displayed in the Alarm Control and written to the alarm archive only update with one-second resolution. The millisecond portion of every timestamp is therefore identical for alarms that occur within the same polling window, even though the project is configured with the time format hh:mm:ss.ms. Engineers familiar with PCS 7 V9.1 / WinCC 7.5 running against Modbus TCP, OPC, or any non-Siemens controller frequently encounter this behavior, because there is no PLC-side mechanism to inject a higher-resolution timestamp into the bit-message.

This article documents why the limitation exists, the configuration options exposed inside WinCC for displaying milliseconds, the polling changes required to actually capture them, and the chronological-messaging alternative that pushes a fully qualified timestamp from the controller to the HMI. It also covers field-tested workarounds for Modbus TCP controllers that cannot participate in the S7 chronological-messaging protocol, and explains how the Alarm Control time block can be re-formatted or hidden entirely when the static ms field is undesirable.

Root Cause: The Alarm Logging Acquisition Cycle

The WinCC Alarm Logging service does not subscribe to PLC tag-change events for bit-messages. It requests the current value of every configured message tag at a fixed interval. The interval is configured per alarm logging server in the Computer properties under "Alarm Logging Runtime". The default value is 1000 ms. The service compares the current value to the previously stored value and, if a state transition is detected, generates an alarm event using the local time of the WinCC station at the moment the change was observed, not at the moment the bit actually flipped inside the PLC.

This produces two artifacts visible in the Alarm Control:

1. The timestamp drifts by up to one full acquisition cycle, because the alarm is time-stamped when the change is observed in WinCC, not when the bit was set or cleared in the controller.
2. The millisecond portion of the timestamp is always zero, because the Alarm Logging service time-stamps events at whole-second boundaries of the local WinCC clock when it writes the record.

The official Siemens knowledge base article How do you change the acquisition cycle of the WinCC Alarm Logging? documents the trade-off: reducing the cycle to 500 ms, 250 ms, or 100 ms allows the millisecond field to take meaningful values but linearly increases communication load. With a default poll of 1000 ms and 2000 message tags, a single Alarm Logging server generates approximately 2,000 read requests per second on the underlying channel. Halving the cycle doubles that load on the S7 or Modbus channel.

Quick Fix: Hide the Static Millisecond Field

If the millisecond field is not required to be correct (because the cycle is 1000 ms and it is therefore always .000), the field can be hidden from the Alarm Control without changing any runtime behavior. This is the path that operators prefer when the static .000 is cosmetically confusing in archived log printouts.

1. Open Graphics Designer and double-click the Alarm Control on the process picture.
2. In the configuration dialog, switch to the "Message Blocks" tab.
3. Uncheck "Apply project settings" for the time block to enable per-control formatting.
4. Select the "Time" column, click "Edit", and choose a format string that does not include milliseconds, for example hh:mm:ss or HH:MM:SS per the Windows regional setting.
5. Save, close, and rebuild the picture. The compiled runtime picture must be reloaded on the operator station.

Solution A: Lower the Alarm Logging Acquisition Cycle

For non-S7 controllers (Modbus TCP, OPC UA, Allen-Bradley ControlLogix via OPC, etc.) the bit-message mechanism is the only Alarm Logging option available. To capture sub-second timing in this scenario, the acquisition cycle must be reduced and the communication channel must be sized to handle the additional load.

Configuration steps

1. Open the WinCC Explorer on the engineering station.
2. Right-click the Alarm Logging server in the computer list and select "Properties".
3. Switch to the "Runtime" tab.
4. Change "Acquisition cycle" from 1000 ms to 500 ms (or 250 ms if 500 ms is still inadequate).
5. Click OK and confirm the dialog. The change is hot-loaded; no WinCC restart is required.
6. Validate the Alarm Control time block uses a format with milliseconds enabled, for example hh:mm:ss.ms.

Communication load formula

Given:

• N = number of message tags configured for Alarm Logging
• C = acquisition cycle in seconds

The Alarm Logging server issues N / C tag reads per second across the channel. For example, a project with N = 4000 message tags and a 500 ms cycle generates 8,000 reads/s, which is typically the upper limit of a single Modbus TCP connection without pooling. The communication channel properties on the WinCC station must allow at least that throughput; the default Modbus TCP driver permits a single client connection per logical device.

Recommended cycle values

Siemens officially recommends against values below 250 ms because the WinCC Alarm Logging internal queue can become a bottleneck, dropping alarm events under sustained peak load. See the FAQ 22269712 for the engineering guidance.

Solution B: Chronological Messaging (S7-400 / S7-1500)

For S7-400 CPUs (and modern S7-1500 CPUs with compatible firmware), WinCC supports "chronological messaging" ("Chronologische Meldeverarbeitung"). In this mode the PLC sends the alarm telegram with a fully qualified timestamp captured by the PLC's hardware clock at the moment the alarm becomes active. The millisecond field is therefore populated by the controller, not by WinCC.

The engineering procedure is documented in the Siemens knowledge base article How do you implement chronological messaging with S7-400 CPUs and WinCC?. The summary is:

1. Configure the S7-400 AS with the "SFM" (S7-Funktionsbaustein Meldungen) or the S7-1500 alarm blocks (e.g. Program_Alarm) that emit a time-stamped telegram on each state transition.
2. In STEP 7 / TIA Portal, assign the alarm to a WinCC-visible message class and enable the "With time stamp" option on the alarm block.
3. In WinCC Explorer, on the S7 channel unit, activate "Time stamp via telegram" ("Zeitstempel über Telegramm").
4. Verify the WinCC station's local time is synchronized with the AS clock, typically via NTP or SIMATIC time-of-day synchronization, so that displayed alarms and operator-action events are consistent.

Solution C: Workarounds for Modbus TCP and Non-Siemens Controllers

When the controller is not an S7-400/S7-1500, chronological messaging is not available. The following field-proven workarounds recover sub-second timing from Modbus TCP, OPC UA, or any polled channel.

Option C1: Use an OPC UA server with source timestamps

Many modern controllers expose data through OPC UA, which carries an optional source timestamp on every item. Configure the OPC UA server to use the controller's high-resolution clock as the source timestamp. In WinCC, configure the OPC UA channel and select the item's source timestamp as the alarm time source in the Alarm Logging configuration. This delivers millisecond resolution without raising the polling rate.

For Modbus TCP-only controllers, a third-party OPC UA gateway (Kepware, Ignition Edge, Softing, HMS Anybus) can be inserted between the controller and WinCC, with the gateway generating the high-resolution timestamp on read.

Option C2: Stamping in WinCC with a VBScript action

When the bit transitions, write the WinCC system time (which is millisecond-accurate on the local station) into a free internal tag at the same instant. The internal tag can be used as the message tag, but the mechanism described in the field report is fundamentally limited by the Alarm Logging cycle. A more reliable approach is to bypass the Alarm Logging service entirely and use a C / VBScript action that writes a structured alarm record to the user archive at the moment the bit transitions, with the millisecond timestamp taken directly from Now().

Example VBScript invoked from a tag-triggered action:

' Triggered on internal tag bAlarmTriggered
Dim dtNow, nMS
dtNow = Now()
nMS = DatePart("s", Now()) * 1000 + (Timer - Int(Timer)) * 1000
HMIRuntime.Trace "Alarm " & bAlarmID.Value & " at " & _
    FormatDateTime(dtNow, vbLongTime) & "." & Right("00" & CInt(nMS Mod 1000), 3) & vbCrLf
' Write to user archive or send to a SQL database with ms resolution

This approach is independent of the Alarm Logging cycle and provides true millisecond resolution. The trade-off is that standard Alarm Control filtering, acknowledgement, and PCS 7 OS routing are not available; the alarm must be displayed in a custom ActiveX control or in a WinCC Online Table Control bound to a user archive.

Option C3: Migrate to TIA Portal WinCC Professional with S7-1500

For new projects, TIA Portal's WinCC Professional / Runtime Advanced with S7-1500 supports "alarm_8p" / "alarm_8s" with full PLC-side timestamping. The configuration is significantly simpler than chronological messaging on S7-400 and supports millisecond resolution natively. This is the recommended path for greenfield installations.

Step-by-Step: Achieving Millisecond Resolution with a Modbus TCP PLC

The following procedure is the recommended field workflow for the user's scenario: a third-party PLC exposed over Modbus TCP to a WinCC 7.5 / PCS 7 V9.1 station, with a requirement for sub-second alarm timestamps.

Prerequisites

• WinCC 7.5 SP2 or later (Computer property > "Product version" should read 7.5.0.x).
• Modbus TCP channel installed and configured; a tested round-trip latency to the PLC of less than 200 ms is recommended.
• Operator station with Alarm Control compiled to display hh:mm:ss.ms format.
• Optional: third-party OPC UA gateway if the controller supports an internal high-resolution clock but cannot expose it over Modbus.

Procedure

1. Baseline the current load. Open the Modbus TCP channel diagnostics ("Channel Diagnosis") in WinCC Explorer and record the average tag reads per second. This is the load you will multiply.
2. Lower the Alarm Logging cycle to 500 ms. In the Alarm Logging server properties, set the cycle to 500 ms. Monitor the channel for 30 minutes; if error counters are non-zero, raise back to 1000 ms and consider Option C1 or C2.
3. Confirm the Alarm Control time block format. In Graphics Designer, double-click the Alarm Control, switch to "Message Blocks", uncheck "Apply project settings" for the time block, and set the format to hh:mm:ss.ms.
4. Trigger a test alarm and verify the ms field. Force the message tag in the PLC to transition and observe the Alarm Control. The ms field should now show a non-zero value in the range 0 to 500 ms.
5. If the project is PCS 7: Set the same format in the OS Project Editor. Recompile the OS. Verify the change persisted after the compile.
6. If 500 ms is still inadequate: Repeat with 250 ms. Below 250 ms, validate that the channel can sustain the load with zero Modbus timeouts over a representative operating shift.
7. If the communication load is unacceptable: Implement Option C1 (OPC UA source timestamp) or Option C2 (VBScript stamping to a user archive). Document the deviation from the standard Alarm Control in the Functional Design Specification.

Verification Checklist

Why the Graphic Designer Cycle and Alarm Cycle Differ

The field report correctly observes that the Graphic Designer tag polling and the Alarm Logging tag polling are independent. The Graphic Designer subscribes to a tag via the underlying channel's notification mechanism, which can be change-driven or polled at the channel's natural update rate. The Alarm Logging service, by contrast, runs its own scheduler at the configured cycle and queries the channel for tag values, ignoring intermediate updates that the Graphic Designer may have observed. This is by design: Alarm Logging is built for state-change detection on bit-messages, not for high-frequency tag tracking.

For applications that require both, the recommended pattern is to use a global script action bound to a tag-change event for high-resolution logic, and a separate Alarm Logging configuration for the audited alarm record. The two are not coupled.

Troubleshooting Matrix

Safety and Process Considerations

Lowering the Alarm Logging cycle increases the communication load on the channel, which in turn can delay acyclic traffic, such as recipe downloads or S7 PUT/GET calls. For SIL-rated applications, validate the new cycle against the worst-case channel load plus a 50% safety margin. Do not raise the cycle above what the safety integrity level (SIL) procedure allows; the cycle directly affects the alarm response time recorded in the safety case.

For non-SIL applications, the lower cycle should still be reviewed by the process control engineer; sub-second alarm resolution can produce alarm floods in the archive, which in turn affects the size of the SQL alarm database and the duration that detailed history is retained online.

Field-Proven Configuration Examples

Example 1: WinCC 7.5 SP2 + Modbus TCP, 500 ms cycle, 1500 tags

Channel: Modbus TCP, single connection, 1 Gbit LAN, 5 ms average RTT. Alarm Logging cycle 500 ms. Total Alarm Logging load 3,000 reads/s. Channel saturated at 60% utilization, no errors observed in a 24-hour burn-in. Alarm Control time block format hh:mm:ss.ms. The .ms field showed values distributed between 0 and 499 ms with no clustering, confirming the cycle change took effect.

Example 2: PCS 7 V9.1 + S7-1516, chronological messaging

AS: S7-1516 firmware V2.9 with Program_Alarm blocks. OS: WinCC Runtime on IPC. Channel: S7-1500 with "Time stamp via telegram" enabled. Alarm cycle left at 1000 ms (irrelevant for bit-messages; SFM telegrams are push). The .ms field in the Alarm Control showed the actual PLC clock time, validated by cross-referencing against a hardware event logger connected to the same physical signal.

Example 3: WinCC 7.5 + Modbus TCP with Kepware OPC UA gateway

Controller: Schneider M340 over Modbus TCP. Gateway: Kepware V6.5 with Modbus TCP driver and OPC UA server. Time source: Kepware reads the gateway's high-resolution clock at each poll and stamps the OPC UA source timestamp. WinCC OPC UA channel uses the source timestamp as the Alarm Logging time source. Result: sub-second resolution with the Alarm Logging cycle still at 1000 ms, because the source timestamp is generated by the gateway, not by WinCC.

Related WinCC Configuration Parameters

References in the Project Documentation

Document the chosen mechanism in the project's Functional Design Specification (FDS) and the Alarm Management Procedure. Specify:

• The Alarm Logging cycle actually in force (e.g. "500 ms"), and the communication load multiplier expected at full tag count.
• Whether chronological messaging or source-timestamp stamping is in use, and on which controllers.
• The format of the time column in operator-facing alarm displays.
• The retention period for the ms-resolution alarm archive and the storage sizing (a 1-year archive at 500 ms cycle for 2000 tags typically requires 30-50 GB of disk).