Resolving Slow WinCC OnlineTrendControl Screen Loading

Problem Definition: WinCC Picture Window Opens Slowly When OnlineTrendControl and RulerControl Are Embedded

Engineers commissioning a Siemens SIMATIC WinCC runtime often encounter a 3–15 second stall when a Process Picture (PDL) containing an WinCC OnlineTrendControl and a WinCC RulerControl is opened. The symptom is consistent across both the classic WinCC V7.x runtime and the WinCC Professional / Unified runtime: the main picture window appears, but the screen does not become operator-ready until the trend control completes its initial archive query, dataset prefetch, and axis layout pass.

In a typical configuration the affected PDL acts as the central HMI screen. A single root PDL hosts two picture windows – one per monitor – and inside each picture window a navigation sub-PDL is loaded. When the operator selects the trend view, the main picture must (1) instantiate the OnlineTrendControl, (2) issue a SQL Server SELECT to the configured Tag Logging archives, (3) hydrate the dataset cache for the configured time range, (4) instantiate the RulerControl with a back-reference to the trend, and (5) layout the time axis, value axis and legend. Steps 2 and 3 dominate total open time.

For an integrator this manifests as a degraded operator experience, especially on overview screens that are touched every shift. The issue is not a single bug; it is a function of how WinCC fetches data on PDL load when the trend object is statically present on the picture.

Root Cause Analysis: Why the Trend Control Holds Up Picture Open

WinCC OnlineTrendControl pulls its initial dataset synchronously during the PDL OpenPicture event. The control does not wait for the operator to scroll or zoom – it requests the configured TimeRange at instantiation. The RulerControl piggybacks on the trend's archive handle, so it contributes additional metadata reads. The latency budget breaks down as follows in a representative production system:

The two largest contributors – SQL archive SELECT and hydration – are not bound to the trend object itself but to the surrounding archive configuration. The next sections decompose each contributor and the engineering controls that contain it.

Affected Software Versions and Configurations

The slow-open symptom is documented across every active WinCC line. The exact impact varies by service pack and runtime platform:

Siemens publishes corrections and performance hotfixes through the Siemens Industry Online Support portal. Always verify the current Service Pack level and any WinCC Performance Improvement hotfixes (search for entry ID 48354879 and the V7.5 SP3 Update 1+ readme) before attempting structural code changes.

Diagnostic Procedure: Quantifying the Stall

Before changing the project, isolate which layer is responsible. The following four-step diagnostic takes about 30 minutes and produces hard numbers you can compare before/after any change.

1. Measure picture open time with ApDiag. In the WinCC Graphics Designer, enable Diagnostic Tools > ApDiag. Open the affected PDL and read the OpenPicture timing. The trend control is named in the timing tree as WinCC Online Trend Control; its construction line item will show the SQL latency if the archive is the bottleneck.
2. Measure raw SQL latency. On the WinCC server, open SQL Server Management Studio and execute the same query that the trend control issues – typically a SELECT * FROM dbo.MEASVALUES_TIME_T... against the configured segment database for the configured time range. Compare execution time against the trend construction time in step 1.
3. Profile the archive. In WinCC Explorer, open Tag Logging > Archives > [archive name] > Properties > Segments. Record the segment size in days, the number of segments on disk, and the total row count returned by the SELECT in step 2.
4. Bisect the picture. Duplicate the PDL, delete the OnlineTrendControl and RulerControl, and re-time the open. If the open returns to < 1 s, the trend + ruler stack is the dominant cost. If open time is still several seconds, the bottleneck is the surrounding picture (tag count, dynamic dialogs, or scripts).

Document the four numbers. They become the baseline against which every fix below is validated.

Root Cause #1 – Trend and Ruler Are Static on the Main Picture

The most common and the cheapest fix is to remove the trend from the picture that is loaded by default. WinCC loads every object that is statically placed in a PDL at picture-open time, regardless of whether the object is currently visible. An OnlineTrendControl configured with a 24-hour time range, eight curves, and a 1-second acquisition cycle will execute its archive fetch on every picture open.

Recommended Pattern: Lazy Picture Window

Move the trend view into a separate PDL (e.g. TrendView.PDL) and host it inside a picture window on the main screen. Set the picture window property Visible = 0 (false) on picture open. The trend is then instantiated only when the operator presses the trend button, at which point a script flips the property to 1 and the load latency is paid on demand rather than at start-up.

' C-Script in the trend button – main PDL
#include "apdefap.h"
void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
    // Set the picture window visible to instantiate the trend PDL on demand
    SetPropChar(lpszPictureName, "PicWinTrend", "Visible", "1");
    // Optional: switch the picture window to the trend PDL
    SetPropChar(lpszPictureName, "PicWinTrend", "PictureName", "TrendView.PDL");
}

The trade-off is that the operator still pays the SQL fetch when they request the trend – the difference is that the start-up screen opens fast, and the operator can pre-warm the trend with a small pre-load (e.g. 5 minutes) so the eventual full-range load happens in the background.

Root Cause #2 – SQL Server Archive Bloat

WinCC V7 and TIA WinCC Professional store Tag Logging archives in a SQL Server database. The default configuration creates one segment per archive per configurable time period (typically 1 day, 1 week, or 1 month). Each segment is a set of SQL tables inside the same database file. As the system accumulates segments, three things happen:

1. The SQL Server query optimizer degrades – the SELECT must span more tables and join more history.
2. The WinCC archive manager must scan the segment index to discover which tables contain the requested time range.
3. Disk I/O on the database file increases linearly with the number of segments in the active query window.

Archive Tuning Procedure

1. Right-size the segment period. In Tag Logging > Archives > Properties > Segments, choose a segment period that matches the operator's natural query range. If operators routinely look at 8 hours, do not use 1-day segments; use shift-sized segments (e.g. 8 h or 12 h) so each query touches one or two tables.
2. Reduce the number of segments per archive. For long-retention tags, consider splitting the archive by tag group. Tags that are looked at only on alarm can use a coarser archive, while high-frequency process tags use a finer archive.
3. Reorganize and rebuild indexes. On the WinCC server, schedule a weekly SQL Server Maintenance Plan that runs DBCC DBREINDEX (or ALTER INDEX REBUILD on SQL 2016+) on the dbo.MEAS* tables during a quiet shift. Index fragmentation above 30 % is the most common cause of multi-second query time on a small archive.
4. Update statistics. Add UPDATE STATISTICS to the same maintenance plan. Out-of-date statistics cause the optimizer to choose a poor plan, especially after major data ingestion events.
5. Move the SQL database to a dedicated disk. Co-locating the archive database with the WinCC project database and the OS page file is a frequent cause of multi-second latency under load. A dedicated SSD or NVMe volume for the archive MDF and LDF files is a high-leverage change.

Root Cause #3 – Trend Time Range Too Wide

The OnlineTrendControl property TimeRange (in WinCC V7) and the TimeRange / TimeBase pair (in TIA Portal / Unified) control the size of the initial SQL fetch. A control configured for 7 days of 1-second data will read roughly 604 800 rows per curve before it can render the first pixel. Reduce the default time range and let the operator zoom for historical data.

If a long time range is required for the start-up screen, set the control's Source to a swap archive with pre-aggregated data (WinCC V7) or use a separate higher-level archive for historical queries.

Root Cause #4 – RulerControl Overhead and Mis-Binding

The RulerControl is a passive object – it does not query the archive on its own. It reads its values from the OnlineTrendControl to which it is bound via the property TrendWindow. The performance cost of the RulerControl therefore comes from (a) the bound trend's data load, and (b) any back-reference mis-configuration that causes the ruler to query the wrong window and force a second fetch.

Correct RulerControl Binding

1. Open the Object Properties of the OnlineTrendControl and confirm the Name property (e.g. CTRL_TREND_1).
2. Open the Object Properties of the RulerControl and set TrendWindow to the same name (CTRL_TREND_1). Do not set it to a picture window name or a tag name.
3. Wire the ruler's value events from the trend, not from the archive. The Siemens KB article How do you read out the trend values on the ruler of the WinCC Online Trend Control? documents the recommended Control Properties > Object Events > On Ruler... wiring. Use that pattern to read the values out of the trend rather than re-issuing SQL queries from the ruler.

Solution: Tiered Engineering Response

Apply the fixes in order, re-running the ApDiag measurement after each step. The cumulative impact is typically a 5×–20× reduction in picture open time.

1. Tier 1 – Code structure (no hardware cost): Move the trend to a lazy picture window. Expected impact: removes the trend load from main picture open entirely. Cost: 30 minutes of configuration.
2. Tier 2 – Archive tuning (no hardware cost): Re-segment the archive, rebuild indexes, update statistics. Expected impact: 30–70 % reduction in the on-demand trend open time. Cost: half a day, including one quiet shift for the maintenance window.
3. Tier 3 – Trend configuration (no hardware cost): Reduce the default time range, reduce the number of curves on the start-up view, archive-only the high-frequency tags. Expected impact: linear with the reduction in fetched rows.
4. Tier 4 – Hardware (one-time cost): Move the archive database to an SSD/NVMe volume, separate from the OS and the project database. Expected impact: 2×–5× reduction in raw SQL latency. Cost: one disk, one planned maintenance window.
5. Tier 5 – Service pack / hotfix (no cost): Apply the current WinCC Service Pack and the latest Performance Improvement hotfix. Each SP typically contains measurable trend-load improvements. Search the Siemens Industry Online Support for the WinCC version's latest readme.

Code Examples: VBScript for Pre-Warm and Lazy Load

The following VBScript snippets demonstrate a pre-warm pattern that runs in the background after the main picture is open. The trend is pre-loaded with a short time range so the operator's eventual full-range query is fast.

' Pre-warm the trend picture window 2 seconds after main picture open
Sub OnOpenPicture(ByVal PictureName)
    If PictureName = "Main.PDL" Then
        HMIRuntime.ActiveProject.ActiveScreen = "Main.PDL"
        ' Defer the pre-warm by 2 seconds so the operator sees the UI immediately
        HMIRuntime.Timers.CreateTimer "PreWarm", 2000, False
    End If
End Sub

Sub OnTimer(ByVal TimerName)
    If TimerName = "PreWarm" Then
        ' Pre-warm: instantiate the trend picture window with a 5-minute range
        Set oPic = ScreenItems("PicWinTrend")
        oPic.Visible = True
        ' After 30 seconds, hide it again so it does not consume resources
        HMIRuntime.Timers.CreateTimer "HideTrend", 30000, False
    ElseIf TimerName = "HideTrend" Then
        ScreenItems("PicWinTrend").Visible = False
    End If
End Sub

This pattern is suitable for WinCC Professional and WinCC Unified Comfort Panels. For WinCC V7 use the equivalent C-script with SetVisible on the picture window and a SetTimer call.

Verification Procedure

After each tier, repeat the four-step diagnostic and compare against the baseline. Acceptance criteria for a "fixed" state:

1. Main picture open time < 800 ms (operator-perceived instant).
2. Trend picture window open time < 1.5 s for a 24-hour, 8-curve view, measured on the production server under nominal load.
3. SQL archive SELECT for the trend's default range completes in < 500 ms on the server (measured in SSMS with SET STATISTICS TIME ON).
4. No trending-related messages in the WinCC diagnostic log: CCTrendingServer.exe queue time, CCArchiveConnMon warnings, or SQL timeout errors.

Troubleshooting Matrix

Safety and Operational Notes

FAQ