Fix WinCC Flexible 2005 'No Data Exchange with PLC' Overflow

David Krause18 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

Engineers configuring scheduled tasks in WinCC Flexible 2005 (SP2 Hotfix 4 and earlier 2005 service packs) on a SIMATIC panel such as the OP 177, TP 177, MP 277, or PC Runtime frequently encounter the runtime alarm:

Overflow - No data exchange with the PLC

The fault is recorded in the HMI device's alarm buffer. In many field cases the HMI stops updating tags, forces the operator to acknowledge the message, and blocks further scheduled execution even though the physical MPI link is intact. The HMI is not actually disconnected; the polling demand of a mis-configured scheduler combined with graphical or tag overhead has starved the communication driver.

This article documents a field-proven diagnostic and repair sequence for systems communicating exclusively over MPI (187.5 kbit/s or 1.5 Mbit/s) with no PROFIBUS DP port available, and where the error condition does not clear after the offending scheduled task is removed from the project.

Reference: Siemens Industry Online Support entry for WinCC Flexible 2005 system manual, search ID 18796052.

Symptoms and Error Context

Operators typically observe one or more of the following conditions:

  • The "Overflow - No data exchange with the PLC" message appears in the message window with a red background and stays latched until acknowledged.
  • All polled tags stop updating, while the panel's date/time continues to refresh because the area pointer for date/time is generated locally on the panel and does not require a PLC round-trip.
  • Scheduled tasks stop firing even though the scheduler's trigger condition is satisfied.
  • The message reappears at intervals that match the configured acquisition cycle of a high-frequency tag.
  • Removing the suspect scheduled task from the project and re-transferring does NOT clear the error; it reappears on the next runtime start.
  • A hard power cycle of the panel does not clear the alarm - the entry survives the boot sequence because the runtime reads the alarm buffer from non-volatile storage on the panel.

The "does not clear after deletion" behaviour is a strong indicator that the project itself - not the live scheduler instance - is in an inconsistent state. WinCC Flexible 2005 stores the compiled runtime file (typically *.fwx) on the panel's flash file system. A new transfer with the "Overwrite all files" option is required to replace that image; deleting a schedule inside the project only marks the change in the source file, not in the already-deployed runtime image.

Root Cause Analysis

Four interacting mechanisms are responsible for the error. Each must be examined during the diagnostic walk-down.

2.1 MPI Bandwidth Ceiling

MPI is a master-slave token bus operating at a default of 187.5 kbit/s. Even on a 1.5 Mbit/s segment, each HMI-to-PLC round-trip requires an RS-485-equivalent frame exchange and bus access is serialized. Practical field measurements show that an OP or MP panel at 187.5 kbit/s cannot sustain more than roughly 60-100 tag polls per second when each tag is 4 bytes wide. The bus capacity can be approximated as:

Sustainable_polls_per_s ≈ (baud_rate / (frame_bits + 11_bits_overhead)) / N_nodes

where frame_bits is approximately 11 bits per byte transmitted. At 187.5 kbit/s with two active nodes (HMI and S7 CPU), the ceiling sits near 80 polls per second, which any project with 200+ tags at 250 ms acquisition will exceed on the first runtime boot.

When the bus saturates, the HMI's internal communication FIFO (256 entries in WinCC Flexible 2005) fills. The driver thread stalls, the runtime raises the "Overflow" message, and any further tag requests are dropped until the queue drains.

2.2 Scheduler Trigger Amplification

A scheduled task in WinCC Flexible 2005 is configured under the "Schedules" node in the project tree. Each task has a trigger (time-of-day, tag-value, or event) and an action list of system functions such as SetBit, SetTag, ActivateScreen, Calculate, and StartLogging. When the trigger fires, the runtime executes the action list synchronously inside the communication task.

If the action list writes a tag that is itself part of a tightly-loopbacked trigger (for example, SetTag "PumpCmd" feeding a scheduler that re-triggers on the same tag change), the HMI enters a self-induced polling storm. Each SetTag generates a write cycle that competes with the read cycles the rest of the screen needs. WinCC Flexible 2005 does not serialize tag writes through the same FIFO the read polling uses, so the buffer can grow past the 256-entry threshold before the driver drains it. The "Overflow" message is raised as soon as the buffer's high-water mark is crossed.

2.3 Graphics and Bit-Cache Pressure

Each screen contains a list of graphic objects; each object is associated with tags and animations. A high-resolution bitmap (≥ 800×600, 24-bit, uncompressed) referenced from a screen-load event triggers a large memory copy and a sustained draw cycle that pre-empts the communication thread on panels with limited CPU bandwidth. The OP 73, OP 77A, and TP 177A all run on a 200-400 MHz class RISC core with no dedicated graphics accelerator.

When a scheduler fires a screen change to a graphics-heavy screen, the communication thread can be starved for tens to hundreds of milliseconds; the next round of tag polls is queued; the queue overflows. WinCC Flexible 2005 does not deduplicate bitmaps in the runtime image, so a logo pasted on every screen multiplies memory pressure by N (the number of screens referencing it).

2.4 Cable Routing and EMC

While software causes dominate, the original report's diagnostic path correctly flagged cable routing. A PROFIBUS/MPI cable routed parallel to a VFD output cable (≥ 50 mm clearance violated) or past a switching power supply introduces CRC errors on the link. The driver treats CRC errors as transient and retries; the retry load further inflates the queue. The same "Overflow" message is raised by the driver when its internal retry counter exceeds the configured threshold (default 3, configurable in the HMI device's "Connection > Properties" dialog).

Diagnostic Procedure

Work through the following in order. The sequence eliminates environmental causes before touching the project, because environment fixes are cheaper and reversible.

  1. Capture the panel's alarm buffer. Connect ProSave or WinCC Flexible's "Transfer > Backup" to the panel and download the *.log and *.bff backup files. Open the log in a text editor; entries of the form [Overflow] ... retry=N ... qd=248/256 confirm the buffer-overflow interpretation. Record qd (queue depth) - if it equals the maximum (typically 256) the queue is saturated.
  2. Inspect the project in WinCC Flexible 2005. Open the project, go to "Project > Cross References" and list every tag used by the "Schedules" node and the screens invoked by the scheduler. Look for tag values written by the scheduler that are also used as scheduler triggers - this is the loopback case in 2.2.
  3. Reduce the test surface. Disable every scheduled task (un-tick the "Active" check-box on each schedule). Transfer the project with "Overwrite all files". If the error disappears, a scheduler is the trigger; re-enable them one at a time to isolate the offender.
  4. Measure bus load. If a PROFIBUS diagnostics tool is available (e.g., Amprolyzer, InPro, or a Siemens BT 200), attach it to the segment and observe the bus utilization while the scheduler fires. Sustained utilization above 70% is the operational ceiling; above 85% the driver is in saturation and the Overflow alarm is imminent.
  5. Verify cable routing. Visual inspection of the MPI cable path. A 200 mm minimum clearance from any VFD output or three-phase power conductor is recommended per the SIMATIC panel installation guide.
  6. Capture a STEP 7 online diagnostic. In STEP 7, open the S7 CPU's diagnostic buffer and the "Communication" statistics. A high count of "Communication error" or "Frame error" events within the period the Overflow message was raised confirms the EMC contribution.

Resolution Steps

After diagnostics, apply the fix in this order. Each step is independently verifiable.

3.1 Cable and EMC Audit

Re-route the MPI cable to maintain ≥ 200 mm separation from any VFD motor cable, and use a shielded PROFIBUS cable with a 360° bonded back-shell at both ends. Verify the shield drain wire is landed at the panel's PE stud, not at a signal ground. If the panel's MPI connector shows corrosion or repeated insertion cycles, replace the connector with a new 9-pin D-sub PROFIBUS connector (Siemens part number 6ES7972-0BA12-0XA0) and re-terminate. Add a PROFIBUS terminator (6ES7972-0DA00-0XA0) at each end of the segment if the existing terminators are missing or have aged out of spec.

3.2 Graphics Optimization

Convert any bitmap larger than 320×240 to either an indexed-colour PNG (≤ 256 colours) or, preferably, to a vector symbol from the WinCC Flexible "Graphics" library. Remove copy/paste duplicates of complex graphics; WinCC Flexible 2005 does not deduplicate bitmaps in the runtime image, so a logo pasted on every screen multiplies memory pressure by N. Move any startup or scheduler-invoked screen to a "light" screen containing only the tags the scheduler needs to read or write.

For graphics-heavy start screens, consider replacing the bitmap with a vector ring buffer or a "Symbol" IO field that draws at runtime from a tag's value, eliminating the bitmap memory footprint entirely.

3.3 Tag and Area Pointer Audit

Open "Communication > Tags" and sort by acquisition cycle. Tags polled at 100 ms should be the exception, not the rule. Increase the cycle for every tag that does not need 100 ms update responsiveness to 500 ms or 1000 ms. For each scheduler-driven SetTag, confirm the destination tag is not itself polled at a faster cycle than the scheduler fires; if it is, raise the polling cycle to match.

Reduce the number of area pointers configured. Each area pointer (Date/Time, Coordination, Job Mailbox, Data Record, Project ID, etc.) consumes bus time. Disable any pointer that is not actually consumed by the HMI logic. A typical minimal configuration for a WinCC Flexible 2005 panel is:

  • Date/Time (1 word read, 8 bytes write every cycle)
  • Coordination (1 byte, used for life-bit and area-pointer-handshake)
  • Project ID (1 word, used to verify the connected PLC project)

Disable the Job Mailbox pointer unless a PLC job (e.g., ReadDataRecord, WriteDataRecord) is actually issued by the HMI logic. Each pointer disabled reduces the per-cycle bus load by approximately 8-16 bytes per direction.

3.4 Scheduler Configuration Review

Open "Schedules". For each schedule, apply the following corrections:

  • Replace any SetTag on a tag used as the schedule's trigger with a direct bit-write to a PLC bit and let the PLC handle the loopback. The PLC returns the new value on its normal scan, and the HMI reads it at its normal polling cycle rather than triggering a fresh write per scheduler fire.
  • If a script is required, prefer a single Calculate function over a chain of SetTag calls. Each SetTag is a separate bus transaction.
  • Add a minimum-interval guard: most schedulers in WinCC Flexible 2005 have an "Update" field; set it to "Once" or "Cyclic > 1 s" to debounce high-frequency triggers.
  • Defer screen changes: do not invoke ActivateScreen from a scheduler that fires more often than the screen redraw itself (typically 500-1000 ms).
  • Do not start logging from a high-frequency scheduler; StartLogging allocates a circular buffer in the panel's flash file system, and repeated start/stop cycles fragment the file system and slow subsequent writes.

3.5 Project Compilation Rebuild

This is the critical step for the "error persists after deleting the schedule" case. WinCC Flexible 2005 retains a compiled runtime image; simply editing and saving the project does not always invalidate the cache. Force a clean rebuild:

  1. Project > Compiler > All > Rebuild All - regenerates the *.fwx image from source.
  2. Project > Transfer > Transfer to HMI device - enable "Overwrite all files". If the panel supports it, enable "Reset HMI device to factory settings" to clear the alarm buffer as part of the transfer.
  3. On the panel, perform a hard reset - power cycle after holding the Service button for 5 seconds where applicable, or use ProSave's "Reset to factory settings" option. On OP 77A and TP 177A this clears the alarm buffer; on PC Runtime, restart the Runtime service.

The hard reset clears any stale alarm entries and re-initializes the communication driver state machine, which is where a "stuck" Overflow condition is latched. A simple power cycle is not always sufficient because the alarm buffer is stored in non-volatile memory; only the factory reset or a deliberate ProSave "Clear alarm buffer" operation removes it.

Edge Cases by Controller Family

The diagnostic path varies by which SIMATIC controller is on the other end of the MPI segment.

4.1 S7-200 over PPI/MPI

The S7-200 CPU (e.g., CPU 224 XP, CPU 226) connects to a WinCC Flexible 2005 panel via PPI at 9.6 kbit/s or 19.2 kbit/s in the lowest baud-rate modes. The bus ceiling collapses to under 20 polls per second. The Overflow message can appear on any project with more than 50 tags polled at 1 s cycle. The fix requires reducing tag count, raising cycles to 2-5 s, and disabling the Job Mailbox pointer, which the S7-200 does not implement but WinCC Flexible 2005 may still try to handshake on if enabled.

4.2 S7-300 and S7-400

These are the canonical targets. MPI at 187.5 kbit/s is the typical configuration. The driver handles the standard area pointers natively. The Overflow typically traces to a scheduler loopback or a high-resolution graphics load. The fixes in 3.1-3.5 apply unchanged.

4.3 LOGO! 0BA6 / 0BA7 / 0BA8

LOGO! communicates with WinCC Flexible 2005 over Ethernet, not MPI, in current revisions. The Overflow message can still appear if the LOGO! is on a shared Ethernet segment with broadcast traffic. The fix is to assign a static IP to the LOGO! and to the panel, disable the panel's PROFINET discovery broadcast, and reduce the tag count to under 30 (LOGO!'s internal VM area is small and a high tag-polling rate can saturate the LOGO! side rather than the HMI side, raising the same alarm in the HMI).

4.4 S7-1200 (Compatibility Note)

WinCC Flexible 2005 does not natively support the S7-1200. The S7-1200's optimized block access (which hides the absolute address layout) breaks the tag-address model that WinCC Flexible 2005 relies on. If a WinCC Flexible 2005 panel is forced to communicate with an S7-1200 over MPI (e.g., through a DP/DP coupler or a third-party gateway), the Overflow message is almost certain and cannot be remediated by project tuning; the migration to TIA Portal WinCC Comfort or Professional is the only sustainable fix. For migration procedures, refer to the Siemens migration portal and the entry "Migrating WinCC Flexible projects to TIA Portal".

Verification

Confirm the fix in three independent ways:

  1. Alarm buffer check. Operate the panel for a full shift with the previously-failing schedule active. The alarm buffer should be free of "Overflow" entries. Use the panel's "Messages > Alarm buffer" view or download the buffer via ProSave.
  2. Tag update latency. Force a value change in the PLC (e.g., toggle a bit in STEP 7 Monitor/Modify) and time the change's reflection on a screen. With the fix in place, latency at 187.5 kbit/s should be below 1.5× the configured acquisition cycle.
  3. Bus load measurement. Re-attach the bus diagnostics tool. Average utilization should be below 60% during normal operation and below 75% at the scheduler's peak fire rate.
  4. Cold start test. Power cycle the panel and confirm the Overflow message does not reappear within the first 30 minutes of operation. A failure here indicates a residual issue in the project, not a transient bus event.

Preventive Best Practices

  • Default to 1 s acquisition cycle. Anything below 250 ms is a "fast" tag and should be justified per-tag.
  • Limit the Schedules node. Fewer than 10 active schedules per panel is a healthy ceiling. Anything more should be consolidated into PLC logic and triggered by a single HMI-side scheduler that calls one script.
  • No bitmaps > 320×240. Anything larger belongs on a PC Runtime, not a panel.
  • Separate bus segments. If the application grows beyond 200 tags or three operator panels, deploy a DP segment or an Ethernet/PROFINET link rather than overloading a single MPI segment.
  • Maintain the cable path. A documented cable schedule and a visual inspection during every scheduled PM walk prevents the EMC regression that re-introduces CRC retries.
  • Version-control the project file. Use the source project's MD5 hash to confirm that the transferred runtime is the rebuild target; otherwise an old *.fwx can be deployed by mistake.

Safety and Operational Checks

Before clearing the alarm buffer or re-enabling a previously-failing scheduler, perform these checks:

  • Confirm the controlled equipment is in a safe state. A scheduler that fired a SetBit "MotorStart" just before the Overflow will leave the bit in its last-written state; verify the controlled device is not in a runaway condition.
  • Confirm the PLC's logic does not depend on the HMI's life-bit (Coordination pointer) for safety. If it does, a panel that has stopped polling due to overflow will be flagged as "not alive" by the PLC, and the PLC should be designed to fail-safe on a life-bit timeout.
  • Confirm that any logging started by the scheduler is stopped cleanly. An interrupted log on the panel can corrupt the CSV file on the flash file system; ProSave can recover the file but the in-progress records are lost.

Related System Functions and Parameters

The following system functions are commonly misused in the Schedules node. Verify spelling and signature against the WinCC Flexible 2005 system manual:

Function Common misuse Recommended guard
SetTag Used to loop back into a schedule trigger Write to a PLC bit, let the PLC return the value
SetBit / ResetBit Pulsed too fast; bus saturates with single-bit writes Aggregate flags into a word and use SetTag on the word
ActivateScreen Called from a sub-100 ms scheduler Add a 1 s minimum interval or convert to operator event
Calculate Long arithmetic expression run inside the comms task Off-load to a PLC function block; call from HMI only when input changes
StartLogging / StopLogging Started every scheduler cycle Use a one-shot trigger; do not restart a running log
ReadDataRecord / WriteDataRecord Triggered from a high-frequency scheduler Trigger only on operator input or on a rising edge of a slow tag

Polling-related properties of the HMI device (open in the project tree, "Properties > Communication" tab):

  • Acquisition cycle (default 1 s): The minimum polling interval the runtime uses for any tag not given an explicit cycle. Lower values widen the bus load.
  • Retry count (default 3): The number of CRC-retry attempts before a "No data exchange" message is raised. Set to 5 only on segments with known but acceptable interference.
  • Communication buffer size: Not user-tunable in 2005 SP2 (256 entries); upgrade to WinCC Comfort/Professional or TIA Portal to access a larger buffer (1024 entries).
  • Timeout (default 3 s): The interval after which the runtime considers the PLC "not alive" and raises the alarm. Tighten to 1 s only if a faster failure detection is operationally required; loosening to 5 s masks intermittent CRC errors.

FAQ

Why does the "Overflow - No data exchange with the PLC" error stay on screen even after I delete the scheduled task in the project?

WinCC Flexible 2005 compiles the project into a runtime image that is transferred to the panel; the live alarm buffer on the panel retains the latched overflow state until the runtime is re-initialized. Perform a clean Rebuild All in the compiler, transfer with "Overwrite all files", and perform a hard reset (or ProSave factory reset) on the panel to clear the latched state. A simple power cycle does not clear the alarm buffer on most OP/TP panels.

I do not have a DP port - only MPI. Can I still use the scheduler?

Yes, but at 187.5 kbit/s MPI the scheduler's actions compete with all tag polling for bus time. Keep the scheduler action list short (fewer than 5 functions), avoid writing to tags that are also polled at sub-second cycles, and target fewer than 200 active tags on the panel. At 1.5 Mbit/s MPI the budget roughly triples, but the same discipline applies.

How do I measure MPI bus load without a PROFIBUS analyser?

Enable the diagnostic LEDs on the panel's MPI connector (if fitted) and count the blink rate, or use the S7 diagnostic functions in STEP 7 to read the PG/OP communication statistics. As a quick check, set a tag with a 100 ms acquisition cycle and verify the value is updating on the screen; if it lags by more than 150 ms, the bus is saturated.

What is the maximum number of scheduled tasks I should configure on a single panel?

Empirically, fewer than 10 active schedules per panel is a healthy ceiling for an MPI segment. If the application requires more, consolidate the logic into a single scheduler that calls one script, or move the time-driven logic into the PLC and use the HMI scheduler only for HMI-specific actions such as screen changes.

Does upgrading to TIA Portal / WinCC Comfort resolve the overflow permanently?

Upgrading increases the communication buffer to 1024 entries and improves the driver thread priority, which reduces the incidence of overflow but does not eliminate the underlying bus load. The same diagnostics - tag count, scheduler loopback, graphics pressure, and cable routing - still apply. Migration also requires re-addressing tags if the original WinCC Flexible 2005 project used symbolic addressing that TIA Portal does not import 1:1.

Can an S7-1200 be connected to a WinCC Flexible 2005 panel over MPI?

Not directly. The S7-1200 does not support MPI and does not expose the absolute memory layout that WinCC Flexible 2005 requires. A DP/DP coupler or a third-party gateway can bridge the two protocols, but the resulting bus load and the lack of native S7-1200 area-pointer support make the Overflow alarm almost certain. The supported migration path is to move both the PLC project and the HMI project to TIA Portal.

Back to blog