Resolving S7-400 Error D20C: OB Cannot Be Copied Priority Class

Problem Overview

When downloading a STEP 7 project to a SIMATIC S7-400 CPU 414-2XJ00-0AB0 (MLFB 6ES7 414-2XJ00-0AB0), the engineering station reports that OB1 transfers cleanly, but OB2 and OB3 fail with the STEP 7 / SIMATIC Manager error:

The error is generated by the target CPU's online operating system and is returned through the PG/PC online interface when STEP 7 attempts to write the OB's load image and configuration blocks. It is a class-of-priority (priority class) validation failure, not a memory or syntax problem: the OB object itself is structurally valid, but the OB number / priority class combination you have placed in your offline project is not part of the set of OBs the firmware of the S7-400 CPU 414-2 is willing to instantiate at the requested priority.

Typical conditions that surface this fault:

• Project contains OBs imported from a foreign controller family (e.g., S7-300, S7-1200, WinAC, or a third-party PLC).
• OB numbers were created in SIMATIC Manager > Blocks with the symbolic name left empty and the OB number picked arbitrarily (here, 2 and 3).
• OB priority class was edited in the OB properties and set to a value the CPU firmware does not support.
• The OB was created in an S7 project whose CPU type was changed (e.g., from 414-2 to 412-1 or to an S7-300 CPU) without re-validating the priority settings.

Error Code D20C: Definition

The diagnostic code D20C is surfaced in the Online > Accessible Nodes download log and in the STEP 7 Module Information > Diagnostic Buffer as a class-1 download error. According to the S7-300/400 system software reference, the meaning is:

The fault is signalled when the CPU receives a download record for an OB whose OB number + configured priority class pair does not match any of the OB slots the firmware has compiled into the system data. The CPU rejects the request, leaves the previous load image in place, and surfaces D20C to the PG.

S7-400 Organization Block Architecture

The full enumeration of S7-400 OBs and the symbolic name each OB receives at creation is documented in SIMATIC S7-300/400 System and Standard Functions - Volume 1 and 2. The CPU 414-2 implements the full S7-400 OB catalogue, but only the entries listed below carry a default priority class at the firmware level. Any OB number outside this list must be user-instantiated with an explicit priority class assignment; the firmware does not auto-bind a default priority to it.

Note: OB2 and OB3 are not present in this table. They are not reserved S7-400 OB numbers and the firmware does not bind a default priority class to them. If OB2 or OB3 is created manually, the priority class dialog in the OB's Properties sheet is empty until the user assigns a value, and the CPU will reject the download with D20C if the assigned value lies outside the supported priority band of the CPU.

Priority Class System in S7-400

The S7-400 CPU family supports a priority scheme of 0-27 (with sub-priority 0.x used only for the background OB). The classification is:

An OB only "exists" in the CPU's view when its (OB-number, priority-class) pair is one of:

1. A reserved slot in the firmware's OB catalogue (the table above), or
2. A user-defined slot where the OB number is in the configurable band (OB10-OB47) and the priority class is set to a value in 2-24.

OB2 and OB3 sit in the configurable band only if you instantiate them. The firmware's System Data build does not auto-allocate a priority slot for them, so the download record must contain a priority class value the CPU will accept. If the priority class field of OB2/OB3 in the offline project is empty (no entry) or set to a value the CPU rejects, the D20C fault is generated.

CPU 414-2XJ00-0AB0 Specifications

The target PLC is a member of the SIMATIC S7-400 mid-range CPU family. Key technical data (from the SIMATIC S7-400 CPU 414-2 product manual):

Root Cause Analysis

The diagnostic path for D20C on a CPU 414-2 is:

1. Open the offline project in SIMATIC Manager or TIA Portal (where the source is S7-300/400 compatible) and select PLC > Accessible Nodes or PLC > Download.
2. STEP 7 assembles a download record for each OB that has changed offline. The record contains the OB header (block number, block type, author, version), the priority class, and the OB code.
3. The CPU 414-2 receives the record. Its online operating system checks the (OB number, priority class) against the firmware-resident OB catalogue.
4. For OB1, the priority class is fixed at 1; the CPU accepts the record.
5. For OB2 and OB3, the firmware has no fixed default and no user-configured slot. The priority class field in the offline OB header is empty (the user created the OBs in Blocks without filling in the priority class), so the CPU receives an undefined or invalid priority class value and rejects the record with D20C.

This is why the symptom is exact: OB1 succeeds; OB2 and OB3 fail with D20C. The same fault will appear on every other S7-400 CPU (412-1, 414-3 PN/DP, 416-2, 416-3, 417-4) when the offline project contains user-created OBs in the 2-9 range that have not been bound to a configurable priority class.

Solution Procedures

There are two recovery paths. Pick the one that matches your application's intent.

Path A: Delete OB2 and OB3 (most common)

If OB2 and OB3 were created by accident (e.g., imported from an old project or duplicated from a template that contained a different controller's OB map), delete them. The S7-400 main cyclic program runs entirely from OB1; there is no requirement to instantiate OBs in the 2-9 range.

1. In SIMATIC Manager, expand S7 Program > Blocks.
2. Right-click OB2 > Delete.
3. Right-click OB3 > Delete.
4. Choose PLC > Download. STEP 7 will issue a Delete blocks record for the obsolete OBs and an Insert record for OB1.

Path B: Assign a valid priority class (if OB2/OB3 are intentional)

If you intentionally created OB2/OB3 to act as additional interrupt or cyclic OBs, the priority class field must be set. The supported range on CPU 414-2 is 2-24.

1. Open SIMATIC Manager with the offline project containing the S7-400 station.
2. Double-click OB2 in Blocks.
3. From the LAD/FBD/STL editor, choose File > Properties (or right-click the OB in the block folder and select Object Properties).
4. Open the Priority Class tab. Enter a value in 2-24. A common choice is 2 for time-of-day-style behaviour or a higher value such as 9-15 if the OB is to be used as a fast cyclic.
5. Repeat for OB3. If OB2 and OB3 are to run concurrently, give them distinct priority class values so the kernel can pre-empt correctly.
6. Save and recompile the project (PLC > Compile and Download Objects).

Path C: Rename OB2/OB3 to a valid default-occupied OB

If the project was created from an S7-300 template, the S7-300 default OB catalogue contains OB2 (error) and OB3 (deleted by some firmware versions). These do not exist on the S7-400 by default. The cleanest fix is to rename them to a true S7-400 OB:

1. Right-click OB2 > Rename > type OB10.
2. Right-click OB3 > Rename > type OB11.
3. Open each renamed OB, set the priority class in Properties to a value in 2-24 (default 2 is acceptable).
4. Open HW Config > CPU Properties > Time-of-Day Interrupts and enable OB10/OB11, set the start time and the periodicity.
5. Download the modified blocks.

Verification Steps

After applying one of the recovery paths, confirm the fault is cleared:

1. Choose PLC > Download. The download log should report Download (no error) for every block in the project.
2. Open PLC > Module Information > Diagnostic Buffer. There should be no D20C entry in the last 10 events.
3. Choose PLC > Monitor/Modify and confirm Operating Mode shows RUN. If the CPU is in STOP, the D20C may have corrupted the project load image; perform a memory reset (MRES) and re-download.
4. Open PLC > Accessible Nodes > Blocks on the online view. Verify OB2/OB3 (or their replacements) appear with the correct Author / Block version stamp.
5. Use the SZL list SZL 0x0011 (OB priority classes present in the CPU) to confirm the priority class is bound. In STEP 7 this is visible under Module Information > Diagnostic Buffer > Open block after a successful restart.

Related Error Codes and Diagnostic Buffer Entries

Operators working around D20C frequently encounter adjacent faults. The diagnostic buffer (DFSZ) entries in the same area are:

Preventive Practices

To prevent the D20C fault from reappearing on future project edits:

1. Standardise on OB numbers that the CPU firmware auto-binds (OB1, OB10-OB17, OB20-OB23, OB30-OB38, OB40-OB47, OB55-OB57, OB60, OB80-OB87, OB90, OB100-OB102). Avoid the 2-9 range unless you have a specific reason.
2. Never copy OBs from a template of a different controller family. The Insert > S7 Block > Organization Block dialog will only propose valid OB numbers for the CPU in the current station.
3. Enable PLC > Check Block Consistency after every project edit that touches OBs. STEP 7 will warn if an OB has no priority class assigned.
4. Maintain a system data (SDB) baseline. After a successful download, choose PLC > Upload Station to PG and archive the SDBs. The next download will diff against the baseline and surface D20C early.
5. Document the priority class of every user-instantiated OB in the project's Symbol Table comments to keep the priority class discoverable during commissioning.

FAQ