Troubleshooting IM 151-8 PN/DP CPU with ET200S 1SI Serial Module

Overview

The IM 151-8 PN/DP CPU is an interface module with an integrated CPU for the ET 200S distributed I/O system. When paired with the ET 200S 1SI serial interface module (6ES7 138-4DF01-0AB0 or 6ES7 138-4DF11-0AB0), the CPU can read and write data from serial end devices using ASCII, 3964(R), or RK 512 protocols. Field experience shows two recurring failure modes: (1) the 1SI module intermittently stops responding on the serial port with no software recovery path other than power cycling, and (2) the CPU enters a 0.5 Hz memory-reset request loop after an MMC swap. Both problems are diagnosable through the integrated LED indicators and are preventable with the correct STEP 7 program architecture.

Problem 1: ET 200S 1SI Serial Module Lockup

Symptoms

• S_RCV (FB 2) returns no new data after running for hours or days.
• S_SEND (FB 3) reports the job complete but bytes never reach the slave.
• The SF (group error) LED on the 1SI module lights steady red; the 1SI is still online in the hardware configuration.
• Writing a new configuration or restarting the OB 1 cycle does not clear the fault.
• The only field-proven recovery is a 24 V power cycle on the ET 200S station or the 1SI submodule's load group.

Root Cause

The lockup is triggered when the calling program polls S_RCV without inspecting the error/status outputs. The 1SI module cancels any active receive job after a framing, parity, or timeout error, and that error remains latched until the application re-arms the receive buffer. When the application code only monitors the DONE bit and ignores ERROR, STATUS, and S_RCV.STA_DATID, the next call to S_RCV never returns because the module has nothing new to deliver and the error path is never cleared.

A secondary cause is the use of a Function (FC) instead of a Function Block (FB) for the serial wrapper. Each FC call rebuilds pointer-based parameter passing (six bytes per pointer with multiple L/T transactions) and, in heavy cyclic use, can produce transient parameter alignment mismatches inside the 1SI's dual-port RAM, especially when the FC is reused for multiple serial ports in the same OB 1.

Problem 2: IM 151-8 PN/DP Memory Reset Request Loop

Symptoms

• After an MMC removal/reinsertion or after a download in RUN, the STOP LED flashes slowly.
• The CPU refuses to enter RUN.
• STEP 7 online view reports the CPU is requesting a memory reset.

LED Decoding

The LED flash-rate timing is documented in the IM 151-8 PN/DP CPU manual entry on SiePortal (article ID 47409312), which lists the 0.5 Hz slow-flash and 2 Hz fast-flash rates for memory-reset request and execution respectively. Reference: IM 151-8 PN/DP CPU status and error displays.

Resolution

1. Turn the mode selector to MRES.
2. Hold the selector for at least three seconds until the STOP LED stays steady ON.
3. Release, then turn back to MRES within one second and release again.
4. The STOP LED now flashes at 2 Hz; wait until it returns to steady ON.
5. Insert the MMC, perform a fresh download, and transition to RUN.

If the CPU reverts to 0.5 Hz immediately after MRES, the MMC is corrupted or contains a project that the CPU firmware rejects. Re-format the MMC in STEP 7 (SIMATIC Manager > PLC > Memory Card > Format) or rewrite the MMC with the matching order number (6ES7 953-8LF00-0AA0 or higher). Additional diagnostic detail for this scenario is published in the SiePortal support thread IM 151-8 impossible to reset memory.

STEP 7 Program Architecture: FB with Multiple Instances

For multi-port serial scanning, declare a single Function Block (FB) that contains S_RCV and S_SEND as static instances. This gives the compiler a fixed, address-bound parameter block per call site instead of the pointer-based parameter exchange the compiler synthesises for every FC call.

Parameter exchange comparison:

FB Declaration (STAT section)

FUNCTION_BLOCK FB_SerialScanner
VAR
  S_RCV_Inst : S_RCV;     // FB 2
  S_SEND_Inst : S_SEND;   // FB 3
  RecvBuffer  : ARRAY[0..255] OF BYTE;
  RecvLen     : INT;
  RecvDone    : BOOL;
  RecvError   : BOOL;
  RecvStatus  : WORD;
END_VAR
BEGIN
  // call S_RCV_Inst here, route its ERROR and STATUS to RecvError / RecvStatus
END_FUNCTION_BLOCK

Calling OB 1 with Multiple Instances

// One IDB per scanner port; each holds its own instance of S_RCV_Inst
CALL FB_SerialScanner, DB_Scanner_1    // port on 1SI slot 1
CALL FB_SerialScanner, DB_Scanner_2    // port on 1SI slot 2
CALL FB_SerialScanner, DB_Scanner_3    // port on 1SI slot 3

Each IDB gets its own copy of S_RCV_Inst and S_SEND_Inst, so the FB2/FB3 background data (receive buffer pointers, job state machine) is unique per port. The compiler emits direct A/= and L/T onto the IDB offsets; no pointer indirection is needed at runtime.

Error Handling for S_RCV and S_SEND

Always evaluate every status output, not just DONE. The 1SI module returns these job-status values:

Any time ERROR = TRUE the calling code must re-issue the S_RCV call with EN_R = TRUE and R = FALSE. Skipping the re-arm path is the most common cause of the lockup described in Problem 1.

Verification Procedure

1. Open STEP 7 SIMATIC Manager and go online with the IM 151-8 station.
2. Open the S_RCV instance DB and confirm BUSY toggles within one OB 1 cycle after each character is received.
3. Force EN_R high and set R high for one cycle, then low; the receive job should re-arm.
4. Disconnect the serial line for 60 seconds and verify the diagnostic buffer records the framing/timeout event with a timestamp; STATUS should display 8181h.
5. Reconnect and confirm S_RCV resumes without a power cycle.
6. Monitor the STOP LED with a phone camera at 240 fps; verify it never sits at 0.5 Hz for more than three seconds during normal operation.

Troubleshooting Matrix

Key Specifications

Programming Best Practices for Serial Libraries

For a reusable serial library on this platform, follow these rules:

1. Define one FB per protocol wrapper (FB_ASCII_Scanner, FB_3964_Scanner, FB_RK512_Scanner).
2. Instantiate S_RCV and S_SEND in the FB's STAT section only.
3. Expose DONE, ERROR, STATUS, and the raw received length on the FB outputs.
4. In the calling OB, treat any rising edge of ERROR as a re-arm trigger.
5. Keep a heartbeat counter that increments every successful reception; alarm if no reception occurs for N× protocol timeout cycles.
6. Document the 1SI slot and channel per IDB so hardware changes do not silently re-point the wrong port.

This pattern produces a library where a new serial port is added by instantiating the FB into a new IDB, with no recompilation of the wrapper and no risk of pointer misalignment across the FC/FB boundary.