Troubleshooting Siemens RF240R RFID Errors on S7-1200 PLC Systems

1. Problem Description and Symptom Summary

A SIMATIC RF240R RFID reader connected to an S7-1214 CPU (S7-1200 family) reports a fault that appears at random intervals. The application reads and writes tags successfully for hours or days, then the antenna enters a permanent error state. The only recovery observed in the field is a full power cycle of the S7-1200 system power supply (PS 307 / PM 1207) or a STOP-to-RUN transition plus cold restart.

The behaviour is consistent with a latched diagnostic event inside the SIMATIC Ident stack: the RF240R antenna stops processing commands, the IDENT function block returns busy=FALSE, done=FALSE, error=TRUE, and the antenna's onboard LED (CH/ERR) is lit solid red or flashing in the manufacturer's fault pattern. The CPU remains in RUN; only the RFID subsystem is faulted.

The fault profile matches the symptoms described when the IDENT configuration DB reset path is not exercised. Many integrators mistakenly believe only a power cycle will clear the antenna, when in fact the SIMATIC Ident profile exposes a software reset bit that restores the antenna to its initial state without re-initialising the CPU.

2. RF240R Reader Hardware and the S7-1200 Communication Path

The RF240R is a member of the SIMATIC RF200 family, an HF (13.56 MHz, ISO 15693) reader with an integrated antenna and RS-422 / serial interface. It is not a PROFINET device on its own - it requires a SIMATIC Ident communication module to expose its data to a Siemens PLC.

The 1214 CPU has the CM (communication module) interface on the left side, which is the slot reserved for the RF120C. If the application uses an RF180C in a remote ET 200 station instead, the path is: RF240R (RS-422) → RF180C → PROFINET → S7-1214. Either topology requires the same IDENT library blocks on the CPU side.

Refer to the SIMATIC RF200 System Manual for pin assignments and the SIMATIC RF180C Operating Instructions for the ET 200 path.

3. Root Cause Analysis: Why Random Faults Occur

When the RF240R enters a permanent error state, the underlying cause is almost always one of the following:

1. Air-interface loss of tag during a write command. The tag left the RF field mid-write. The reader holds the command in the air interface until the configured timeout expires and reports a command abort.
2. RS-422 framing / parity error from electromagnetic interference (VFD harmonic noise, unshielded cable near a power contactor, missing ground reference). The reader rejects the corrupted response frame and reports an air protocol error.
3. Ident stack overflow caused by an over-aggressive command rate. Each Ident_Read / Ident_Write call must complete before the next is queued. If the application code re-triggers faster than the cycle, the module returns 0xE0FE0043 (another command is currently active).
4. Antenna cable over length. The RS-422 cable between RF240R and RF120C / RF180C must not exceed 50 m for RS-422 at 115.2 kbit/s; longer runs produce intermittent CRC errors that the reader interprets as protocol faults.
5. 24 V supply brownout on the antenna. The RF240R draws ~120 mA at 24 V. A shared PS with solenoids or relays can produce a dip that resets only the antenna, not the CPU, leaving the IDENT stack waiting for a response that will never arrive.

In each of these cases the IDENT stack transitions into a fault wait state rather than auto-recovering. Without a software reset, the fault is latched until the communication module is re-initialised - which TIA Portal performs during a CPU STOP→RUN transition or after a full power cycle.

4. Diagnostic Procedure: Reading the Fault Code

Before resetting, capture the fault code. The IDENT function block (for example FB 286 "Ident_Read" or FB 287 "Ident_Write" from the "SIMATIC Ident" library) writes diagnostic data to the user-configured IDENT configuration DB. Inspect these tags to obtain the fault class:

Common RF240R / RF200 error codes:

Capture the value at the instant of the fault; many integrators only see the LAST error from a watch table, which can be overwritten by an automatic retry. Use an HMI tag log or push the error_code to a retentive data block the moment command_state transitions to 3.

5. Reset Paths: Hardware Power Cycle vs Software Reset

There are exactly four documented reset paths for the SIMATIC Ident subsystem. Power cycling the CPU is the worst of them because it stops the controlled process and drops all outputs to their configured substitute values.

6. Implementing Software Reset in the IDENT Configuration DB

When you configure the RFID channel in TIA Portal (device view → RF120C / RF180C properties → "Ident profile"), the wizard generates a configuration DB. By default the structure looks like:

// Ident configuration DB - sample offsets (byte addresses may vary by version)
DATA_BLOCK "DB_Ident_Config"
  STRUCT
    channel          : BOOL;   // Channel enable
    antenna          : BOOL;   // Antenna enable
    reset            : BOOL;   // *** Software reset request ***
    continuous_mode  : BOOL;
    command_timeout  : TIME;   // Default T#2s; raise to T#5s for noisy lines
    retry_count      : INT;    // Default 0; raise to 2 for transient air errors
    reserved         : ARRAY[0..15] OF BYTE;
  END_STRUCT;
END_DATA_BLOCK

The reset bit is level-triggered on the Ident profile side. Pulse it for at least one OB1 cycle (typically 50–100 ms) to command a clean re-initialisation. The communication module acknowledges the reset by clearing its internal error state and returning command_state = 0 (ready).

6.1 SCL example for a single-channel RF240R

// Auto-reset logic for RF240R via Ident configuration DB
// Triggered when command_state has been ERROR for more than 5 seconds

#FaultTimer(IN := ("DB_Ident_Config".command_state = 3),
            PT := T#5s);

IF #FaultTimer.Q THEN
    // Pulse the reset bit for one cycle, then release
    "DB_Ident_Config".reset := TRUE;
    #ResetPulse(IN := TRUE, PT := T#200ms);
    IF #ResetPulse.Q THEN
        "DB_Ident_Config".reset := FALSE;
        #FaultTimer(IN := FALSE);
    END_IF;
END_IF;

// Latch the last error code to a retentive DB for diagnostics
IF "DB_Ident_Config".command_state = 3 AND NOT #LastErrorLatched THEN
    "DB_Diagnostics".last_error_code   := "DB_Ident_Config".error_code;
    "DB_Diagnostics".last_extended     := "DB_Ident_Config".extended_error;
    "DB_Diagnostics".last_error_time   := RD_SYS_T;
    #LastErrorLatched := TRUE;
ELSIF "DB_Ident_Config".command_state = 0 THEN
    #LastErrorLatched := FALSE;
END_IF;

6.2 Ladder alternative

Network 1: Fault watchdog
[DB_Ident_Config].command_state == 3  --TON-->  T#5s  --|/|-->  Q0.0 (reset_request)

Network 2: Reset pulse
reset_request                        ---( S )---  "DB_Ident_Config".reset
reset_request  --TON--> T#200ms       ---( R )---  "DB_Ident_Config".reset

The 5-second hold-off prevents the auto-reset from chasing fast transient faults (e.g. a tag briefly leaving the field). Only latched, persistent faults trigger a reset.

7. Auto-Reset Logic with Watchdog Timer

A complete auto-reset routine for production lines should layer three behaviours:

1. First fault within a 10-minute window: hold the application and queue retry on the next OB1 cycle.
2. Second consecutive fault: issue a software reset via the IDENT DB.
3. Third consecutive fault: latch a system-level alarm, send an SMS / e-mail via the HMI, and disable the RFID channel to prevent CPU watchdog overflow.

// Counter-based escalation
IF "DB_Ident_Config".command_state = 3 THEN
    #FaultCount := #FaultCount + 1;
ELSE
    #FaultCount := 0;
END_IF;

CASE #FaultCount OF
    0: "DB_Ident_Config".reset := FALSE;
    1: // first fault - wait, do nothing
       ;
    2: "DB_Ident_Config".reset := TRUE;          // software reset
    3: "DB_Ident_Config".reset := FALSE;
       "DB_Ident_Config".channel := FALSE;       // disable channel
       "DB_Diagnostics".escalation_active := TRUE;
END_CASE;

Place this routine in a cyclic OB (OB1 or OB35 at 100 ms) so that the reset decision is independent of the scan time of the operator's HMI screen.

8. Verification and Commissioning Tests

After deploying the reset logic, validate it with a structured bench test before going back to production:

Use the TIA Portal Online & Diagnostics view on the RF120C / RF180C to confirm "Status = OK" and "Diagnostic interrupt = None" after each reset. See the SIMATIC RF180C diagnostics guide for the diagnostic event list.

9. Field-Commissioned Best Practices

• Use shielded twisted-pair cable for the RS-422 link, drain wire grounded at one end only (typically at the RF120C / RF180C side). Maximum 50 m at 115.2 kbit/s; reduce to 25 m in noisy cabinets.
• Separate 24 V supply for the RF240R from solenoid valves and contactor coils. Use a dedicated PS 307 or PM 1207 segment with a 1 A fuse.
• Set command_timeout to T#5s in the IDENT DB. The default T#2s is too tight for production-line reads where tag dwell time varies with conveyor speed.
• Raise retry_count to 2 for read commands; leave at 0 for write commands because repeated write attempts can corrupt tag memory.
• Pin the IDENT DB to optimised access in TIA Portal so the symbolic read is consistent across OB1 / OB35 / OB82 (diagnostic interrupt) - mixing non-optimised and optimised blocks on the same IDENT DB is a common cause of stale command_state values that delay auto-reset.
• Enable the diagnostic interrupt OB (OB82) on the RF120C / RF180C and log the IO_State word on every entry. This is the fastest way to capture the exact module event that triggered the fault.
• Reserve retentive DBs for last_error_code, last_extended, and escalation_active. Without retention, every power cycle clears the fault history and the root cause becomes untraceable.

For TIA Portal configuration of the RF120C, see the SIMATIC Ident Profile Function Manual. For S7-1200 CPU diagnostics on OB82, see the S7-1200 Programmable Controller System Manual.

10. Quick Decision Matrix

FAQ