Resolving WinCC Flexible 2007 MP 277 Project Size Exceeds 6 MB

Problem Overview

When configuring a Siemens MP 277 10" Touch Multi Panel with WinCC Flexible 2007 HF5 (or SP1–SP3), engineers frequently encounter the following error during compilation or download:

The configuration memory size is greater than allowed (6,291,456 bytes).

This hard limit corresponds to 6 MiB (6 × 1024 × 1024 bytes) of compiled project data that the panel's runtime can load. Exceeding this limit prevents the .fwx file from being written to the panel, blocks simulation transfer, and is the most common blocker on long retrofit or migration projects with 150–250 screens, dense faceplate libraries, and many HMI tags.

This article breaks down where the bytes are consumed, what to do first, and the verification steps that confirm the rebuilt project fits inside the 6 MB envelope on the MP 277 10" Touch (6AV6 643-0CD01-1AX1) hardware platform.

MP 277 10" Touch Memory Architecture

Understanding where the 6 MB limit comes from is critical before touching any project file. The MP 277 10" Touch uses a fixed image memory partition reserved for the compiled WinCC Flexible project. The remaining internal flash is consumed by firmware, options, and the operating system image (Windows CE 5.0).

The 6,291,456-byte ceiling is enforced at three points: when you press Compile → Rebuild All in WinCC Flexible, when transferring the project via ProSave/Ethernet, and when the panel boots and verifies the .fwx integrity. Compression on the panel does not increase this ceiling; it is the uncompressed, pre-packing image data plus the configuration database that the runtime loader has to map.

Root Cause: Where the 6 MB Goes

A typical MP 277 project on WinCC Flexible 2007 HF5 distributes its bytes roughly as follows:

In the case described, the project contains roughly 200 pictures at 3 MB, plus an oversized faceplate library and dense tag layout. The 3 MB picture block alone is therefore 47% of the budget, leaving little headroom for everything else. The fastest, highest-leverage fix is the graphics layer.

Image Format Conversion: BMP and PNG to JPG

BMP is an uncompressed raster format. A full-screen 640 × 480 background at 24-bit color weighs 921,600 bytes per image. A 200-screen project full of BMPs is mathematically incapable of fitting in 6 MB. PNG is lossless and is sometimes unavoidable (it is the only one of the three that supports an alpha channel/transparency), but for a 200-picture MP 277 project, 24-bit PNGs are typically larger than 24-bit JPGs of equivalent visual quality.

Conversion procedure:

1. Open the picture in an editor (IrfanView, GIMP, Photoshop, or the WinCC Flexible Graphics Designer).
2. Resize the bitmap to the on-screen pixel footprint. A 1024 × 768 photo scaled down to 640 × 480 before JPG encoding is typically 4× smaller than the same source encoded at native resolution and downscaled in the HMI.
3. Re-save as JPG at quality 75–85. Use a JPG compressor such as jpegoptim or the Save for Web dialog to strip metadata.
4. Use PNG-8 indexed only where the image must be partially transparent (button states, indicator overlays, motor/valve symbols). WinCC Flexible fully supports the alpha channel of 8-bit indexed PNG.
5. Replace the file in the project; WinCC Flexible will use the new file at next compile. Confirm that the file name and extension match what is referenced in screen objects.

Reducing Number and Size of Screens

After format conversion, look at the screen count itself. Two hundred screens on a 10" operator panel is often the result of "screen-per-equipment-item" design from a SCADA mindset, not a panel mindset. MP 277 10" Touch is not a SCADA; the operator area is 640 × 480.

• Group similar process units into a single screen with a tab or navigation bar instead of one screen per motor or valve.
• Use pop-up screens for sub-detail (faceplate content, motor start/stop detail) so the underlying navigation screen is not duplicated.
• Replace static background pictures with vector graphics (WinCC Flexible supports lines, rectangles, polygons, arcs, polylines) drawn natively. A 10 KB polyline of a tank is effectively free.
• Delete unused screens: in the project tree, screens that are not referenced by area pointers, start screen, or ActivateScreen function calls can be deleted. WinCC Flexible does not warn about orphan screens; check the Cross References tool before deletion.
• Strip EXIF / metadata from JPGs and PNGs; some camera tools add 30–100 KB of EXIF and ICC profiles that contribute to the compiled size.

Faceplate and Template Optimization

Faceplates are the MP 277's strength and its silent memory consumer. Each instance of a faceplate is replicated into the compiled project; a faceplate with 15 properties used 60 times is 60 copies of the template structure in the project file. Optimization is therefore multiplicative.

A 50-instance faceplate at 6 KB each = 300 KB. Halving that to 3 KB by removing an embedded PNG and converting to vector is a 150 KB saving — more than the entire log and alarm configuration.

Tag Database Optimization

Tag count is rarely the dominant byte consumer on MP 277, but 3,000 tags with default acquisition settings can quietly add 200–400 KB. Tactics:

• Increase the acquisition cycle for tags that are not displayed continuously. Default is 1 s; raising to 2 s or 5 s reduces update traffic but does not directly reduce project size — use multiplexing for size reduction.
• Use tag multiplexing: with WinCC Flexible, define a single tag and reassign its address or area pointer to switch the active tag. Combined with indexed PLC DBs, one tag can serve 50+ display points.
• Remove unused tags: WinCC Flexible does not always prune unreferenced tags. Sort the tag list by last used or use the Check Consistency tool with the Remove Unused option.
• Limit tag limits per PLC connection: an S7-300/400 with too many symbolic tags can blow the area pointer budget. Cap symbolic tags to the required set.
• Convert S7 string tags to fixed-length WString only when multi-byte support is required. WString tags are 2–4× the byte cost of equivalent WChar[16] tags.

Alarm and Logging Optimization

Each discrete alarm is approximately 80–200 bytes of compiled configuration. A 500-alarm project therefore consumes 80–100 KB; an audit-trail / 1500-alarm project can exceed 250 KB. The MP 277 has fixed limits on the alarm buffer (512 active messages, 1,024 archive entries typically) and the compiled project must describe each alarm class, each trigger, and each acknowledgment logic.

• Group similar alarm conditions into alarm classes with shared attributes (priority, group, acknowledge strategy) instead of per-alarm overrides.
• Disable history/archive for alarm classes that are pure status (e.g., "operator logged in").
• Reduce the number of alarm rows in the alarm view; default 1000 rows consumes significantly more compiled configuration than 200 rows.
• Convert alarm acknowledgement buttons to soft keys on the screen and remove redundant F-keys if they are alarm-related.

Project-Wide Settings: Compiler, Languages, Recipes

Several project-level toggles have an outsized effect on compiled size:

Disable languages under Project → Language Settings → Active. Each active language copies every text in the project to a separate text table; the MP 277 supports 5 runtime languages maximum, but every language you do not need adds 5–15% to the project.

Verification: Compiling and Confirming Size

After each batch of changes, run a clean compile and read the output window carefully. The relevant messages are Compile (Compile OS), elapsed time: …, image size: … / 6291456 bytes.

1. In WinCC Flexible, choose Project → Compiler → All (Rebuild). The lower output panel will show the final image size in bytes.
2. Confirm the result is strictly less than 6,291,456 bytes. A safety margin of 200–500 KB is recommended to allow for later commissioning additions (an extra trend view, an extra language flag, a new recipe view). The runtime reserves some memory for dynamic expansion; do not run at the ceiling.
3. Open Project → Size Estimator (available in SP2+) to break down the project by element. This tool enumerates picture bytes, faceplate bytes, tag bytes, and alarm bytes independently.
4. Transfer the rebuilt .fwx to the panel using Transfer → Configuration in ProSave or directly via the WinCC Flexible Transfer tool. The panel reports Transfer successful only if the size fits the partition.
5. Boot the panel and confirm the start screen loads; the runtime will display Configuration error: image too large only if the panel's own check fails. A green Transfer OK on the host side is necessary but not sufficient — always verify the panel boots.

Troubleshooting Matrix

When to Migrate Instead of Optimize

If after exhausting all of the above the project still hovers at 5.8–6.0 MB with a clear roadmap of additional screens, alarms, and trends, optimization alone is not the right answer. Plan a migration:

• Upgrade to a Comfort Panel (TP700 / TP900 / TP1200 in TIA Portal) where the image ceiling is 12–24 MB depending on the model.
• Migrate to WinCC Comfort / TIA Portal V13+; the new compiler produces smaller compiled images for the same logical content because of delta encoding and improved faceplate instantiation.
• If a Comfort Panel is not an option, the MP 377 12" Touch with 12 MB project image is a drop-in replacement for the MP 277 10" in many cabinets.

Each of these migration paths requires a new TIA Portal project (WinCC Flexible projects do not import cleanly to TIA for very old image formats), and PLC tag structures should be verified against the new symbol interface. Budget two to five engineering days for a 200-screen migration with regression testing.

Field-Proven Compression Workflow

The following sequence, applied iteratively, will take most MP 277 10" Touch projects from 7–9 MB back to a comfortable 4–5 MB:

1. Inventory the bytes: run the WinCC Flexible Size Estimator. Rank picture files by total bytes.
2. Convert top 20 largest pictures to JPG quality 80, resized to 640 × 480 (or smaller if the original is 320 × 240).
3. Re-save all PNGs through optipng -o7 or equivalent lossless optimizer; this typically shrinks 24-bit PNGs by 20–30%.
4. Consolidate faceplate instances: identify the top 3 most-used faceplates and reduce their embedded graphics.
5. Disable secondary languages not in active commissioning scope.
6. Re-build and re-measure; iterate on the top contributors until a 30% safety margin is achieved.