Troubleshooting SIMOCODE Pro PROFIBUS Feedback Fault F9C1:237B

Problem Overview

A SIMOCODE pro motor management and control device fails to start its assigned motor after a plant shutdown. The PROFIBUS DP link reports as healthy (no station failure, no diagnostic interrupt for the slave itself), the motor is mechanically available, and the PCS 7 program logic still references the correct I/O tags. When the operator issues a run command, the output block toggles but no start confirmation returns, and the HMI raises a "feedback fault" alarm. The same SIMOCODE pro hardware and the same PCS 7 program drive other motors without issue.

Observed behavior in the field:

• Replacing the SIMOCODE pro unit and keeping the original PROFIBUS address does not clear the fault.
• Changing the PROFIBUS address of the SIMOCODE pro (and the matching address in the STEP 7 / HW Config) restores normal operation.
• No duplicate address is found on the segment; all other slaves continue to communicate.

This combination — "good bus, bad feedback, address change fixes it" — is the fingerprint of a DP slave reinitialization problem rather than a wiring, GSD, or program logic defect.

System Architecture Context

The reported installation is built on the Siemens SIMATIC PCS 7 process control system:

The CP 443-1 acts as the PROFIBUS master for the DP segment, the AS 400 CPU is the host controller, and the SIMOCODE pro units are the leaf nodes. The DP slave exchange is cyclic I/O data plus acyclic record reads/writes for parameterization and diagnostics.

Diagnostic Event Decoding

The CPU's diagnostic buffer (visible in STEP 7 via PLC → Diagnostic/Setting → Diagnostic Buffer, or in PCS 7 via WinCC Explorer → Diagnostics) reports the following entry:

Event 4 of 128 — Event ID 16# F9C1:237B

Data record could not be read

A data record could not be read from slot 0 of slave 85.

Error: 80B0 — Object not obtainable

External error, Incoming event — 03:58:22.823 PM 06/04/2014

Event ID F9C1:237B Breakdown

Error Code 80B0

Status 0x80B0 returned on a DPV1 READ / WRITE call is the standardized PROFIBUS DP-V1 negative acknowledgement "Object not obtainable / object does not exist". The master issued a record access (slot 0, index 0..255) and the slave acknowledged the request but the requested object (parameter block, diagnostics block, or identifier) could not be returned within the configured monitoring time.

Important: 0x80B0 is not a bus-physical fault. The slave is online, alive, and answering the master's poll. What is missing is the application's ability to read a defined data record from slot 0 of the device — typically the SIMOCODE's parameter, statistics, or command object block.

Root Cause: DP Slave Not Reinitialized After Restart

When a SIMATIC S7 CPU restarts, the standard startup sequence is:

1. Power-on / restart / cold restart executes OB 100 / OB 101 / OB 102.
2. Once user OB 1 begins cyclic execution, the DP master (CP 443-1) sends the configured parameterization telegram (Set Prm) and checks the configuration (Chk Cfg) to every configured slave, in the order of the HW Config.
3. On positive response, the slave transitions to Data Exchange and the master starts cyclic I/O.

The PROFIBUS slave has internal object dictionaries for SIMOCODE pro: the parameter set, the actual values (process image), the statistics buffer, the function blocks, and the command interface. These are stored in non-volatile memory on the device. If a Set Prm — or more typically a re-parameterization via SIMOCODE ES (TIA Portal) or SIMOCODE pro Manager — left an object in a state the device cannot serve, the next acyclic read returns 0x80B0.

The defining symptom is: the device is on the bus, the I/O is exchanged (or partially exchanged), but one or more acyclic objects on slot 0 are unattainable. Changing the PROFIBUS address forces the master to treat the device as a new station: a fresh Set Prm and Chk Cfg is sent, all objects are re-initialized, and the bad object recovers. The HW Config slot assignment and slave address are updated together so cyclic I/O resumes against the correct image.

Why a Replacement SIMOCODE Pro with the Same Address Did Not Help

A brand-new SIMOCODE pro unit populated with the same parameter set and installed at the same PROFIBUS address should clear the fault — provided the master's view of that address is the only thing being re-sent. If the same fault appears on the brand-new device, the cause lies above the slave:

• The HW Config entry still references an old device description, GSD revision, or slot mapping.
• The CP 443-1 has cached the parameterization for that address from the previous device and is not re-issuing it.
• The startup OB on the CPU is not running the channel-driver and module-driver blocks (CFC: CH_DI, CH_DO, MOD pairs) for this slave.

This is why the SIMOCODE pro itself is exonerated and the master / configuration is in scope.

Step-by-Step Troubleshooting Procedure

Follow this sequence before changing the PROFIBUS address. Each step is a real diagnostic you can capture in PCS 7 or STEP 7.

Step 1 — Capture the Full Diagnostic Buffer

1. Open STEP 7 Manager, select the AS 400 project, go online.
2. Select PLC → Diagnostic/Setting → Diagnostic Buffer.
3. Export the complete buffer to a text file. Look for any distributed I/O, DP slave, or CP 443 entries around the time of the last CPU restart.
4. Record the exact slave address, slot, and event ID for every DP fault event.

Step 2 — Read the CP 443-1 Diagnostic Buffer

1. In HW Config, double-click the CP 443-1 module.
2. Select Diagnostics → Diagnostic Buffer (requires the CP to be online and configured for diagnostics).
3. Note any DP Master errors, "Slave not found", "Slave failed", or "Diagnostic interrupt from slave 85".

The CP 443-1 buffer is the right place to find the DP layer's view of the same event — the CPU buffer only records what crosses the backplane.

Step 3 — Read the SIMOCODE Pro Local Diagnostics

1. Connect a PG/PC to the SIMOCODE pro via the system interface (X8 front port) or via Ethernet on the -IP variant.
2. Open SIMOCODE ES (TIA Portal) or SIMOCODE pro Manager.
3. Go online with the device, open Diagnostics → Event Log and Diagnostics → Status.
4. Export the event log. Look for events flagged as "PROFIBUS", "parameterization", or "configuration mismatch".

The local diagnostics often show a C2/C3/C4 service rejection that the CPU never sees, because it is below the DP-V1 layer.

Step 4 — Verify HW Config Consistency

1. Open HW Config in the PCS 7 project.
2. Locate the DP slave object representing the SIMOCODE pro at the affected address.
3. Right-click → Object Properties. Compare:
   • PROFIBUS address (must match the rotary switches on the device).
   • Slot 0 module type and order number (e.g. 3UF7011-1A..., 3UF7013-1A...).
   • Firmware version targeted by the GSD file.
   • Diagnostic interrupt enable / behavior.
4. Cross-check every other SIMOCODE pro on the segment. The HW Config entry for the failing slave must match a working slave — same GSD, same module, same firmware.

Step 5 — Verify the GSD File and Firmware Match

1. Identify the GSD file in use: HW Config → Options → Install GSD File. Note the GSD name and revision.
2. On the device itself, read the firmware version from the local diagnostics or from the type label.
3. If the device's firmware is newer than the GSD supports, parameterization can succeed with reduced features; if the firmware is older than the GSD assumes, the slave may reject objects the master requests. In either case, re-import the matching GSD and recompile HW Config.

Step 6 — Verify Startup OB and Module Drivers

1. In the S7 program (CFC), open the chart that owns the affected motor block.
2. Confirm the channel drivers (CH_DI, CH_DO) and the module driver (e.g. MOD_PB, MOD_DPV1) blocks are present.
3. Right-click each block → Object Properties → Block. Confirm the block is installed in OB 1 (or, for PCS 7 standard driver blocks, in the cyclic OB and not in OB 100). The startup OB (OB100) is not the right place for cyclic channel drivers; however, the initialization logic (parameter set download, command interface priming) must run after CPU restart and before the operator issues a start.
4. Compile and download the program. Re-test.

Step 7 — Force a DP Slave Reinitialization (Without Changing the Address)

If steps 1-6 are clean, force the CP 443-1 to reissue Set Prm to the affected slave. This is the recommended long-term fix and avoids moving the device to a new address.

1. Open HW Config and go online.
2. Select the DP master system on the CP 443-1.
3. Right-click the affected slave → DP Slave → Assign Master, or use DP → Initialize Slave (menu and availability depends on the STEP 7 / PCS 7 version).
4. Alternatively, use the standard PCS 7 block MOD_DPV1 with the REINIT input driven from the operator faceplate, or call the system function block SFB 52 / SFB 53 with a forced parameter record write to slot 0.
5. Watch the diagnostic buffer. The 0x80B0 event should be replaced with a normal parameterization handshake.

Step 8 — Validate with the Operator Faceplate

1. Switch the WinCC faceplate for the affected motor from Manual Off to Manual On.
2. Confirm a positive feedback (running bit) within the configured feedback time (typically 3-5 s for a DOL starter; up to 15 s for a star-delta or soft start).
3. Toggle to Manual Off and confirm the stop feedback within the configured time.

Why the Address Change Worked

Changing the PROFIBUS address of a SIMOCODE pro requires:

1. Setting the new address on the device's rotary switches (or via SIMOCODE ES, with the device in "Parameterization" mode).
2. Updating the matching address in HW Config and re-downloading HW Config to the CPU.
3. Re-downloading the S7 program (so that the symbolic I/O references resolve to the new slot / new diagnostic address).

Steps 2 and 3 cause the CP 443-1 to rebuild the DP master system table. The next CPU restart treats the slave at the new address as a station never seen before: full Set Prm, full Chk Cfg, full object initialization, and the bad object disappears.

The trade-off: an address change invalidates every diagnostic reference (WinCC alarm tags, asset references, and the topology of the DP master system) tied to the old address. It is a useful smoke test, but it is not a permanent fix.

Long-Term Recommendations

Verification Matrix

Related PROFIBUS Failure Modes

Address-induced reinitialization is one of several recovery paths for DP segment issues. Other common root causes in industrial field installations include:

• Repeater power supply or repeater hardware failure, which can leave a segment of slaves invisible to the master while still passing the fieldbus termination. A failing repeater can mimic the symptoms described above on a sub-segment.
• Termistor-on / terminator-off segments, which cause intermittent station dropouts and cyclic re-entry into Data Exchange.
• Duplicate address on the segment, which prevents all conflicting slaves from completing parameterization (not just one).
• Shielding or EMC-induced single-bit errors on long cable runs, which produce retry storms and timing-window object failures.

A structured approach to PROFIBUS diagnostics — from the physical layer up to the DP-V1 object layer — is the fastest way to localize these. Capture the bus trace with a PROFIBUS analyzer (e.g. Softing PROFINET/PROFIBUS diagnostic tool, Indu-Sol PROFINET/PROFIBUS diagnostic tool) before the device recovers; once re-initialized, the bus state is lost.

Quick Reference: Decoded Event F9C1:237B

Recommended References

• SIMOCODE pro System Manual — 3UF7 — parameterization, PROFIBUS DP interface, slot 0 object list, diagnostic event codes.
• STEP 7 / TIA Portal online help — "PROFIBUS address" — subnet properties and per-slave address assignment.
• CP 443-1 manual — DP master mode, diagnostic buffer layout, DPV1 read/write service handling.
• PROFIBUS & PROFINET International (PI) — installation guideline for PROFIBUS DP/FMS, grounding and shielding.

FAQ