Resolving WinCC RT Professional Alarm History 1000-Record Limit

David Krause12 min read
HMI / SCADASiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Problem Overview

When configuring a WinCC RT Professional alarm visualization in TIA Portal, the AlarmControl window stops showing records after 1,000 alarms even though the project-defined alarm log was sized for 10,000 or more entries. Engineers commonly raise the "Max. data records" property on the alarm log from 1,000 to 10,000 and extend the "Time range of statistics" to a full month, yet the runtime display never changes. Operators only see the most recent 1,000 alarms; anything older is silently excluded from the control.

This is a documented design constraint of the AlarmControl view, not a logging failure. The 1,000-row cap is enforced inside the control itself and is independent of the SQL-backed archive the alarm log writes to. Confusing the two layers is the single most common cause of this symptom.

Engineering note: The 1,000-alarm ceiling applies to WinCC Professional RT (TIA Portal) and to WinCC SCADA Classic V7.x. It does not apply to Basic Panels, Comfort Panels, or RT Advanced, which use a different alarm buffering model.

Root Cause Analysis: Two Independent Layers

The alarm pipeline in WinCC RT Professional consists of two clearly separated layers. Misunderstanding either of them produces the reported behavior.

Layer Component Function Sizing Property
Acquisition Alarm logging / AlarmLog Persists incoming alarms to the configured archive (SQL Server, file-based segment, or single-tag) Max. data records, segment interval
Display WinCC AlarmControl Renders a list view of pending or logged alarms in the runtime UI Internal buffer limit of 1,000 rows

The AlarmControl is a presentation layer. It queries the alarm logging back-end on demand and projects the result into a list view, but its working set is bounded to 1,000 messages per refresh. Changing the alarm log's data record count does not change this display buffer because the AlarmControl never requests more than 1,000 rows from the source at one time.

This behavior is documented in the Siemens TIA Portal Help under "Basics on alarm logging (RT Professional)" and the corresponding WinCC Professional runtime manual. See Siemens TIA Portal V20 - Basics on Alarm Logging (RT Professional).

Affected Versions and Software Configurations

Product Versions Verified Behavior
WinCC Professional RT (TIA Portal) V13, V14, V15, V15.1, V16, V17, V18, V19, V20 AlarmControl caps display at 1,000 messages
WinCC SCADA Classic V7.0, V7.1, V7.2, V7.3, V7.4, V7.5 Same 1,000-message cap on AlarmControl
WinCC RT Advanced All versions Not affected; uses buffer-tag model
Basic / Comfort Panels All versions Not affected; circular buffer handles history differently

The bug-or-design question is resolved by recognizing that this is the documented design. There is no fixpack that raises the cap on the AlarmControl itself; instead, the workflow must be changed to query older segments explicitly.

Verification: Confirming the Symptom

Before reconfiguring, prove that the archive actually contains more than 1,000 rows:

  1. Open the project in TIA Portal and navigate to Runtime Settings > Alarm Logging.
  2. Verify the active alarm log has Max. data records = 10000 (or your intended value).
  3. Compile and download to the RT Professional target.
  4. Generate > 1,000 alarm events (force tags, drive a tag generator, or replay from a simulation).
  5. In runtime, right-click the AlarmControl header and choose Export > CSV on the visible list. Export will only contain the most recent 1,000 rows; this confirms the cap.
  6. On the engineering station, connect to the SQL archive backing the alarm log. Locate the segment database (default under C:\Program Files\Microsoft SQL Server\MSSQLxx.MSSQLSERVER\MSSQL\DATA with a CC_AlgLogDb_* prefix).
  7. Run SELECT COUNT(*) FROM <AlarmTable>; to confirm the archive holds the expected 10,000+ rows. A count > 1,000 confirms the limitation is in the view, not in the log.

If the SQL count equals 1,000 exactly, the alarm log itself has wrapped and the issue is upstream of the AlarmControl. In that case, raise the segment size, verify the segment rotation schedule, and check that the AlarmLog connection is not single-tag backed.

Solution 1: Use a Selection with an Explicit Time Interval

The recommended workflow is to expose the Selection dialog on the AlarmControl and let the operator define a time window that points at the older segment of the archive.

  1. In the TIA Portal HMI editor, select the AlarmControl on the screen.
  2. In the Properties > General tab, ensure Source = Alarm log and that the configured alarm log name matches the runtime log.
  3. In Properties > Toolbar, enable the button "Selection" (symbol typically a funnel/filter icon).
  4. Compile and download.
  5. At runtime, click the Selection button. The dialog offers two columns: Time from and Time to.
  6. Set Time from to the timestamp of the 1,001st alarm and Time to to a value after the last alarm of interest.
  7. Click OK. The AlarmControl reloads and now displays alarms from the selected interval, up to its 1,000-row buffer. To scan deeper history, repeat the Selection with successive windows.
Tip: Pair the Selection dialog with an Archive name selector if multiple alarm logs exist. The Selection dialog supports filtering by archive as well as by time range.

Solution 2: Use a Dedicated Selection Screen with Pre-configured Time Ranges

For operator screens that routinely need to walk back further than 1,000 events, build a dedicated selection screen rather than relying on the toolbar Selection dialog.

  1. Add two date/time pickers to a screen (e.g., dtpFrom, dtpTo).
  2. Add a button labeled Show historical alarms.
  3. Wire the button's Click event to set the AlarmControl's Selection parameters. In TIA Portal V17+, the AlarmControl exposes a configurable Selection property. From script:
' VBScript on the "Show historical alarms" button Sub ShowHistorical_Click(ByVal item) Dim ctrl, fromTime, toTime Set ctrl = ScreenItems("AlarmControl") fromTime = ScreenItems("dtpFrom").Value toTime = ScreenItems("dtpTo").Value ctrl.SetSelection fromTime, toTime End Sub
  1. Compile and download. Operators now select arbitrary windows without needing to know the 1,000-row constraint exists.
  2. To expose paging through older intervals, build a page navigator that decrements fromTime by a fixed delta (e.g., one shift or 8 hours) until the archive's earliest record is reached.

Solution 3: Increase the Alarm Log Capacity (So Older Records Survive)

The display buffer caps at 1,000, but the underlying archive must still hold the records. Configure the alarm log so 10,000+ rows actually persist.

Property Recommended Value Notes
Max. data records 10,000 - 500,000 Each record is ~1 KB; 100,000 records ≈ 100 MB
Time range of statistics 1 month / 1 quarter / 1 year Must align with segment rotation
Segment interval Day / Week / Month Smaller segments reload faster but increase file count
Archive type SQL Server (recommended) or File-based segment Single-tag archives do not scale to 10k+ records

In TIA Portal:

  1. Project tree > Runtime Settings > Alarm Logging.
  2. Select the alarm log (e.g., AlarmLog_Process).
  3. Set Max. data records = 10000 (or higher).
  4. Set Time range of statistics = 1 month.
  5. Confirm the Archive type under Runtime Settings > Archives is configured to a SQL-backed connection, not a single tag.
  6. Recompile and re-download the full project.
Engineering note: On TIA Portal V18 and later, the alarm log editor adds a segment limit field that constrains how many segments are retained on disk. Set it to match your retention policy, otherwise the oldest segments are silently deleted regardless of Max. data records.

Solution 4: Add an OLE DB / ODBC Export Pipeline for Long-Term History

When the AlarmControl is fundamentally unable to present more than 1,000 rows at a time, the canonical enterprise workflow is to expose the historical archive via a separate viewer or to export filtered selections to CSV/PDF for compliance review.

  1. Add a button "Export long-term history" to the alarm screen.
  2. Wire the button to a VBScript that opens the Selection dialog, then triggers Export > CSV:
Sub ExportHistory_Click(ByVal item) Dim ctrl, fso, ts Set ctrl = ScreenItems("AlarmControl") ' Apply the user-selected time range ctrl.ApplySelection ' Wait briefly for the reload to complete HMIRuntime.Wait 500 ' Trigger CSV export programmatically ctrl.ExportAlarmLog "C:\Exports\Alarms_" & Year(Now) & _ Right("0" & Month(Now),2) & _ Right("0" & Day(Now),2) & ".csv" End Sub
  1. Compile and download. Operators can now select an arbitrary window and export the full result set (not limited to the 1,000-row view).
  2. For continuous archival, configure the alarm log to write to a SQL database and query it directly from a separate reporting tool (e.g., Power BI, Excel via ODBC, SQL Server Reporting Services).

SQL-Backed Archive: Schema Reference

When the alarm log is backed by Microsoft SQL Server (the recommended path for > 10,000 records), the underlying schema is generated by WinCC and typically lives in a database named CC_AlgLogDb_<n> with tables named AlgLog_<n>.

Column Type Description
MsgNr bigint Alarm number from PLC/HMI
State int 0=Came In, 1=Went Out, 2=Acknowledged
TimeChange datetime UTC timestamp of the state change
TimeCome datetime UTC timestamp of the initial trigger
TimeGone datetime UTC timestamp of the clear event
Text nvarchar(255) Alarm text after substitution
TagName nvarchar(128) Triggering tag name
AckTime datetime Time of acknowledgement
UserName nvarchar(64) User who acknowledged
ComputerName nvarchar(64) Source server name
Priority int 0-16 (0 = highest)
Class int Alarm class ID
Area nvarchar(64) Hierarchy area
Value nvarchar(128) Process value at trigger

Example query for retrieving alarms in a given window:

SELECT TOP 5000 MsgNr, State, TimeChange, Text, ComputerName, UserName FROM AlgLog_1 WHERE TimeChange BETWEEN '2025-03-01 00:00:00' AND '2025-03-31 23:59:59' ORDER BY TimeChange DESC;
Important: All timestamps are stored in UTC regardless of the runtime server locale. Convert in the query when presenting to operators.

Performance Considerations for Large Alarm Logs

Archive Size Storage Footprint Selection Refresh Time Recommended Server
10,000 records ~10 MB < 1 s Any WinCC RT PC
100,000 records ~100 MB 1 - 3 s SSD-backed workstation
500,000 records ~500 MB 3 - 8 s Dedicated SQL Server, 16 GB RAM
1,000,000+ records ~1 GB+ 8 - 20 s Dedicated SQL Server, SSD, indexed on TimeChange

The AlarmControl refreshes the entire 1,000-row view on every Selection change. With archives > 100,000 records, switch to SQL-direct reporting rather than the AlarmControl for compliance review. The AlarmControl is intended as an operator real-time tool, not an archive browser.

Troubleshooting Matrix

Symptom Likely Cause Verification Fix
Display caps at 1,000 alarms AlarmControl design limit SQL count > 1,000 Use Selection dialog with explicit time range
Archive itself caps at 1,000 Max. data records = 1,000 SQL count = 1,000 Raise Max. data records to 10,000+
Archive contains no records after 1 day Single-tag archive (no segment) Archive type = Single tag Switch to SQL-backed or file segment archive
Selection dialog disabled Toolbar Selection button not enabled AlarmControl Properties > Toolbar Enable Selection toolbar button
Selection shows "no data" but SQL has rows Time zone mismatch (UTC vs local) Compare SQL timestamp to RT clock Convert UTC timestamps before Selection
SQL count < 1,000 but display empty Wrong alarm log bound to AlarmControl AlarmControl Source property Set Source = correct alarm log name
Selection refreshes slowly (> 10 s) Archive on slow disk, no indexes Disk I/O, missing IX_AlgLog_TimeChange Move to SSD, add index on TimeChange
Alarm log stops logging SQL Server disk full SQL Server error log Free disk or extend volume

Verification Checklist After Reconfiguration

  1. Confirm SQL count of the archive table is greater than 1,000 after reconfiguration.
  2. Confirm the AlarmControl toolbar shows the Selection button (funnel icon).
  3. Click Selection, enter a time window covering the older events, click OK.
  4. Verify the AlarmControl displays alarms from the selected window (up to 1,000 rows).
  5. Repeat the Selection with an earlier window to confirm you can page back through the entire history.
  6. Confirm runtime CPU and memory return to baseline within 5 s of each refresh.
  7. Confirm the SQL Server transaction log is not growing uncontrollably; schedule a log backup if it is.
  8. Confirm operators have a documented procedure (or an on-screen button) for accessing long-term history.

When to Consider Migrating Off AlarmControl

If your application routinely needs more than the 1,000-row view and Selection paging is operationally unworkable, the AlarmControl is the wrong tool for long-term review. Migrate to one of the following:

  • SQL-direct report: Connect Excel, Power BI, or a custom WebHMI to the SQL archive. This is the canonical path for compliance-grade reporting.
  • WinCC Audit / Information Server: For plants already running WinCC Information Server, expose historical alarms via its web-based reports. It is not subject to the 1,000-row cap.
  • Custom HMI control: Build a custom WebHMI or WinCC Unified view that queries the archive directly without going through the AlarmControl buffer.

For RT Professional projects where operators only need to see the most recent 1,000 events (the typical case for process-line operations), leaving the AlarmControl as-is and configuring the alarm log for the desired retention is the correct engineering trade-off.

Field-Proven Best Practices

  1. Never rely on the AlarmControl for "long-term" historical review. Treat it as a real-time operating tool.
  2. Set Max. data records to match your retention policy. A 1-year retention with one alarm per second yields ~31 M rows; in practice most plants stay at 100k-500k.
  3. Always back the alarm log with SQL Server once you exceed 10,000 records; file segments work but lack query flexibility.
  4. Index the SQL archive on TimeChange to keep Selection refresh times under 1 s.
  5. Document the 1,000-row cap in your HMI operating manual so on-call engineers do not chase a non-bug.
  6. Build a Selection helper screen for operators rather than expecting them to use the toolbar dialog.
  7. If you must see more than 1,000 rows at once, query SQL directly; do not attempt to raise the AlarmControl buffer.

Why does my WinCC RT Professional AlarmControl stop showing alarms after exactly 1,000 records?

The AlarmControl has a fixed internal display buffer of 1,000 alarms. This is independent of the alarm log's Max. data records setting. The archive can hold 10,000+ rows, but the AlarmControl only renders the most recent 1,000 unless you narrow the request using the Selection dialog with an explicit time range.

Can I raise the 1,000-alarm display limit on the AlarmControl?

No. The 1,000-row cap is enforced inside the control and applies to all versions of WinCC RT Professional (TIA Portal) and WinCC SCADA V7.x. It cannot be raised by a property, fixpack, or registry edit. Use the Selection dialog, build a custom export, or query the SQL archive directly for older history.

What is the difference between "Max. data records" and "Time range of statistics"?

Max. data records caps how many rows the archive stores before wrapping. Time range of statistics defines the period the alarm statistics subsystem aggregates over (counts per priority, per class, etc.). Neither parameter changes the AlarmControl's 1,000-row display buffer; they only govern the underlying archive and statistics engine.

How do I view alarms older than the most recent 1,000?

Enable the Selection toolbar button on the AlarmControl, click it at runtime, and set a Time from / Time to window that targets the older segment of the archive. The AlarmControl reloads and shows up to 1,000 alarms from that window. Repeat with successively earlier windows to page back through the full archive.

What archive type should I use for alarm logs larger than 10,000 records?

Use a SQL Server-backed archive. Single-tag archives do not scale beyond a few hundred rows; file-based segments work but lack query flexibility. With SQL Server, you can run arbitrary SELECT queries against the AlgLog_<n> table, index TimeChange for fast filtering, and integrate with external reporting tools for long-term historical review.

Back to blog