Diagnosing S7-1200 PLC Freezes with CP1242-7 GPRS Modbus

Problem Overview

The reported fault pattern is a classic S7-1200 communication-degradation failure: a CPU 1212C in combination with a CP1242-7 v2 GPRS module stops updating Modbus tags and OPC UA values after an unpredictable runtime, with no entry in the CPU or CP diagnostic buffer, no SF/MBF LED, and no STOP transition. The PLC remains reachable through the TeleService (Teleservice) tunnel, a warm restart (STOP→RUN) immediately restores operation, and the freeze re-occurs hours later. Because there is no error message, the failure is almost always related to a runtime degradation of the user program (Modbus instruction queue, watchdogs, memory pressure) rather than a hardware fault.

System Architecture Reference

The reported topology is a layered SCADA system:

1. Field level – Modbus RTU/TCP slaves (instruments, energy meters, I/O).
2. CPU 1212C – program executes MB_CLIENT/MB_SERVER blocks from the Modbus library to read field data and to map data points to the CP.
3. CP1242-7 v2 – GPRS communication processor that publishes the data points to a TCSB (TeleControl Server Basic) v3.1 instance over the cellular network.
4. SCADA level – WinCC v7.4 (or newer) reads values from TCSB through the OPC UA channel.

The GPRS link introduces latency, jitter, and intermittent disconnects. When the CP1242-7 loses the PDP context, the S7-1200 program must actively detect and recover. If the user program does not implement reconnection logic, the Modbus request queue can stall and, in some firmware versions, can lock OB1 from completing its cycle.

Root Cause Analysis

When the CPU keeps the RUN LED on, accepts a Teleservice connection, but stops processing Modbus requests and data-point updates, the most likely root causes are listed in the table below in order of frequency.

Step 1 – Read the CPU Diagnostic Buffer

Even when no error LED is lit, the diagnostic buffer is the first place to look. Connect the engineering station to the CPU (Teleservice tunnel or direct Ethernet), then in TIA Portal:

1. Project tree → Devices & Networks → right-click the CPU → Go online.
2. Open Online & Diagnostics.
3. Select Diagnostics > Diagnostic buffer.
4. Sort the events by time (descending) and look for the earliest Communication error, Time error (OB80), or Connection abort.

Key event IDs to look for on a CPU 1212C:

Step 2 – Read the CP1242-7 Diagnostic Buffer

The CP1242-7 keeps its own diagnostic buffer and a web interface:

1. Open a browser and point to the CP IP address (port 80). The default credentials are admin / admin – change them in production.
2. Navigate to Diagnostics > Logbook and inspect the GPRS/PPP state machine entries.
3. Confirm signal strength (CSQ), PDP context, and the number of reconnect attempts.

If the logbook shows frequent reconnection events at the moment the PLC freezes, the cellular link is suspect. Add an external watchdog: in the user program, expose a counter that increments every successful Modbus poll. If the counter does not advance for N cycles, set a digital output that triggers a STOP→RUN pulse on the CM switch or call RE_INIT to force a partner reconnection.

Step 3 – Instrument the Modbus Cycle with a Life Bit and Telegram Counter

The fastest way to make the failure observable from SCADA is to publish two data points to the CP1242-7 data-point table:

• Life bit – a BOOL that toggles in OB1 every successful cycle. SCADA can detect that the value is stuck and raise an alarm.
• Telegram counter – a DWORD that increments on every MB_CLIENT DONE. The delta between two consecutive samples must equal the number of expected slaves.

A reference STL code block (use as a template – adapt data block numbers to your project):

// OB1 – toggles life bit, increments telegram counter on DONE
A     "Modbus".Done;
FP    "Edge_Done";
JCN   NO1;
L     "Counter".TelegramCnt;
+     1;
T     "Counter".TelegramCnt;
NO1: NOP 0;
A     "Lifebit";
=     "Lifebit_Next";
A     "Lifebit_Next";
=     "Lifebit";

At the SCADA level, configure a watchdog that triggers a PLC not responding alarm if the life bit is unchanged for 3x the expected cycle time. The alarm should also trigger a forced reconnect command back to the PLC through a write data point.

Step 4 – Verify the MB_CLIENT Block Usage

The Modbus instruction library on S7-1200 / TIA Portal V13 SP1 and newer ships with FB1080 MB_CLIENT and FB1081 MB_SERVER. The block uses a rising edge on REQ to launch a transaction and reports the result on DONE, ERROR, and STATUS. Common mistakes that cause silent stalls:

1. REQ stays TRUE: the block does not start a new transaction while REQ is high. If the program never resets REQ, only one transaction is ever sent.
2. DONE/ERROR not acknowledged: the block does not clear the busy state until either DONE or ERROR pulses. If the program samples the bits with a slow OB (e.g. OB35 every 100 ms) the request queue can be blocked.
3. MB_MODE / MB_DATA_ADDR wrong after reconfig: the block returns STATUS = 0x8381 or 0x8382 and the program silently ignores it.

Best-practice template: trigger REQ with a one-shot pulse from a clock generator at a rate lower than the worst-case Modbus turnaround. On the rising edge of DONE or ERROR, immediately reset REQ. This guarantees that the block is always ready for the next trigger.

Step 5 – Check the OB1 Cycle Time and Watchdog

Open Online > Diagnostics > Cycle time / Time system. The S7-1200 has two thresholds:

• 100% of the configured maximum cycle time – OB80 (Time error) is called once.
• 150% – the CPU goes to STOP.

When the cycle creeps up to ~90% of the limit, the CPU may still stay in RUN, but the Modbus transactions slow down to the point that the queue accumulates. Add a DB that records the last 100 cycle times, then use a trace or a script to find the slope. If the trend is monotonically increasing, look for:

• Unbounded loops in the user program.
• Unreleased DBs (e.g. after a recipe is changed online).
• Frequent data logging to a removable media (the S7-1200 DataLog block is not real-time safe).

Step 6 – Update Firmware

Several GPRS/Modbus defects were corrected in the following firmware releases. Always match the CPU and the CP versions recommended by Siemens for use with the same TIA Portal version.

Step 7 – Add Reconnection Logic to the CP1242-7

The CP1242-7 has an automatic GPRS reconnection parameter. Set the values explicitly in the CP device configuration:

• Maximum number of connection attempts – 0 (infinite).
• Connection attempt delay – 30 s.
• Keep-alive interval – 60 s.
• Watchdog time – 180 s (triggers a reconnection if no telegram exchanged).

Then add a user-program block that monitors the CP state and forces a manual reconnection when the CP state has been Not connected for more than 5 minutes. The CP state is exposed in the data points or through TC_CON instructions on the S7-1200 program.

Step 8 – Verify the OPC UA Server Side

The S7-1200 can act as an OPC UA server starting with firmware V4.4. The WinCC v7.4 OPC UA channel connects as a client. If the connection between WinCC and the CPU breaks silently:

1. Open the OPC UA method block on the CPU and check ServerState. A value of 1 indicates a comm_failure.
2. Reduce the number of subscribed items per session. A WinCC v7.4 channel default of 1000 items per session can starve the CPU if it also runs Modbus.
3. Enable the Server interface parameter Minimum publishing interval to 500 ms – this prevents the client from requesting 50 ms updates that the CPU cannot sustain.

Verification Procedure

1. Force the GPRS link to drop (pull the antenna or use the CP web server to disable the PDP context).
2. Confirm that the life bit in SCADA stops toggling within 2 cycles.
3. Wait 5 minutes; confirm the CP reconnects automatically and the life bit resumes.
4. Inspect the CPU diagnostic buffer – there must be no STOP event and no OB80.
5. Run a 24-hour soak test with the SCADA logging the telegram counter deltas. The delta must equal the expected number of slaves every minute.

If all four conditions are met, the freeze is resolved. If the life bit still stops but no error appears, repeat the cycle-time analysis with a longer trace window.

Troubleshooting Matrix

FAQ