Resolving CP340 FB2/FB3 Compile Error on Siemens CPU 314 (S7-300)

The Siemens CP 340 point-to-point communication processor ships with a library of function blocks (FB2, FB3, FB4 etc.) for serial send/receive handling. On older S7-300 CPUs that ship with the legacy command set and a single-system-function-block (SFB) limit, the example FBs from the newer "CP PtP" library will fail to compile in STEP 7 and refuse to download. This article documents the root cause, the diagnostic steps, and the field-proven workarounds for a CPU 314 (6ES7 314-1AE04-0AB0) paired with a CP 340 (6ES7 340-1AH02-0AE0).

1. Problem Description

When configuring a Datalogic barcode scanner against a CP 340 (6ES7 340-1AH02-0AE0) on a CPU 314 (6ES7 314-1AE04-0AB0), the user copies the example project shipped with the CP onto the CPU. The hardware configuration is downloaded successfully and the CP is recognised. As soon as the user attempts to download the supplied receive block (FB2 P_RCV / FB3 P_SND) into the PLC, STEP 7 reports:

• Error: Unable to copy block FB2
• Details tab error: (D280) Error compiling the block in S7-300 CPU

The STEP 7 diagnostic text for the (D280) event reads:

Correct the illegal address, the command, or the lock number, or reduce the number of transfer parameters.

The PLC remains in RUN; the FB simply never reaches load memory. The user cannot download the missing SFBs (SFB 52 / SFB 53) manually because the download button is greyed out in the SFB container once the CPU is online.

2. Root Cause Analysis

The CPU 314 (6ES7 314-1AE04-0AB0) is an early S7-300 module whose technical data documents a deliberately small command set. The relevant excerpt from the device manual is:

The "one SFB slot" line is the key constraint. The modern CP 340 / CP 341 / CP 440 / CP 441 "CP PtP" example library (sometimes referred to as library v2.0) is written against SFB 52 (RDREC) and SFB 53 (WRREC) for parameter data-set reads and writes to the CP module. On a CPU 314, only one SFB instance can exist in the SFB container, and the firmware (v1.0.0 on the affected unit) does not provide SFB 52/53 as built-in resources. The FB therefore references unresolvable SFB calls, which is what surfaces as the D280 compile error.

The compile error is not a memory-size error. Even when the user has confirmed several KB of free load and work memory through the online Module Information dialog, the block is still rejected because the SFB system calls themselves cannot be bound.

3. Library Version vs. CPU Generation

Siemens shipped two distinct example libraries with the CP 340 over the product's lifetime:

If the project was created from a newer example or a newer STEP 7 install, the FBs dragged into the S7 program are the v2.0 variety. They look identical at the symbol level (P_SEND / P_RCV) but generate calls to SFB 52 / SFB 53 internally. The v1.0 library has been confirmed by multiple field installations to work on a CPU 314 (1AE04) firmware 1.0.0 with the same CP 340 hardware, which is the cleanest workaround.

4. STEP 7 Diagnostic Procedure

Use the following ordered procedure to confirm the root cause before applying any change:

1. Capture the exact error. In STEP 7 Manager, attempt the download again and record both the high-level message (Unable to copy block FB2) and the (D280) detail text.
2. Inspect the FB source. Open the offline FB2 in the LAD/FBD/ST editor and locate every CALL SFB 52 / CALL SFB 53 statement. The presence of these calls identifies a v2.0 library block.
3. Check the SFB container online. Connect online (Ctrl+PLC > Accessible Nodes or via the configured MPI address), then open PLC > Module Information > Performance Data (or CPU > S7 Communication on newer STEP 7 versions). The SFB list will show what is built into the firmware. On the CPU 314 (1AE04) the SFB list is empty or contains only one slot.
4. Verify free memory. In Module Information > Memory, confirm the load and work memory figures. The D280 error is not triggered by low memory; ruling this out is still part of the diagnostic to avoid chasing the wrong cause.
5. Try to download SFB 52 / 53 manually. Right-click the SFB in the standard library, choose Download, and observe whether STEP 7 enables the action. On a CPU 314 the SFB container is locked and the download button is greyed out — this is the definitive confirmation that the SFBs cannot be added to this CPU.

5. Solution Path 1 — Use the CP PtP v1.0 Library

Re-source the example program from the legacy library version. The exact procedure is:

1. Open STEP 7 and the project containing the CPU 314 / CP 340 hardware configuration.
2. From the original CP 340 driver CD (or the legacy CP_PtP_V1 archive), open the example project CP340_PtP_Example.
3. Copy the FBs (typically FB2 P_SEND and FB3 P_RCV) and any companion DBs / UDTs into the offline S7 program of your own project, replacing the v2.0 blocks.
4. Update the instance DBs to match the v1.0 FB interface; the symbol names are usually the same, but the variable list differs.
5. Recompile the program (Ctrl+B / Program > Compile All) and download to the CPU.
6. Confirm via the online Module Information that the FB is now in load memory and the CPU remains in RUN.

The v1.0 library is the only configuration that has been confirmed in service to run on the CPU 314 (1AE04) FW 1.0.0 with the CP 340. It exposes the same send/receive symbol layer (FB2 P_SEND / FB3 P_RCV) so the rest of the application logic does not need to be rewritten.

6. Solution Path 2 — Replace the CPU

If the application requires the v2.0 library (for example because MODBUS master functionality is needed and is only implemented in v2.0), or if the SFB 52/53 calls are propagated into custom blocks that cannot be downgraded, the only clean fix is to replace the CPU with a module that supports the SFB 52/53 firmware resources. Candidates from the same S7-300 family are:

When replacing the CPU, retain the existing CP 340 (6ES7 340-1AH02-0AE0) and the original hardware configuration; only the rack slot for the CPU and the project-side module assignment change. Recompile and download the unmodified (v2.0) program to the new CPU. The D280 error should clear immediately because the missing SFBs are now resolved against the firmware-resident instances.

7. Solution Path 3 — Migrate to S7-200 / S7-1200

For a Datalogic barcode-scanner data-collection cell, the user may decide that the lifecycle cost of supporting an early S7-300 CPU no longer makes sense. The viable migrations are:

• S7-200 with a freeport library. The S7-200 family supports RS232 / RS485 freeport communication natively and has well-tested example projects for barcode readers. The freeport receive/transmit interrupts substitute for the CP 340's hardware-buffered protocol handling.
• S7-1200 with a CM1241 (RS232 / RS485) or CB 1241. The S7-1200 supports modular PtP via the PtP_Point-to-Point instruction set, with built-in SFB-equivalent system calls. The program is rewritten in TIA Portal, not STEP 7.

Migrations are appropriate when the existing system is being modernised anyway; they are not the smallest fix for a like-for-like CP 340 / barcode-scanner rollout.

8. Memory Configuration Notes

Although the D280 error on the CPU 314 is not a memory error, it is worth confirming that the S7-300 load memory and work memory are sized correctly for the application. On the CPU 314 (1AE04) the relevant published figures are:

• Work memory (integrated): 64 KB for code, 64 KB for data
• Load memory: 64 KB RAM, expandable via MMC up to 8 MB (firmware-dependent)

When the v1.0 library FBs are used, the combined footprint of FB2 + FB3 + instance DBs is on the order of a few KB. There is no realistic risk of an out-of-memory condition with a single CP 340 + barcode scanner configuration. If the project is in a micro-memory card, check that the card is not write-protected (the write-protect tab on the MMC) and that the card type matches the CPU's compatibility list; mismatched MMCs can produce other D2xx errors that look superficially similar.

9. Hardware Configuration Pre-checks

Before changing any software, verify the physical configuration is sound:

1. CP 340 is seated in a slot of the S7-300 rack; backplane bus connectors are clean.
2. The CP 340's RS232 / RS485 / TTY sub-module (6ES7 340-1AH02-0AE0 ships without; verify the sub-module is present, e.g. 6ES7 340-1BA02-0AE0 for RS232).
3. CPU is in RUN (or RUN-P) with no SF / BF LEDs lit; the BF LED on the CP 340 will extinguish once the hardware configuration is downloaded.
4. STEP 7 hardware catalog entry for the CP 340 matches the firmware of the physical module.
5. Datalogic scanner is configured for the same baud rate, parity, and frame as set in the CP 340 hardware configuration (the default in most Datalogic factory defaults is 9600, 8, N, 1).

10. Verification

After applying Solution Path 1 (v1.0 library) or Path 2 (CPU replacement), perform the following checks:

1. Download succeeds. STEP 7 reports Block downloaded successfully for both FB2 and FB3; no (D280) event is logged in the diagnostic buffer.
2. CPU stays in RUN. Mode selector in RUN; no STOP transitions after the download.
3. Online block view. Right-click FB2 in the online view; the source code is visible and the SFB calls (if any) resolve cleanly.
4. Send a test string from the Datalogic scanner. Watch the receive DB in STEP 7 (VAT / monitor / modify) increment; confirm length and data match the expected barcode payload.
5. Trigger a send from the PLC. Use a VAT to set the request bit on FB2 (P_SEND) and confirm the scanner echoes / acknowledges as expected.
6. Diagnostic buffer clean. Open PLC > Module Information > Diagnostic Buffer; only normal mode-change events should be present.

11. Troubleshooting Matrix

12. Field-Proven Cautions

• The CPU 314 (1AE04) cannot be upgraded to gain SFB 52/53 resources by firmware update alone; the SFB inventory is defined by the CPU's ASIC set, not by the firmware revision.
• Do not edit the v2.0 FB source to remove the SFB 52/53 calls. The data-set exchange with the CP 340 requires those calls; stripping them breaks the protocol and produces silent communication failures that are harder to diagnose than the original D280 error.
• If you keep the CPU 314 and use the v1.0 library, lock the project in STEP 7 against re-importing the v2.0 library by accident. The two libraries share symbol names, so a copy/paste from a colleague's project can silently re-introduce the problem.
• When a barcode scanner is being added to a cell that has a more modern CPU already, prefer reusing the modern CPU rather than introducing a fresh S7-300 / CP 340 stack; the lifecycle outlook for the 314 (1AE04) is limited.

FAQ