Resolving Siemens CP342-5 BUSF Blinking and PROFIBUS Error 16# F9C1:236C

The Siemens CP 342-5 communications processor is the workhorse PROFIBUS interface for S7-300 stations. When the front-panel BUSF LED starts blinking and the CPU diagnostic buffer records Event ID 16# F9C1:236C with the text "Output data length: The output data length for the DP_SEND block 144 bytes is too high. The configured output data length is 112 bytes," the controller is telling you that the cyclic output payload you are pushing through DP_SEND does not match the slave's configured slot in HW Config. This article walks through the exact diagnostic path, root cause, and corrective procedure for this error, including the secondary issue of an FB call pointed at the wrong CP hardware identifier.

1. Affected Hardware and Software Versions

2. CP 342-5 LED Status Reference

The CP 342-5 front panel carries four primary indicators. The BUSF LED is the dominant error indicator for the error class discussed here.

A blinking BUSF with diagnostic event 16# F9C1:236C always means the CP successfully completed parameter assignment and entered data exchange, but a cyclic I/O length violation was detected against a slave that had been acknowledged by the master. The PROFIBUS stack remains "up," which is why RUN stays green.

3. Anatomy of Diagnostic Event 16# F9C1:236C

The Siemens S7 diagnostic event is a compound 32-bit identifier. The high word identifies the source module class, the low word identifies the specific error.

• 16# F9C1 – Source: CP 342-5 (PROFIBUS DP master, communications error class)
• 236C – Event sub-code: DP_SEND output length exceeds configured DP slave output length

The accompanying text is generated by the CP 342-5 firmware and contains the exact length values offending the stack:

Event 1 of 35:  Event ID 16# F9C1:236C
Output data length: The output data length for the DP_SEND block 144 bytes
is too high. The configured output data length is 112 bytes.
External error, Incoming event

From this single event the engineer can derive three facts:

1. Block DP_SEND is being called with a payload of 144 bytes.
2. HW Config has only reserved 112 bytes of consistent output for the addressed slave.
3. The CP is rejecting the call to prevent writing beyond the slave's GSD-defined input buffer.

4. Root Cause Analysis

4.1 Primary Cause: DP_SEND Length > Configured Slave Length

The most common trigger is a modification to the application program (typically a data block expansion or pointer re-sizing) that increases the LEN input of DP_SEND without a matching change in HW Config. The reverse case (LEN too small) does not raise F9C1:236C – instead the CP truncates without error – which is why the alarm fires asymmetrically.

4.2 Secondary Cause: Wrong Hardware Identifier (HW ID) on DP_SEND / DP_RECV

The CP 342-5 is identified in STEP 7 by an HW ID assigned automatically when the module is dragged into HW Config. The CALL instance of DP_SEND must reference this HW ID. Common mistakes:

• A second CP 342-5 was added to the project (e.g. CP 343-1 Lean for Ethernet) and the FBs are still pointed at the original slot.
• The CP was re-inserted at a different slot after a rack change, changing the HW ID without updating the FB calls.
• A copy/paste from another station brought the wrong HW ID along.

Symptom in this category: a "module not found" diagnostic, or a different slave's data showing on the wire. The diagnostic buffer may show a follow-up 16# F9C1 event with a sub-code pointing to a non-existent logical address.

4.3 Tertiary Cause: Slave GSD Re-import Changed the Slot Layout

If a PCD3.M3230 firmware update introduced a new GSD revision and the GSD was re-imported into STEP 7, the slot/channels may have been re-mapped. The 112-byte figure in the diagnostic reflects the current HW Config, not the GSD on disk.

5. Diagnostic Buffer Reading Procedure

The S7 CPU diagnostic buffer is the canonical source of F9C1 events. Open it via:

1. SIMATIC Manager → PLC → Online → Accessible Nodes, or in TIA Portal: Online & Diagnostics → Diagnostic buffer.
2. Right-click the S7-300 station and choose "Online & Diagnostics."
3. Open the Diagnostic Buffer node. Use the Save As… button to export the buffer as a plain-text file for archival – this preserves the hex event IDs and timestamps for later analysis.
4. Scroll to the first occurrence of 16# F9C1:236C and note the offending block and length values.

For an offline view of the same event classes, the STEP 7 online help under Help → SFCs / SFBs → DP_SEND lists the F9C1 sub-code family and the lengths in the error byte RET_VAL of the block call.

6. Step-by-Step Resolution

6.1 Locate the DP_SEND Call

Open the project, navigate to the block that contains the call, and double-click the DP_SEND instance. Record:

• The CALL instance (HW ID, displayed as a hex constant such as W#16#0100 or a symbolic name in TIA Portal).
• The LEN input value (in the reported case: 144 bytes).
• The SEND input pointer (P#DBxx.DBXy.z BYTE n).

6.2 Verify the CP 342-5 HW ID

In HW Config, right-click the CP 342-5 in the rack and choose "Object Properties…". The Diagnostics tab lists the HW ID. Compare it to the value the FB is calling. If they differ, update the FB's CALL parameter, recompile, and download.

6.3 Match the LEN to the HW Config Slave Slot

1. Double-click the DP master system line on the CP 342-5.
2. Click the PCD3.M3230 slave in the station list.
3. Open "Object Properties → Configuration → Module / Slot" for the slave. The "Configured length" column shows what the master reserves for that slave's outputs.
4. If LEN > configured length (144 > 112 in our case), do one of the following:

• Option A (preferred): Increase the configured output length in HW Config to match the LEN parameter – provided the PCD3.M3230 GSD supports the requested length. Re-compile HW Config and download to the CPU and CP.
• Option B: Reduce the LEN input on DP_SEND to match the configured 112 bytes, and ensure the SEND source pointer covers only that area.

6.4 Recompile and Download

1. Save and compile HW Config (Station → Save and Compile).
2. Download the HW Config to the CPU (target system → Download). This includes the modified PROFIBUS parameters to the CP 342-5.
3. Download the modified blocks (DP_SEND, DP_RECV) to the CPU.
4. Perform an S7 CPU STOP → RUN transition to re-establish the DP master role.

6.5 Confirm BUSF Clears

After RUN, observe the CP 342-5:

• RUN stays green
• BUSF off
• Diagnostic buffer shows "Outgoing event" for the F9C1 family

7. DP_SEND / DP_RECV Programming Reference

The DP_SEND and DP_RECV function blocks (FC3 and FC4 in the SIMATIC NET CP 342-5 library) implement the DP master interface. They are not SFCs – they are part of the library supplied with the CP and must be present in the S7 program.

Critical programming rules that prevent the F9C1:236C event in the first place:

• Always size LEN as a constant equal to the configured output slot length, not as a dynamic expression.
• Initialize the SEND pointer with a fully qualified P# reference; a relative DB pointer without an explicit BYTE length will lead STEP 7 to assume zero bytes and reject the SEND on the very first call.
• Use DP_RECV with the matching length to read the slave's input area symmetrically.

8. Configuring the Saia PCD3.M3230 as a DP Slave

The PCD3.M3230 CPU is the mid-range member of the Saia PCD3 family. PROFIBUS DP slave connectivity is provided by the PCD3.F221 (PROFIBUS DP slave) or PCD3.F281 modules installed in the Saia backplane. Configuration steps on the Saia side:

1. In Saia PG5 (or the current SBC tool), open the PCD3 project and add the F221/F281 module to the slot list.
2. Open the PROFIBUS configuration dialog and define the number of input bytes and output bytes exchanged with the master. This determines the GSD file on the Saia side.
3. Set the PROFIBUS station address to a unique value (1–125). The three PCD3.M3230s must be at distinct addresses; duplicate addresses cause a steady BUSF rather than the blinking pattern of F9C1:236C.
4. Export the GSD file from the Saia tool and import it into STEP 7 HW Config. The imported GSD defines the slot/module listing used in the master configuration.

9. Verification and Commissioning

After applying the corrective actions, run the following checks to confirm the F9C1:236C event is closed and the DP network is healthy.

1. LED check: BUSF off, RUN solid green on the CP 342-5. On each PCD3.M3230, the PROFIBUS LED should show active data exchange (typically a steady or fast-blinking green LED labelled "BF" or "DX," depending on the F-module revision).
2. Diagnostic buffer: Confirm an "Outgoing event" for the F9C1 family. No new "Incoming event" entries should appear after the next STOP → RUN cycle.
3. Online view in HW Config: Right-click the DP master system → PROFIBUS → Online. All three PCD3 slaves should appear with status "OK" and a green check.
4. Watch table: In STEP 7, open a VAT or watch table and force a known pattern into the SEND area. Observe the input image on the slave side (using Saia PG5 debug tools) and confirm byte-by-byte consistency.
5. Cyclic payload audit: Print the configured slot lengths from HW Config and the LEN values from every DP_SEND call. The two lists must match. A useful KPI is to maintain a project-wide spread-sheet of Slave → OutputLength → DP_SEND_LEN → DP_RECV_LEN rows.

10. Troubleshooting Matrix

11. Field-Proven Best Practices

• Version-pin the GSD: Keep a single canonical GSD for the PCD3.M3230 slaves in a project library. Mixing GSD revisions on a multi-slave segment is a frequent source of intermittent BUSF.
• Avoid dynamic LEN: If the application needs to transmit variable payloads, segment them into multiple DP_SEND calls with fixed lengths, each tied to a dedicated HW Config slot. The CP 342-5 does not resize a slot on the fly.
• Pre-allocate the SEND ANY pointer: Declare a stand-alone DB large enough for the maximum planned payload. Always reference the same area from DP_SEND; never use a temporary pointer assembled at runtime.
• Document every DP_SEND / DP_RECV call in the program header with the expected length and the target slave. This makes the next engineer's review straightforward and prevents accidental drift.
• Capture the diagnostic buffer to file on every commissioning step. The export is a plain text file, easy to diff and easy to attach to a change request.
• Keep CP 342-5 firmware current. Siemens released several firmware versions for the 5DA02 hardware that tightened the validation of LEN values and improved the diagnostic event text.

12. Related Diagnostic Event Codes (CP 342-5)

13. Frequently Asked Questions