Fixing RF180C PROFINET Failure on S7-1512SP-1 PN with S120 TOs

An S7-1512SP-1 PN controller (ET 200SP CPU) running four S120 drive axes through motion-control Technology Objects (TOs) cannot complete the PROFINET application relationship (AR) with four SIMATIC RF180C RFID communication modules when the RF180C channels are added as Ident TOs. The four RF180C modules light up the red BF (bus fault) LED, the CPU online diagnostics show the AR is rejected, and TIA Portal reports the channels as not reachable. Remove the four S120 TOs and the RF180C ARs establish immediately. This is a CPU resource saturation problem, not a wiring, GSD, or firmware-mismatch defect, and it has a deterministic fix path that does not require swapping CPUs in the majority of cases.

Affected System Configuration

The configuration that fails:

• Controller: SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK02-0AB0, firmware V2.6 and later in the field reports; behavior is consistent across the V2.x line)
• HMI: SIMATIC TP 700 Comfort (6AV2 124-1GC01-0AX0)
• Drives: 4 axes of SINAMICS S120 with PROFINET control, each axis configured as a TO of type TO_SpeedAxis or TO_PositioningAxis, telegram 105 or 111 with motion control
• RFID: 4× SIMATIC RF180C PN communication modules (6GT2002-0JD00), each with 2× SIMATIC RF280R readers (6GT2801-3AB10) multiplexed on a single channel, 8 readers total
• Engineering: TIA Portal, RF180C and S120 configured through TOs under Technology objects

What fails: the four RF180C devices show IO device failure or AR establishment error in the TIA Portal device view and online diagnostics. The four S120 drives continue to operate normally.

What works: deleting only the four S120 TOs (the RF180C TOs are still present) brings the four RF180C ARs up within a single PROFINET cycle. The drives lose TO-driven motion control and must be re-controlled with standard telegram plus a user program, but the RF180C reads and writes start working.

Root Cause: Independent Resource Pools, One Saturating

The S7-1500 and ET 200SP CPUs maintain several independent resource pools that all compete for a finite internal budget. Technology Objects consume from more than one of these pools, and PROFINET IO devices do as well. When a TO is instantiated for a S120 drive, the TO is bound to a specific PROFINET IO device slot and reserves resources in at least three pools:

1. General technology object slots, a single integer counter (typical: 192 for the 1512SP-1 PN)
2. Motion-control resource blocks, a separate counter that bounds how many PositioningAxis, SpeedAxis, and SynchronousAxis TOs the CPU can execute concurrently, sized smaller than the general slot count
3. PROFINET IO controller slot and submodule budget on the X1 interface, a finite budget of cyclic and racy slots, ARs, and record-data bytes that the PN interface can manage

The S7-1512SP-1 PN documented general TO slot count is high enough that 4 S120 TOs + 4 Ident TOs (8 total) is well within the limit. The motion-control resource limit is also sufficient for 4 axes. The pool that saturates is the PROFINET IO controller slot and submodule budget consumed when the four S120 drives are configured with TO-supported telegrams (105 or 111). The CPU reserves additional internal submodules, record-data length, and isochronous time-slot resources per axis that do not appear in the standard telegram configuration. When the four Ident TOs for the RF180C modules are added, the additional submodule and record-data reservations push the controller past the per-interface budget, and the CPU rejects the AR for the RF180C devices (the lowest-numbered or most-recently-added devices in practice).

S7-1512SP-1 PN Resource Reference

Verify the specific budget for your firmware version against the function manual on the Siemens Industry Online Support portal. The values below are typical for an S7-1512SP-1 PN (6ES7512-1DK02-0AB0) on firmware V2.6 through V2.9; check the function manual for the exact number that applies to your build:

To read the live budget on your CPU, go online in TIA Portal, open the device view of the S7-1512SP-1 PN, right-click the PROFINET interface, and select PROFINET interface diagnostics, then Port statistics and IO device diagnostics. The diagnostics buffer of the CPU (Online & Diagnostics > Diagnostics buffer) will contain the specific cause code if the AR was rejected for a resource reason; look for entries of class PROFINET IO with the cause Resource problem or Submodule list rejected.

Diagnostic Procedure

Follow this sequence to confirm the failure mode before changing hardware or TOs.

1. Go online with the CPU (TIA Portal > project tree > S7-1512SP-1 PN > Go online).
2. Open Online & Diagnostics > Diagnostics buffer. Filter for events of class PROFINET IO and I/O fault. Note the event IDs and the affected IO device PROFINET names.
3. Open the device view, select the X1 PROFINET interface, and read Online & Diagnostics > PROFINET interface > Diagnostics. Note the values for Number of IO devices, Number of submodules, and IRT slots used (field labels vary by firmware).
4. In the project tree, expand Technology objects. Right-click the group and read the size of each pool used. TIA Portal shows the configured versus available count for motion-control resources, Ident channels, and PID resources.
5. Disconnect the four RF180C devices from the project (delete the four RF180C nodes and the four Ident TOs). Compile and download. The S120 axes continue operating. Observe whether the S120 ARs are stable and whether the S120 diagnostics buffer is clean.
6. Add the four RF180C IO devices back to the project without TOs (standard PROFINET device with default telegram). Compile and download. Verify all 8 IO devices are reachable. If they are, the failure is on the TO layer, not on the PROFINET IO device layer.
7. Re-add the four Ident TOs one at a time, downloading and going online between each, until the AR for the next RF180C is rejected. The last successfully added TO marks the threshold of the saturating resource pool. Note which resource saturates (submodule count, IRT slot, record-data length).

At the end of step 7 you will know exactly which resource pool is the bottleneck and how many RF180C modules your CPU can host with TO support at the current firmware version. Record the result in the project functional specification so the next project of this class is sized correctly at the design stage.

Solution Option 1: Upgrade to a Higher-Class S7-1500 CPU

If the production line has to retain TO-based motion control on all four S120 axes and TO-based Ident handling on all four RF180C channels, the only hardware-level fix is to move the controller up to a CPU class with a larger per-interface budget. Candidates in the same ET 200SP and S7-1500 family:

An S7-1515SP-2 PN is the smallest step that doubles the per-interface PROFINET budget and adds a second PN port. The migration cost is the head module swap (the 1512SP and 1515SP are both ET 200SP head modules, so the swap is in-place), the project recompile, and a re-plug of one device class onto the X2 port. For projects where a rack-mounted S7-1500 head module is acceptable, the S7-1515-2 PN (6ES7515-2AM02-0AB0) is a clean alternative with the largest absolute per-interface budget in the mid-range. Verify the exact budget at the manual for your firmware before quoting the migration; the numbers above are typical mid-line figures, not firmware-specific guarantees.

Solution Option 2: Handle the RF180C Manually Without Ident TOs

Drop the Ident TO layer for the four RF180C channels and use the Siemens Ident instruction library directly. This eliminates the per-channel TO reservation entirely and reduces the per-channel PROFINET reservation to the default 2 submodules plus 1 record-data block, which fits the 1512SP-1 PN budget alongside the four S120 TOs. The RF180C supports both modes; see the SIMATIC Ident system manual on the Siemens Industry Online Support portal for the library and block descriptions.

Steps in TIA Portal:

1. Open the project tree, expand Technology objects > Ident, and delete the four existing Ident TOs (TO_Ident_1 through TO_Ident_4). Confirm the deletion in the dialog.
2. In the device view, keep the four RF180C nodes. Set the RF180C PROFINET device name and IP address for each.
3. Open Libraries on the right side of TIA Portal, expand Global libraries > SIMATIC Ident, and drag the instruction set for RF180C into a program block of your choice. The standard set used for the RF180C is:
   • Ident_Ini, initialize the channel and set the antenna configuration
   • Ident_Read, read a tag UID or user data
   • Ident_Write, write user data to a tag
   • Ident_Reset, reset the channel after a fault
   • Ident_GetStatus, query the current channel and reader status
4. For the RF280R readers on each RF180C channel, the block input command takes the values 1 (read UID), 2 (read data), 3 (write data), 4 (next), 5 (inventory), and so on. Map the readers to the two physical reader ports using the RF180C configuration under Device view > RF180C > Channel 1 > Reader 1 / Reader 2.
5. For each RF180C channel, call Ident_Ini in OB100 (startup) or OB1 on first scan, then call Ident_Read or Ident_Write in OB1 with a duty cycle appropriate to the application (typical: 50 to 200 ms per channel to avoid RF180C channel saturation).

Block parameter template for the read call in Structured Text:

// One read per OB1 scan, sequential per channel
IF "rfCh1".cmdBusy = FALSE THEN
  "Ident_Read_1"(
    REQ       := "rfCh1".req,
    ID        := "rfCh1".hwId,    // hardware identifier from device view
    CMD       := 1,               // 1 = read UID
    LEN       := 0,
    DATA      := "rfCh1".buf,
    DONE      => "rfCh1".done,
    BUSY      => "rfCh1".cmdBusy,
    ERROR     => "rfCh1".err,
    STATUS    => "rfCh1".status
  );
END_IF;

This drops the TO reservation, frees the per-channel submodule slot, and lets the 1512SP-1 PN host the four S120 TOs plus four RF180C channels. You lose the TO-level diagnostics (the technology object view in TIA Portal) and gain a programmatic interface that is easier to step through in the watch table.

Solution Option 3: Handle the S120 Drives with Standard Telegrams

If the project is motion-control-light (open-loop speed or torque control on the four axes) and TO support is not strictly required, drop the S120 TOs and use standard Siemens telegrams (typically telegram 1, 2, 3, or 5) with the standard drive blocks (SINA_SPEED, SINA_POS, or the S7-1500 TO-free blocks in the SINAMICS library). The CPU then has the headroom to host the four RF180C Ident TOs. Telegram 105 and 111 are the TO-bound telegrams that the motion-control features require; the standard telegrams 1, 2, 3, and 5 do not reserve the per-axis submodule and IRT slot block that causes the saturation here.

Steps:

1. Delete the four S120 TOs from the project tree.
2. In the device view of each S120, set the telegram to 1 (speed control, 32-bit) or 2 (speed control, 32-bit plus 16-bit status word). If positioning is required, set the telegram to 3 or 5 and use the SINA_POS block from the SINAMICS library.
3. Add the SINAMICS S120 support package (TIA Portal > Options > Support Packages > SINAMICS S120). Drag SINA_SPEED or SINA_POS into a program block and call it per axis from OB1.
4. Download to the CPU. The S120 ARs establish with the smaller standard-telegram submodule set, freeing the per-interface PROFINET budget for the four RF180C Ident TOs.

You lose TO-based motion-control features (the cam editor, synchronous operation, the S7-1500 Motion Control diagnostic faceplate) but retain the ability to set speed and position references and to read status. For a conveyor or indexing application that does not need electronic gearing or camming, this is the lightest path to coexistence.

Solution Option 4: Use a Second PROFINET Interface

The 1512SP-1 PN has one PROFINET interface (X1). If the same project is re-homed on an S7-1515SP-2 PN (two PROFINET interfaces) or an S7-1516-3 PN/DP, split the IO classes: S120 on X1, RF180C on X2. Each interface has its own submodule, IRT, and record-data budget, so the saturation cannot cross the interface boundary. This is functionally a sub-case of Solution Option 1 but is the cleanest architectural fix because the two device classes never compete for the same interface budget. If you ever expect to grow the RFID count, isolate the RFID PN segment from the drive PN segment from the design stage.

Verification Procedure

After applying the chosen solution, verify on the running system before commissioning the line:

1. In TIA Portal, go online with the CPU. All 8 IO devices (4 S120 + 4 RF180C) must show a green check in the device view.
2. Open the CPU diagnostics buffer. There must be no PROFINET IO error entries since the last download.
3. Open the S120 drive TOs (or the SINA_SPEED / SINA_POS instances) in the watch table. Force a zero reference on each axis and confirm the drives respond without PROFINET dropouts.
4. Open the RF180C instance for each channel. Trigger an Ident_Read on a tag placed on the reader. Confirm the DONE bit sets within the expected duty cycle and the DATA buffer contains the tag UID.
5. Run a 30-minute soak test with continuous reads on all four RF180C channels and continuous S120 motion at rated speed. Watch the CPU PROFINET interface statistics for any port error counter that climbs. The counters must stay flat.
6. On the TP 700 Comfort HMI, switch between the S120 status faceplate and the RFID tag-list screen. Verify that both update without a visible stall.
7. Power-cycle the CPU and confirm the ARs come up cleanly on cold start in the documented order (drives first, then RFID) without manual intervention.

Preventive Design Practices

Three rules to apply on the next project of this class:

• Read the CPU function manual for the exact TO, motion-control, and PROFINET submodule budgets at the firmware version you are targeting. The numbers in the marketing datasheet are not the same as the per-interface submodule budget. The S7-1500 and ET 200SP function manual Cycle and Response Times, on the Siemens Industry Online Support portal, is the authoritative document.
• When the design includes both motion-control TOs and Ident TOs, leave a 25% headroom in the per-interface PROFINET submodule count. The IO device count check is not sufficient; the submodule count and IRT slot count are the actual gating factors, and the saturation presents as an AR rejection on the most recently added device class, not on the most recently added device.
• If the controller class is locked (by panel cutout, by ET 200SP head-module choice, or by project budget) and the IO device list grows, fall back to the manual instruction libraries (Ident library, SINAMICS library) before increasing the CPU class. The manual approach is also faster to debug because the watch-table path is the same as the program path; TOs add an opaque dispatcher layer between the user program and the device that complicates fault analysis.

FAQ