Fixing WinCC V6 TagLogging PLC Disconnection at 500ms Cycles

Problem Statement: WinCC V6 SP3 TagLogging Drops One PLC After Approximately 30 Minutes

A WinCC V6.0 SP3 runtime station is connected to four SIMATIC PLCs (S7-300/S7-400 class) over Industrial Ethernet / TCP/IP using the SIMATIC S7 Protocol Suite channel. The project registers 70 process tags in TagLogging with the following configuration that is critical to the failure mode:

Observed runtime behavior:

1. WinCC runtime starts cleanly; all four PLC connections report OK in WinCC Explorer > Channel Diagnostics.
2. After approximately 30 minutes of continuous operation, exactly one of the four PLC connections transitions to Disconnected.
3. The disconnected partner does not recover without an operator action (server restart, channel re-init, or manual reconnect).
4. Deactivating TagLogging entirely eliminates the disconnection. All four PLCs remain connected indefinitely with the same channel configuration and the same PLC program.

The pattern is consistent with a polling-overload or runtime-resource saturation in the WinCC V6 communication layer, triggered when TagLogging pushes the acquisition cycle down to 500 ms across 70 tags on a server that has only 1 GB of physical RAM and an unspecified number of C-Scripts attached to the same HMI process.

Root Cause Analysis: Why 500 ms TagLogging Starves the S7 Channel

Three independent factors compound in the failure case. Each one is recoverable on its own; the combination reliably breaks the connection after 25-40 minutes of runtime.

Factor 1 - Polling-Overload From Cyclic Continuous Acquisition

With acquisition type = cyclic continuous and acquisition cycle = 500 ms, the Data Manager schedules a read request for every logged tag every 500 ms. The theoretical load is:

L_polled = N_tags / T_acq = 70 / 0.5 = 140 tag-reads/s

On Industrial Ethernet / TCP-IP using the SIMATIC S7 Protocol Suite, the S7 communication driver multiplexes these reads onto a smaller number of PDU (Protocol Data Unit) requests. The default maximum PDU size is 480 bytes, and the S7-300/400 driver typically packs 8-12 tag reads into a single PDU. The effective request rate to the channel is therefore:

R_eff = ceil(140 / 10) = 14 PDU/s minimum, plus handshakes

Each PDU also requires an application-level acknowledge. If any of those PDUs is lost (TCP retransmit, switch port flap, broadcast storm), the driver must retransmit and may time out on the partner that was momentarily slow. With a saturated 1 GB server, GC pauses and Data Manager thread starvation cause periodic read-queue backlogs that exceed the 5-second S7 partner timeout. The result: one of the four PLCs is the slowest responder on the segment and is declared disconnected first.

Factor 2 - 1 GB RAM Is Below the V6 SP3 TagLogging Envelope

WinCC V6.0 SP3 documentation specifies a minimum of 1 GB RAM and recommends 2 GB or more for any project that uses TagLogging with sub-second acquisition cycles. The Data Manager caches tag values in shared memory, and the TagLogging runtime buffers uncompressed process values in RAM before they are flushed to the segment file. The memory footprint of 70 tags at 500 ms continuous acquisition is dominated by the segment buffer:

On a 1 GB server this leaves ~ 360-550 MB free, which is enough at startup. After 25-40 minutes the Windows working set manager begins trimming the Data Manager pages. Trimming the Data Manager starves the channel threads, which causes PDU timeouts, which causes the S7 driver to tear down the slowest connection. The fact that exactly one PLC drops is the signature: the four PLCs are not equally loaded, and the partner that is the busiest on the S7 partner list is the first to time out.

Factor 3 - C-Scripts and Global Scripts Add Unpredictable CPU Spikes

WinCC V6 executes C-Scripts on a single-threaded scheduler by default. A 10 ms C-Script triggered every second on a saturated CPU is invisible. The same script on a server that is paging or under Data Manager pressure can take 200-400 ms, during which the Data Manager thread is blocked and the read queue backs up. This is the dominant secondary cause observed in this failure class.

WinCC V6 TagLogging Architecture You Need to Understand

Before changing configuration, it is essential to understand the runtime topology. The following inline diagram shows the WinCC V6 data flow for a logged tag:

The key insight: the Data Manager, the TagLogging runtime, and the C-Script engine share one process (CCEs.exe / WinCC.exe). If any of them stalls, all three stall. The S7 channel unit runs in the same process and shares its read-queue with the Data Manager, so a slow Data Manager manifests as channel timeouts.

Channel Unit Cycle Management: The "By PLC" Checkbox Explained

Inside the SIMATIC S7 Protocol Suite, every connection (logical connection to one PLC) has a System Parameters > Cycle Management tab. The default state is:

When By PLC is enabled, the S7 driver only requests a value when the PLC reports that the value changed. The PLC must therefore be programmed to send spontaneous updates for the 70 logged tags. In a typical S7-300/S7-400 program, this is rarely done for 70 tags. What actually happens in the field is that By PLC is enabled, the PLC never sends a spontaneous update, the read queue stays empty, and the runtime appears to work - but if any tag is referenced by a C-Script or by a WinCC picture, the driver falls back to cyclic polling on a per-tag basis, and the read queue becomes unpredictable.

When By PLC is disabled, the S7 driver is told: do not wait for the PLC. Poll the tag on the configured cycle. This produces a higher but fully predictable load on the channel. The benefit is that the partner watchdog never fires, because each read PDU is acknowledged on schedule. The drawback is that the cycle time must be set such that the channel can complete all polls within the cycle window - which is exactly the resource constraint in this project.

Solution Step-by-Step: Restore Stable Communication With TagLogging Enabled

Apply the changes in the order shown. Each step is independently useful; together they remove the 30-minute failure.

Step 1 - Disable "By PLC" on Every S7 Channel Connection

1. Open WinCC Explorer on the engineering station and open the server project that is online.
2. Right-click the channel unit (e.g. SIMATIC S7 Protocol Suite > MPI/Industrial Ethernet > S7 Connection_1) and choose System Parameters.
3. Open the Cycle Management tab.
4. Uncheck the By PLC checkbox.
5. Click OK and confirm the prompt that the change is applied to the runtime project.
6. Repeat for every S7 connection (Connection_1 through Connection_4 in this project).
7. Recompile the OS and download the modified project to the runtime server.

Step 2 - Reduce the Acquisition Cycle to a Value the Channel Can Sustain

For four S7-300/400 partners and 70 logged tags, the sustained polling rate on a healthy 1 GB server is approximately 60-80 tag-reads/s. That corresponds to a 1 s acquisition cycle:

Set the acquisition cycle to 1000 ms in the TagLogging configuration of the WinCC Explorer. Increase the archiving cycle to 1000 ms at the same time. The display cycle can stay at 500 ms - the OnlineTrendControl interpolates between archived values without forcing a second read from the PLC.

Step 3 - Verify RAM, CPU, and OS Tuning

1. Confirm physical RAM: wmic memorychip get capacity on the server. If less than 2 GB, schedule a hardware upgrade as the second-priority action.
2. Open System Properties > Advanced > Performance Settings > Advanced > Virtual Memory. Set the page file to a fixed size equal to 1.5x physical RAM on a dedicated partition.
3. Disable screen savers and the Windows XP theme engine on the runtime server. Each one can re-introduce GDI pressure that throttles the Data Manager.
4. In Computer Properties > Start > Auto-start, confirm that only WinCC Runtime is in the auto-start tray. Disable antivirus real-time scanning on the WinCC project directory and on the archive path.

Hardware and RAM Optimization for WinCC V6 SP3

WinCC V6.0 SP3 is a 32-bit process and is therefore limited to a 2 GB user-mode virtual address space on Windows XP / Server 2003 (3 GB with the /3GB boot switch, but this is not officially supported for V6). The usable working set per process is typically 1.2-1.6 GB even on a 4 GB physical server because of the 32-bit address space limit.

For the project described here (4 PLCs, 70 tags, 500 ms, 1 GB), the immediate hardware action is to upgrade to 2 GB. This single change is usually enough to stop the 30-minute drops even without any software changes, but Step 1 (disable By PLC) is still required because it removes a class of partner-watchdog failures that can occur on 2 GB as well when the network is loaded.

Diagnose Folder Analysis: Read the Logs Before You Change the Project

Before applying any change, copy the entire ..\wincc\diagnose\ folder from the server. The relevant files are:

To analyze the failure timestamp (the moment one PLC drops), use findstr /s /i "disconnect" *.log from the diagnose folder. Cross-reference the line with the WinCC internal event log (WinCC Explorer > Computer > Properties > Events). The first 10 lines after the disconnect timestamp are the highest-value evidence: they tell you whether the driver ran out of resources, whether the partner watchdog fired, or whether a C-Script raised an access violation that took the runtime down.

C-Script and Global Script Optimization

Every C-Script in the project competes with the Data Manager for the same WinCC process scheduler. The performance budget on a 1 GB V6 SP3 server is small. Audit the project as follows:

1. Open WinCC Explorer > Computer > Properties > C-Scripts. List every project function and every action.
2. For each function that is called from a picture (button, mouse action, value change), measure its worst-case execution time using GetTickCount() at start and end. Print to ProjectDebug.log only when the script exceeds 50 ms:

#include "apdefap.h"
void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName)
{
DWORD t0 = GetTickCount();
/* ... your logic ... */
DWORD dt = GetTickCount() - t0;
if (dt > 50)
{
  printf("OnClick slow: %lu ms on %s\r\n", dt, lpszObjectName);
}
}

3. Move any C-Script that runs faster than 1 Hz to a Global Script scheduled timer at 1 s or 2 s. C-Scripts on a 500 ms trigger should be eliminated unless they are strictly required for the displayed value.
4. Eliminate SetTagWord / SetTagFloat calls from inside frequently triggered C-Scripts. Each Set* call enqueues a write into the Data Manager and can stall a thread. Use the internal tag direct write API only if you have profiled the call and confirmed the cost.
5. Avoid MScriptMsg and printf in hot paths. Each call to printf flushes a buffered I/O stream and can take 1-5 ms.

After the audit, the typical finding is that 80 percent of the runtime cost is concentrated in 20 percent of the scripts. Those are the ones to optimize or to reschedule.

TagLogging Configuration Tuning Beyond the Acquisition Cycle

Three additional knobs in TagLogging reduce runtime cost without losing data:

Knob 1 - Switch "Cyclic Continuous" to "Cyclic On Command" or "On Change"

For 70 tags that include 30-40 slow-changing values (setpoints, mode flags, status words), acquisition type = On Change with a tolerance of 0.5 percent of the engineering range reduces the effective read rate to 5-20 reads/s while still capturing every significant transition. The 500 ms cycle is reserved for the 20-30 fast-changing values that genuinely need it.

Knob 2 - Increase the Archiving Cycle Independently of the Acquisition Cycle

The acquisition cycle and the archiving cycle are independent. The recommended split for this project is:

The compression effect is significant: a 70-tag archive at 2 s holds 8 hours of data in a single segment of ~ 100 MB, whereas a 500 ms archive holds only 2 hours. The disk I/O cost is therefore 4x lower.

Knob 3 - Use the Single-User Project Mode Only If the Project Is a Standalone Server

WinCC V6 can run in multi-user (client-server) mode or single-user (standalone) mode. Multi-user mode adds the WinCC server-client data exchange to the process and consumes additional RAM. If the project runs on one server that is the only HMI, switch the project type to Single-User Project in WinCC Explorer > Project Properties. This removes the entire client-server data layer from the runtime and frees 30-80 MB of working set.

Network and Switch Configuration for Industrial Ethernet

Even with the WinCC-side optimizations above, a misconfigured switch can re-introduce partner timeouts. Apply the following on the Industrial Ethernet switches that connect the four PLCs to the server:

1. Use a managed switch (SCALANCE XB-000 / XC-100 / XR-100 class) for the HMI segment. Unmanaged switches drop S7 PDUs under load.
2. Disable Energy Efficient Ethernet (EEE, IEEE 802.3az) on the HMI ports. EEE introduces a 1-2 ms wake-up latency that can exceed the S7 partner watchdog.
3. Enable flow control (802.3x) on the server port only, and configure a small ingress buffer on the switch ports that face the PLCs.
4. Place the four PLCs and the WinCC server in a dedicated VLAN. Broadcast traffic from the office VLAN is the most common source of PDU delay on shared segments.
5. Enable port statistics / RMON on the switch and check for late collisions, CRC errors, and runts. A single bad cable on one PLC port is enough to make that partner the slowest responder and therefore the first to be dropped.

Verification and Commissioning Checklist

After applying the changes, perform the following verification sequence. The runtime is considered stable only when all six checks pass for at least 8 hours of continuous operation.

1. Channel diagnostics clean. In WinCC Explorer > Channel Diagnostics, all four connections show green. No "partner lost" entries in the last 8 hours.
2. TagLogging archive integrity. In WinCC Explorer > TagLogging, the segment is closed cleanly at the configured size. No gaps in the archive timeline.
3. Diagnose log clean. findstr /s /i "disconnect" *.log from the diagnose folder returns no new entries since startup.
4. RAM headroom. In Task Manager > Performance, the WinCC process (CCEs.exe) commits less than 800 MB. The system commit charge is less than 1.4x physical RAM.
5. CPU headroom. In Task Manager > Performance, kernel time + user time averages less than 60 percent of one core over any 5-minute window.
6. Trend display responsive. Switching the trend display between fast and slow archives returns within 1 second. No "trend not loaded" overlay appears.

If any of the six checks fails, return to the diagnose folder and capture the relevant log lines for the failure window. The two most common residual failures are: (a) insufficient RAM (Step 3 not done) and (b) a slow C-Script on a hot path (Knob 1 not applied).

Troubleshooting Matrix for Recurring Partner Drops

Long-Term Migration Considerations

WinCC V6.0 SP3 reached end of active support from Siemens years ago. The patterns described in this article (saturation of 32-bit process, partner watchdog fires, Data Manager thread starvation) are intrinsic to the V6 architecture and reappear in different forms on V7.0 and V7.4 when the same project size is forced onto undersized hardware. If the project is being maintained rather than replaced, the right hardware floor is:

• 2 GB RAM minimum, 4 GB recommended for 4 PLCs and 70 logged tags at 500 ms
• Industrial-grade managed switch (SCALANCE) on the HMI segment
• Windows XP Professional x64 or Windows Server 2003 x64, with the V6 service packs that support x64

For new projects, evaluate WinCC Unified (V18 / V19 / V20) on TIA Portal. The Unified runtime is 64-bit, runs the Data Manager in a separate process from the script engine, and exposes the tag logging layer through a documented JavaScript object model, e.g. TagLogging.LoggedTags(). The architectural separation in Unified removes the single-process scheduler contention that is the root cause of the V6 failure pattern.

Frequently Asked Questions