Resolving MP 370 Touch Ethernet Communication Failures

Overview: MP 370 Touch Ethernet Project Transfer Failure

The SIMATIC Multi Panel MP 370 Touch is a Windows-CE-based HMI platform that supports project transfer over Ethernet from a programming PC running WinCC flexible (2004 SP1 or later, including WinCC flexible 2007/2008). A common field symptom is that the programming PC can ping the MP 370 IP address successfully, but the WinCC flexible "Transfer" command terminates with a connection error and no project is downloaded. The most frequent root cause for this specific symptom is an incorrect default gateway configured on the panel or on the engineering station.

This reference covers the diagnostic path for the 12" Touch, 15" Touch, and 12" Key variants of the MP 370 family, the correct TCP/IP parameters, the WinCC flexible transfer channel configuration, the Control Panel / OP properties checks, and the conditions that require an OS update prior to a project download. The procedure applies to Ethernet-only transfer (EtherNet/PROFINET MAC on the MP 370) and to PROFINET-based variants where the same Windows-CE network stack is used.

MP 370 Touch Hardware and Network Specifications

The relevant electrical and network characteristics for the MP 370 Touch (per the SIMATIC HMI MP 370 (WinCC flexible) operating instructions) are summarized below. The delivery release for the 12" Touch and 12" Key variants is documented in Siemens Support entry 6811127.

The MP 370 does not ship with a static IP address. The first commissioning step is to set the IP address, subnet mask, and gateway on the panel itself, or to use ProSave to assign them across an Ethernet link. Without a valid gateway on both endpoints, the engineering PC may still answer ICMP echo (ping) for the local subnet, but TCP/UDP transfer of the WinCC flexible project will hang at "Connecting to target..." because the panel's stack rejects the handshake.

Root Cause Analysis: Why Ping Succeeds but Transfer Fails

ICMP echo (ping) only confirms Layer-3 reachability inside the local subnet. The WinCC flexible transfer service uses TCP port 1025 (or the port specified in ProSave) and the Siemens S7WEBCnxOPC protocol for booting/project download. A ping-reachable host that is not configured for project transfer will still fail the higher-layer handshake. The most common root causes, in order of frequency, are:

1. Wrong default gateway on the MP 370 or the PC. The panel may boot, accept the ping reply, but its routing table has no path to the PC outside the local subnet if any NAT or address-translation is present.
2. Mismatched subnet mask between PC and panel (e.g., 255.255.255.0 on PC, 255.255.0.0 on panel) makes ARP and the TCP handshake fail even though ICMP echo appears to round-trip during a brief window.
3. Transfer channel in WinCC flexible not set to "Ethernet" or not pointing at the panel's IP.
4. Control Panel > OP Properties > Transfer on the MP 370 has transfer disabled, or the channel "ETHERNET" is unchecked.
5. OS version mismatch: the compiled project targets a Windows CE image newer than the image on the panel. WinCC flexible prompts for an OS update, which the user declines, so the transfer aborts.
6. Firewall on the engineering PC (Windows XP SP2+, Windows 7+) blocks inbound responses on the transfer port.
7. Duplicate IP address on the LAN: another device holds 192.168.1.30, and the panel's responses are not reaching the PC consistently.

Prerequisites for Ethernet Transfer to MP 370

Before starting the transfer, validate the following prerequisites. Each must be confirmed individually; a single missing item reproduces the "ping-OK, transfer-fail" symptom.

• WinCC flexible 2004 SP1 or later installed on the engineering station. The version must support the MP 370 image type (CE 3.0 / CE 5.0 / XPe). For XPe panels, ProSave is used directly.
• A crossover or straight-through Cat5/Cat6 cable (MP 370 supports Auto-MDIX on the integrated RJ45). When connecting PC-to-panel directly, either cable type works; when connecting through a switch, use straight-through.
• The PC and the panel must be on the same IP subnet. For a typical setup: PC 192.168.1.25 / 255.255.255.0, panel 192.168.1.30 / 255.255.255.0.
• The default gateway on the PC and the panel must be valid. If the two devices are on a single physical LAN with no router, the gateway can be the PC's own IP (or 0.0.0.0 is not acceptable; use the panel's IP on the PC, and the PC's IP on the panel as gateway).
• The Windows firewall on the engineering PC must allow SIMATIC WinCC flexible and ProSave as exceptions, or be temporarily disabled during transfer.
• No duplicate IP on the LAN segment; confirm with arp -a on the PC.

Step-by-Step Recovery Procedure

Follow the steps in order. The full procedure resolves the wrong-gateway case described in the field report, and additionally covers the related Layer-3 issues that produce the same symptom.

Step 1 - Verify ICMP and ARP

From the engineering PC, open a command prompt and execute:

ping 192.168.1.30 -n 4
arp -a 192.168.1.30

A successful ping with a MAC address returned by arp confirms Layer-2/3 reachability to the panel. If arp -a shows (incomplete) or no entry, the cable, switch port, or IP configuration is wrong and Step 2 will not help until this is fixed.

Step 2 - Correct the Default Gateway on the MP 370

On the MP 370, open the Control Panel (Start > Settings > Control Panel) and double-click OP Properties (or System, depending on image). Select the Network tab. Enter the parameters exactly as shown:

On the PC, set the default gateway to 192.168.1.30 (the panel's IP) if no real router is present. This symmetrical gateway assignment is what was missing in the source case: the PC had a gateway that pointed at a non-existent router, so the panel's TCP handshake reply was discarded by the PC's routing table. Confirm with route print on the PC; the route to 192.168.1.0/24 must show interface 192.168.1.25 directly.

Step 3 - Enable Transfer on the MP 370 Control Panel

In the same OP Properties / System dialog, open the Transfer tab. The following settings are required:

• Channel 1 (or the Ethernet channel): Enabled, mode ETHERNET.
• Check Remote Control so that the panel accepts a transfer request from a remote PC without a confirmation prompt at the HMI.
• Confirm the transfer port (default 1025; legacy 1024 is also accepted by WinCC flexible).

Apply the changes; the panel prompts for a restart of the transfer service. Allow the restart.

Step 4 - Configure the WinCC flexible Transfer Channel

In the WinCC flexible project, open Project > Transfer > Transfer Settings. Set:

Mode:         Ethernet
IP Address:   192.168.1.30
Port:         1025
Timeout:      60 s (default is sufficient)

Click Test. A successful test returns "Connection established." A failure with a timeout indicates Layer-3 mismatch (revisit Step 2) or a firewall (revisit prerequisites). Click Transfer to push the project.

Step 5 - Handle the OS Update Prompt

If the project was compiled against a newer Windows CE image than the panel currently runs, WinCC flexible returns a dialog such as "The operating system on the target device does not match. Do you want to update the OS?" Select Yes and confirm the subsequent ProSave OS update prompt. The OS update is mandatory in this case; declining it aborts the project transfer.

For an OS update via ProSave:

1. Open ProSave on the engineering PC.
2. Select device type MP 370 Touch (or 12" Key / 15" Touch as applicable).
3. Connection: Ethernet, IP 192.168.1.30.
4. Select the OS Update tab and choose the matching *.img file supplied with WinCC flexible.
5. Click Update OS. The panel reboots into the update image and writes the new CE image. Do not power-cycle during this process.

Step 6 - Transfer the Project

After the OS update completes (or if no update was required), return to WinCC flexible and re-trigger Project > Transfer > Transfer. The MP 370 displays "Transferring..." with a progress bar, and the WinCC flexible client shows a successful completion log.

Verification

After the transfer, perform the following verification checks before signing off the commissioning step:

1. Project boot: The MP 370 restarts and runs the new project. The configured start screen appears within 30-60 s after the panel boots into runtime.
2. Version check: On the MP 370, navigate to Control Panel > OP Properties > Version (or the WinCC flexible runtime info screen) and confirm the project version matches the compiled output.
3. Tag/connection test: Use a watch table in the connected PLC, or the WinCC flexible online diagnostics, to confirm that tags update in real time on the screen.
4. Persistence test: Power-cycle the MP 370 and confirm the project reloads automatically from flash.
5. Route persistence: Re-check route print on the PC and the MP 370's gateway field; a non-zero static gateway should remain set.

Troubleshooting Matrix

Advanced Diagnostics

When the basic procedure does not resolve the issue, escalate to packet-level diagnostics. On the engineering PC, run Wireshark (or the built-in netsh trace on Windows 7+) with a capture filter for the panel's IP and the transfer port:

capture filter: host 192.168.1.30 and tcp port 1025
display filter:  ip.addr == 192.168.1.30 && tcp.port == 1025

A successful transfer begins with a TCP three-way handshake from the PC's ephemeral port to the panel's 1025, followed by a Siemens-specific protocol negotiation. If the SYN is sent but no SYN-ACK returns, the panel's transfer service is not listening (channel disabled or wrong port). If SYN-ACK returns and the session opens, but is then reset, the project image is incompatible and the OS update prompt is being suppressed by the client.

For panels that hang during the OS update, connect a serial service cable to the MP 370 (RS-232 on the service port) and capture the boot messages at 115200 8N1. The Windows CE bootloader will report the active image version and any CRC errors on the internal flash, which is the fastest way to identify a corrupt image that prevents project boot.

Field-Proven Caveats

• The MP 370 retains the last project in flash. If a transfer is interrupted (power loss, cable disconnect), the panel returns to the previously running project on the next boot. This is by design; it does not indicate a transfer failure.
• ProSave's "Reset to factory defaults" option erases both the project and the IP settings. Always reconfigure the network parameters after a reset; the panel does not preserve any prior static IP through a factory reset.
• When the PC and the panel are on different subnets (e.g., 192.168.1.0/24 and 192.168.2.0/24) and connected through a router, both sides must list the router as the default gateway. With a flat /24 the source-issue case (wrong gateway on the PC) is the dominant cause.
• The "Remote Control" checkbox in OP Properties is off by default on some CE images. Without it, the panel requires an operator to press a soft key to accept the incoming transfer; remote unattended transfers fail.