An S7-200 CPU 224 that remains accessible in STOP but disconnects after entering RUN is consistent with a serial-port ownership conflict. The downloaded program uses the CPU's only port for PLC-to-PLC communication through NETR/NETW logic. When execution starts, that logic takes control of the port, so the PC/PPI programming connection can no longer remain online.
Identify the RUN-mode port conflict
| Observed condition | Diagnostic meaning |
|---|---|
| PC/PPI communication works in STOP | The cable and programming path can reach the CPU while user communication logic is inactive. |
| The program downloads successfully | The failure occurs after download rather than during transfer. |
| The connection drops when the CPU enters RUN | The user program begins using the same port assigned to the programming device. |
| Both CPU 224 units have one available port | No separate serial port remains for simultaneous programming access. |
Confirm that the program owns the port
Check whether the downloaded program configures the CPU 224 port for the NETR/NETW communication created by the wizard. The evidence refers to this configuration as Freeport communication, but the decisive condition is shared use of the same physical port by the PLC-to-PLC link and the PC/PPI cable.
- Place the CPU in STOP and confirm that the programming software can go online through the PC/PPI cable.
- Inspect the project for NETR/NETW communication assigned to the CPU's only port.
- Change the CPU to RUN and observe whether the online session drops when that communication logic begins executing.
- Temporarily prevent the PLC-to-PLC communication from taking control of the port, then repeat the RUN-mode test. If online access remains available, the port conflict is confirmed.
Select an access strategy
If the only serial port must remain assigned to communication between the two CPUs, do not expect simultaneous PC/PPI monitoring through that port in RUN. Use STOP mode when the application permits the port to return to the programming device, or revise the architecture so programming and PLC-to-PLC traffic use separate paths.
The cited alternative is to equip each S7-200 with an Ethernet module and connect the controllers through Ethernet. This can leave the serial ports available for PC/PPI monitoring and can also provide an Ethernet path for monitoring, upload, and download. Confirm module compatibility and configuration requirements for the installed CPUs before selecting hardware; no module model is identified in the evidence.
Verify the correction
After separating the communication paths or disabling the serial communication that owns the port, download the revised project, place the CPU in RUN, and reconnect online. The correction is verified only when the CPU remains in RUN while the programming session stays connected and the required PLC-to-PLC data exchange still operates through its intended path.
FAQ
Why does an S7-200 CPU 224 communicate in STOP but disconnect in RUN?
The downloaded NETR/NETW communication begins using the CPU's only port in RUN. That prevents the PC/PPI programming connection from using the same port concurrently.
Can I monitor a CPU 224 through PC/PPI while NETR/NETW uses its only port?
Not through that same port while the user communication owns it in RUN. Stop or disable that communication, or provide a separate communication path.
How can two CPU 224 PLCs communicate while keeping programming access?
One cited approach is to add an Ethernet module to each PLC and move the controller link or programming access to Ethernet. Verify compatible hardware before implementation because the evidence does not specify a module model.