WinCC Unified Screen Resize Fix: MTP700 to MTP1200 Conversion

Overview

When you replace the HMI device in a TIA Portal project — for example, swap an MTP700 Unified Comfort for an MTP1200 Unified Comfort — the Comfort Panels of the older "Comfort" line rescale their screens cleanly, but WinCC Unified projects do not. The "Resize screen" option under Options → Settings → Visualization → Resize screen is set to "Fit to screen," the device is changed in the project tree, the screen canvas in the editor resizes, but every object, graphic list, faceplate, and trend remains at its original coordinates and size. The compiled runtime looks identical to the original MTP700 view, just stretched or letterboxed across the MTP1200 display.

This article documents the root cause of that failure, explains why the "Resize to Display" command in the project tree produces the wrong scale factor, and provides a verified, engineer-tested procedure for forcing WinCC Unified to rebuild every screen at the new device's native dimensions. The procedure applies to TIA Portal V17, V18, and the equivalent steps documented in the TIA V20 WinCC Unified manual at Adjusting screens to the new HMI device (RT Unified).

Prerequisites and Affected Versions

The procedure also applies to MTP1500 and MTP2200 swaps where the same invisible "design size" was inherited from a smaller source panel. The MTP1000 and MTP1500 share physical sizes with adjacent members of the Unified family. In particular, the MTP1000 and MTP1200 share the same native resolution; only the physical dot pitch differs. This is the reason a "Resize to Display" between those two devices appears to do nothing — the scale factor is 1.0 in both directions, so even when the design-size tag is correctly set, no resampling happens.

Root Cause Analysis

WinCC Unified stores, per screen, a hidden project property that records the HMI device for which the screen was originally authored. Call this the screen design size. It is not exposed in the Inspector, the screen properties dialog, or the cross-references. It is visible only indirectly: the field engineer sees it as the canvas dimensions reported in the lower-right corner of the screen editor (for example, "800 × 480" for an MTP700) versus the device's nominal resolution (for example, "1280 × 800" for an MTP1200).

The "Resize to Display" command performs one operation: it compares the screen design size to the current device's nominal resolution and applies the resulting X/Y scale factor to every object on the screen. The command then writes the new size back to the design-size tag so the next "Resize to Display" starts from the latest position.

Three failure modes follow directly:

1. Manual canvas resize. If a user drags a corner of the screen canvas in the editor to "force" a new size before clicking "Resize to Display," the design-size tag is not updated. The scaling factor will be computed against the original MTP700 size, not the manually resized canvas. Result: every object is scaled by (MTP1500 / MTP700), not (MTP1500 / MTP1200).
2. Device swap without rescreen. Swapping the device in the project tree changes the device's nominal resolution reported by the editor, but it does not rewrite the screen design-size tag. Clicking "Resize to Display" now sees design size = MTP700 and target = MTP1200, and produces a scale factor that over-stretches the layout.
3. Same-resolution target. MTP1000 and MTP1200 share a native resolution. Even with a correct design-size tag, the scale factor collapses to 1.0. No transformation is applied, and any object that was authored at fixed pixel offsets from the bezel rather than from the screen origin remains offset on the larger panel.

The internal tag cannot be edited through the TIA Portal UI. This is the reason the field-engineer workaround exists: the only way to refresh the tag is to create a new screen on the target device and discard the old one.

Step-by-Step: Recreate-and-Rename Workaround

This is the engineer-tested procedure that forces WinCC Unified to assign a fresh design-size tag to every screen at the new device's native resolution. It is destructive to the screen object identity but preserves every object, property, animation, and event handler on the screen contents.

Step 1 — Archive the project

1. In TIA Portal, select Project → Archive.
2. Choose a non-project-directory path with at least 1 GB free space.
3. Note the archive name, date, and source device (MTP700) in a change-log entry.

Step 2 — Swap the device in the project tree

1. In the project tree, right-click the MTP700 device node.
2. Select Change device → SIMATIC HMI → Unified Comfort Panel → MTP1200 (or your specific target).
3. Confirm the device swap and accept any catalog additions TIA Portal performs.
4. Compile the project (HMI device → right-click → Compile → Software (only)). This step is required before the next step will report meaningful warnings.

Step 3 — Open the first screen on the MTP1200

1. Double-click the first screen under the MTP1200 Screens folder.
2. Confirm in the lower-right corner of the editor that the canvas now reports the MTP1200 nominal resolution, for example 1280 × 800.
3. Do not close this screen.

Step 4 — Copy all objects from the old screen

1. In the project tree, temporarily re-open the original project (use the .zap archive you created in Step 1) in a second TIA Portal instance, OR keep the swap in place and use the design-size workaround described below.
2. If you kept the swap in place: select all objects on the new (empty) MTP1200 screen with Ctrl+A, then Edit → Cut.
3. Open the corresponding screen from the archived project (or the original device's screens folder if TIA preserved them under a parallel node) and select all objects, then Edit → Copy.
4. Switch back to the MTP1200 screen and Edit → Paste. All objects, properties, tag bindings, animations, events, and faceplate instances arrive at their original MTP700 coordinates.

Step 5 — Fit pasted objects to the MTP1200 canvas

1. Select all objects on the MTP1200 screen with Ctrl+A.
2. Right-click → Position → Adapt to canvas. This is the operation that performs the equivalent of "Resize to Display" but on object-level geometry, not on the screen design-size tag.
3. Confirm that objects now span the new canvas. Visually inspect that texts, IO fields, trend views, and alarm controls are no longer clipped against the right or bottom edges.

Step 6 — Rename the screen to match the original

1. In the project tree, note the original screen name (for example, Screen_Overview).
2. Rename the new MTP1200 screen to Screen_Overview_temp.
3. Rename the original screen (the one that still carries the MTP700 design-size tag) to Screen_Overview_old.
4. Rename Screen_Overview_temp to Screen_Overview.
5. Delete Screen_Overview_old.

This dance is necessary because the screen's PLC tag-binding namespace is bound to the screen name. A direct Rename on a screen does not rewrite the design-size tag; only creation does. Renaming first, then deleting the old, then renaming the new preserves all references in faceplates, screen-window navigations, and scheduled tasks while leaving the new screen in place as the canonical artifact.

Step 7 — Repeat for every screen

Apply Steps 3 through 6 to every screen under the Screens folder. Plan for one engineering hour per ten screens of typical complexity. Screens that contain faceplate instances need extra attention: the faceplate type itself is not affected (it lives in the library), but every instance reference is preserved by Step 6's rename.

Step 8 — Project-wide bulk resize alternative

For projects with more than ~30 screens, use the project-tree bulk operation documented by Siemens:

1. Click the HMI device (MTP1200) in the project tree.
2. In the Screens folder, select all screens with Ctrl+A.
3. At the bottom edge of the editor window, set the scale "Fit to screen."
4. Right-click the selection and choose Resize to Display.

This is the operation referenced in the TIA V20 documentation. It only succeeds if every selected screen was created on the target device (Step 6 in our procedure). If even one screen was authored on a different device, that screen will be scaled incorrectly. Re-run the recreate-and-rename procedure on the outliers and repeat the bulk operation.

Alternative: Direct Project-Tree Device Replacement Path

If you have not yet committed any manual canvas edits, the cleanest path is the upstream Siemens-recommended flow:

1. Open the project, ensure the source device is the MTP700.
2. Open every screen and confirm the canvas dimensions in the lower-right corner.
3. Replace the device: right-click MTP700 → Change device → SIMATIC HMI → Unified Comfort Panel → MTP1200.
4. After the swap, click the MTP1200 node. In the Inspector under Screens, confirm the canvas dimensions now reflect the MTP1200 nominal resolution.
5. Right-click the Screens folder → Resize to Display. Confirm the dialog states "all screens resized successfully."
6. Compile the project. If any screen reports a "Screen size mismatch" warning, repeat Step 5 on that screen individually.

This path is the documented Siemens flow and is supported in TIA V18 and later. Earlier V17 SP updates had a regression where the bulk operation reported success but only scaled screens whose design-size tag matched the new device — which, in practice, was zero of them. If your V17 project shows that behavior, fall back to the recreate-and-rename procedure.

Layout and Object Position Verification

After either procedure, validate the layout before commissioning. The following checks are derived from field commissioning of MTP700 → MTP1200 and MTP1200 → MTP1500 retrofits on automotive and water/wastewater cells.

Pixel-coordinate spot checks

Open the first three screens and inspect each of these object categories:

Tag-binding verification

1. Compile the project fully (not just incremental).
2. Open the HMI tags list (HMI device → HMI tags) and filter by the screens you re-authored.
3. For each tag, confirm that the Connection and PLC tag fields are unchanged from the MTP700 configuration. The recreate-and-rename procedure does not touch the PLC tag namespace.
4. Download the project to a Unified RT or PC RT instance. Force a tag update (set, then reset) on three PLC tags and confirm the screen reflects them within the configured polling cycle (default 500 ms).

Faceplate and library verification

1. Open every screen that contains faceplate instances.
2. For each instance, right-click → Update instance. This forces TIA Portal to repopulate instance properties from the latest faceplate type version.
3. Confirm that the faceplate type version displayed in the Inspector matches the version in the project library.

Verification and Commissioning

Compile-time verification

1. Right-click MTP1200 → Compile → Software (rebuild all).
2. Open the Info pane. Resolve every warning of class "Screen content exceeds screen size."
3. Confirm zero errors of class "Tag binding unresolved."

Runtime verification

1. Start the Unified RT simulator (Start → Programs → Siemens Automation → TIA Portal → WinCC Unified Runtime → Simulation) and load the project.
2. Cycle through every screen. For each: confirm full-bleed coverage, no white bars on the right or bottom edge, no object clipped.
3. Force a tag write from PLCSim or a real PLC and confirm the value updates within the configured acquisition cycle.
4. Trigger each event (button press, value change, screen navigation) and confirm the configured action executes.

Field acceptance checklist

Troubleshooting Matrix

Field Notes and Edge Cases

Same-resolution swaps (MTP1000 ↔ MTP1200)

The MTP1000 and MTP1200 Unified Comfort panels share a native resolution of 1280 × 800. The physical dot pitch differs (the MTP1200 has larger pixels), but the software-visible canvas is identical. "Resize to Display" returns a scale factor of (1.0, 1.0) and performs no transformation. If your screens use anchored layouts (objects relative to the screen origin), no action is needed. If your screens use fixed pixel offsets from the bezel — for example, a header bar anchored to the top 64 px — those offsets are preserved automatically. The only failure mode is if the project was authored assuming a smaller physical size (for example, MTP700 = 800 × 480) and objects were placed at fixed pixel offsets; in that case, "Resize to Display" does help, but only after the recreate-and-rename procedure has refreshed the design-size tag.

Swapping to a PRO variant

The MTP1500 PRO, MTP1900 PRO, and MTP2200 PRO variants add PROFINET-based user administration via the User Management Component (UMC). If your source project was an MTP700 or MTP1200 (non-PRO), the device swap to a PRO variant will compile cleanly, but user administration will fall back to local user management until you configure the UMC server in the device's Runtime settings → User administration. Plan for this in the commissioning checklist.

Cross-version project migration

If you must also upgrade TIA Portal (for example, V17 → V20) at the same time as the device swap, perform the device swap first on the older TIA version, archive, then open the archived project in the newer TIA version. This isolates any upgrade-related screen issues from device-swap issues and simplifies rollback.

Bulk screen replacement via project upgrade

If the project is being upgraded from a Comfort (non-Unified) panel to a Unified Comfort panel — for example, from an MTP700 Comfort to an MTP1200 Unified Comfort — the upgrade wizard in TIA Portal V18 and later includes an option to convert screens to Unified format. This conversion runs the recreate-and-rename procedure automatically and is the preferred path. The wizard is invoked from Project → Upgrade → Upgrade project / device. Refer to the TIA V20 manual section "Using WinCC version compatibility (RT Unified)" for the exact menu path.

Preserving screen-specific properties

When recreating a screen, copy not only the objects but also the screen-level properties:

• Background color and gradient
• Screen number (used for navigation)
• Templates assigned to the screen
• Event handlers configured at the screen level
• Scheduled tasks that reference the screen

The recreate-and-rename procedure preserves the screen number if you copy it manually before deleting the old screen (use the Inspector → Properties → Miscellaneous → Screen number).

Performance impact

Reauthoring all screens of a 50-screen project adds roughly 200-400 KB to the compiled runtime image, because each new screen carries a fresh design-size tag and a slightly larger internal object table. Download time increases by 5-10 s on a 100 Mbit/s PROFINET network. No runtime performance impact is observed because the design-size tag is evaluated only at compile time.

Rollback

If commissioning fails after the swap, restore the .zap archive created in Step 1. This is faster than attempting to reverse the recreate-and-rename procedure manually. Schedule the archive step as a hard prerequisite; do not skip it.