Sinumerik 840D PLC STOP at Startup: Resolving OB100 Event 16#4562

1. Symptom Summary

A Sinumerik 840D PL integrated PLC drops to STOP the moment OB 100 finishes its first pass. The diagnostic buffer lists two back-to-back incoming events: 16#4562 ("STOP caused by programming error") at startup OB 100, and 16#2522 ("Area length error when reading, Global DB, word access, Access address: 62") pointing at a global data block whose length cannot satisfy a 16-bit read at byte offset 62.

Loading the PLC archive (ARC) of the Sinumerik project restores operation, but the next cold or warm restart re-introduces the same pair — sometimes on the first power-up, sometimes on the second. An NCU swap and a Simodrive line-module swap have been performed without effect, which already exonerates the hardware. Treat those swaps as the diagnostic that proves the root cause is software, not hardware.

2. Affected Sinumerik 840D Hardware and Firmware

The pattern has been observed on the classic 840D PL line and on early 840D sl systems where the PLC slot still hosts an integrated SIMATIC S7-300 CPU. Refer to the Sinumerik 840D sl product page for the NCU-to-CPU mapping and to the SIMATIC S7-300 product page for the underlying PLC platform.

3. Decoding the Diagnostic Buffer — Event 16#4562 and 16#2522

The two events are causally linked. 16#2522 is the cause; 16#4562 is the consequence. Reading them in the order they appear in the buffer matters: the CPU logs the underlying access error first, then logs the STOP that the access error triggered.

The priority class 27 that the diagnostic buffer reports for the 16#4562 entry is the standard S7 priority assigned to OB 100 (startup). The "Module address: 14" is the slot of the integrated PLC inside the NCU; on a classic 840D this is the slot of the internal S7-300 CPU.

The 5 supplementary words that follow each event in the raw diagnostic buffer (e.g. FF84 8E70 1B64 0001 000E for 16#4562, FE79 0024 003E 0000 0000 for 16#2522) are an event-type-specific payload. Their layout is documented in the STEP 7 V5.x online help under "Diagnostic buffer — supplementary information" and varies by event class. The reliable way to interpret them is not to decode them by hand but to click Open Block in the diagnostic buffer dialog and let STEP 7 jump to the failing instruction.

4. Byte Offset 62 vs DB Number: The Most Common Misdiagnosis

The single most common misdiagnosis of this exact pair is to read "Access address: 62" as the DB number, conclude that DB 62 is missing, and go looking for it. The S7 diagnostic buffer does not put the DB number in the access-address field. The DB number is recovered from the absolute operand of the failing instruction — the operand the "Open Block" jump highlights.

Concretely, the "Access address: 62" string in the human-readable diagnostic buffer view is the byte offset inside the data block the failing instruction was reading. The number "62" is the offset, not the DB number. To find the real DB number, click the "Open Block" or "Open Faulty Block" button in the STEP 7 V5.x diagnostic buffer dialog. The editor will jump to the instruction that caused the fault and show the absolute operand — for example DB17.DBW62 or a fully symbolic equivalent such as "ToolData".Magazine[2].Position. The DB number is the number that precedes the dot in the absolute operand; the 62 is the byte offset within that DB.

5. Root Cause Analysis — Seven Reasons a Startup Fault Is Intermittent

The pattern "first or second time after power-up, then OK for hours" points to a small, repeating set of causes on 840D PL hardware. Ranked by frequency in the field:

1. Non-retentive data block sized to zero on first restart. The instance DB of a tool-change FB is declared with a length that the FB only resizes at first RUN. If OB 100 runs before the first normal cycle has had a chance to populate the DB, the word access at offset 62 falls off the end of the DB.
2. Re-entrancy of OB 100. Some older tool-magazine FBs re-enter themselves through a call chain that crosses OB 100 and OB 1. On the first cold start the FC called from OB 100 is still being initialised; on a warm restart it has already been initialised, and the same code path is safe.
3. Battery-low on the NCU. When the lithium cell inside the NCU module is below its warning threshold, the CPU drops a few bytes of retentive memory at the moment of the first power-down. The instance DB returns from battery as garbage, the FB reads past the end, and the next STOP writes the DB back as "empty". A second start, with the FB's startup code now able to run to completion, recovers the DB.
4. STEP 7 project vs. PLC archive (ARC) mismatch. The S7 project on the PG and the archive that gets re-loaded from HMI may carry different versions of the same FB. The "load ARC works" symptom means the ARC version of the FB is correct; the project version is not, or vice versa. Whichever is loaded second wins, and the next restart is what you measure.
5. Symbolic vs. absolute access on a renamed data block. If the FB was written with symbolic access and the symbol file was regenerated, the compiler may pack the UDT differently and the access lands at byte 62 of the new layout, which is past the end of the old runtime DB.
6. Watchdog / scan-time race in the first OB 1 cycle. A watchdog FB that truncates the DB on timeout can race against the tool-magazine FB on the first cycle. Replacing the watchdog with a one-shot flag set in OB 100 fixes it.
7. Corrupted MMC / PC card image on sl systems. For 840D sl NCUs, the PLC project lives on the CF card. A bad-block remap on the first mount can hand the S7 runtime a truncated DBW for one cycle only.

Items 1, 2, 4 and 5 are the ones that match "first time or second time, then OK for hours". Item 3 is the most common hidden cause on machines that have been in service for several years. To rule item 3 in or out, read the diagnostic buffer's battery and buffer-status entries (event class 4, event IDs 0x4301 / 0x43FF) before doing anything else.

6. Hardware and Memory Pre-Checks

Before changing a single byte of code, run a 10-minute hardware pass. The user in the source case had already replaced the NCU and the Simodrive line module, so most of this list is fast to execute.

1. NCU battery voltage. On classic 840D the battery is a 3.6 V lithium cell. Open HMI menu Commissioning > NC > Battery status; replace the cell when the HMI shows the red battery icon, regardless of what the diagnostic buffer says.
2. RAM / FEPROM / PC card consistency. From STEP 7, go PLC > Diagnostics/Settings > Module Information > Diagnostic Buffer and read the most recent 0x4301 "Buffer status" entries. Look for a 0x43FF "Battery exhausted" or 0x4303 "Retentive data lost" event. Either one points to item 3 in the list above.
3. MMC / CF card health (sl systems). Use Commissioning > NC > MMC > Check to run a sector test. A red "CRC error" or "Sectors bad" line means the project image is suspect — re-flash the CF card from a known-good backup before debugging the application code.
4. PLC operating-mode switch. Put the CPU in STOP for 30 s, then back to RUN and observe whether the 16#2522 reappears. If it does, the FB in question is unconditionally run from OB 100 and the access violation is structural, not a power-up race.
5. PROFIBUS / PROFINET slave presence. If FB 1 happens to call a PUT/GET to an I/O slave that has not yet come up at startup, the area-length error can be reported against the slave's I/O area. Open HW Config, compare the configured and actual slot lists, and bring any newly added slave online.

7. STEP 7 V5.x Recovery Procedure — Step by Step

Recovery has two layers: a fast path that gets the machine back into production, and a permanent fix that removes the cause. The fast path is "load the ARC". The permanent fix is what the next sections describe.

1. Open STEP 7 V5.x with the project that matches the machine. Confirm the CPU type and firmware version in HW Config > PLC > Properties > Diagnostic/Clock match the nameplate on the NCU.
2. Establish Online > Accessible Nodes and read the actual S7 program out of the PLC into the offline project: PLC > Upload Station to PG. Do not trust the offline project until it matches what the CPU is actually running.
3. Open PLC > Diagnostics/Settings > Module Information. The 16#4562 / 16#2522 pair will be the most recent incoming event.
4. Click Open Block (or "Open Faulty Block") on the 16#2522 entry. STEP 7 jumps to the instruction that read past the end of the DB.
5. Note the absolute operand. It will look like DBW 62 of a specific DB — record both the DB number and the offset.
6. Right-click the DB in the project tree and choose Object Properties > Length. Confirm whether the DB has at least 64 bytes (offsets 0–63). If the length is 60 or less, the read is structural and the access is wrong.
7. Choose the path from section 8 or 9 below depending on whether the DB exists.
8. Compile the S7 program, download only the changed blocks (never the whole project during a hot commissioning unless the safety integration is verified), and perform the restart sequence in section 11.

For the screenshot-by-screenshot navigation of the diagnostic buffer, refer to the Siemens Industry Online Support portal and search for "diagnostic buffer S7-300 V5.5". For the OB 100 / OB 1 / OB 100 reset rules that 840D-specific tool-magazine FBs expect, refer to the Sinumerik 840D sl PLC Programming Manual in the same portal.

8. Case A — The DB Exists but Is Too Short

If the DB is present in the project and on the CPU, the fix is to extend it.

1. Open the DB in the LAD/FBD/ST editor.
2. Open View > Data View (or press F9 if you have a numeric keypad). Confirm the byte count in the status bar.
3. Either add a new variable of at least 2 bytes starting at offset 62, or extend an existing UDT so that byte 62 falls inside a real field.
4. Save and recompile. The DB length must change in the compiled output. STEP 7 will warn "DB length changed" the first time you download — acknowledge only if the change has been reviewed.

A robust STL pattern to add a length guard in OB 100 is:

// OB 100 — restart
      L     DBW 62               // suspect word read
      T     "ToolData".FieldCheck // 1-shot flag, set in OB100, cleared in OB1 cycle 1
      L     0
      T     DBW 62               // clear the field on every cold restart
      SET
      R     "ToolData".FaultPending

This pattern does not fix the original UDT problem, but it bounds the damage: OB 100 clears the suspect area on every cold restart and lifts the flag, so the first OB 1 cycle that reads it cannot read past the end.

9. Case B — The DB Is Missing Entirely

If the "Open Block" jump points to a DB that is not in the project (e.g. DB 17 was renamed, or DB 62 was renamed in the latest compile and the PG was not refreshed), the fix is to restore the DB before the FB that opens it is downloaded.

1. Search the project for the source UDT or the data block the FB was written against. Look in the Sources folder and in the Master copies folder — they often carry the original version.
2. If the source is not on the PG, extract it from the PLC archive. From the HMI, Commissioning > PLC > Archive > Unpack writes the project into a known directory; S7ARC.EXE can be used to extract the SDB and the blocks.
3. Recompile the FB against the restored DB. Confirm the absolute operand now points inside the DB (byte 62 is reachable).
4. Download the DB first, then the FB. Order matters: if the FB is downloaded before the DB, OB 100 will execute against the old, missing DB and re-trigger the STOP.

10. Adding OB 121 to Suppress the PLC STOP

The S7 operating system only forces a STOP if the error OB is missing, disabled, or cannot be started. Adding OB 121 is not a fix for the area length error itself, but it is the single most effective measure to keep the machine running while the root cause is being diagnosed. Most production 840D installations already have OB 121 / OB 122 loaded by the machine builder for exactly this reason; a retrofit machine may not.

Create a minimal OB 121:

// OB 121 — Programming error
// Temporary local variables:
//   OB121_RESERVED_1, OB121_RESERVED_2, OB121_RESERVED_3
//   OB121_BLOCK_TYPE, OB121_BLOCK_NUMBER, OB121_BLK_ADDINFO

      L     #OB121_BLOCK_TYPE
      L     W#16#000A          // 0x0A = global DB
      ==I
      JC    DBX
      L     #OB121_BLOCK_TYPE
      L     W#16#0005          // 0x05 = instance DB
      ==I
      JC    DBX
      JU    EXIT

DBX:  L     #OB121_BLK_ADDINFO
      SRW   16                // top 16 bits of the additional info word
      T     "System".FaultedDB
      L     #OB121_BLK_ADDINFO
      T     "System".FaultedByteOffset
      SET
      S     "System".ProgramErrorFlag

EXIT: BE

The block captures the DB number and the byte offset that caused the violation, latches a system flag, and returns. With OB 121 in place, the same byte 62 read that previously stopped the PLC will now only set a flag, and the operator can be informed via the HMI without taking the spindle out of cut.

Repeat for OB 122 (I/O access error) and OB 80 (time error) on the same principle. The 840D tool-magazine FBs do not generate OB 80 / OB 121 under normal conditions, so the addition is purely defensive and cannot mask a real safety fault.

11. Verifying the Fix and Restoring the PLC Archive

After the change is compiled and downloaded, run a structured restart cycle and observe the diagnostic buffer for any 16#2522 / 16#4562 entry.

1. Cold restart (NCU power-down for at least 30 s, then power-up). Confirm the HMI shows the operator screen within 60 s, the PLC is in RUN, and the diagnostic buffer has no 16#2522 entry.
2. Warm restart (PLC STOP / RUN toggle from STEP 7 or the HMI). Same checks.
3. Hot restart (simulated by triggering the warm-restart path during a part program). Same checks. This is the case where the fault was most likely to appear in the original report.
4. Power cycle at least 5 times in a row. The intermittent symptom can be statistical; one or two passes are not enough.
5. Run a tool-change cycle. If FB 1 is part of the tool-change code path, a 20-call cycle exercises it more than an hour of normal cutting.
6. Once the fix is stable, save the corrected S7 project to the ARC on the HMI and to a versioned backup on the engineering server.

12. Related Diagnostic Event IDs and Preventive Maintenance

The 16#4562 / 16#2522 pair is one of a small family of OB-100-induced STOPs. The table below lists the siblings that an 840D PL commissioning engineer will eventually see.

Use this preventive checklist on every 840D PL that is being commissioned, retrofitted, or coming out of a long storage period:

• Replace the NCU battery before any firmware upgrade, regardless of the voltage reading.
• Confirm that OB 100, OB 1, OB 82, OB 121, OB 122 are present in the project, downloaded, and consistent across the PG and the CPU.
• Compile the S7 project with the "Length check" option enabled in the customiser.
• Document every DB length in a spreadsheet, and review it whenever a UDT is changed.
• Add a one-line comment in OB 100 with the date and author of the last change, so that the next engineer can see the version path.
• Run the 5-power-cycle test in section 11 before signing off.
• Save the project to the ARC after every approved change; verify the HMI can reload it from Commissioning > PLC > Archive > Restore.

For the broader preventive practices, refer to the Sinumerik 840D sl product documentation on the Sinumerik 840D sl product page and the SIMATIC S7-300 system manual on the SIMATIC S7-300 product page. Use the Siemens Industry Online Support portal to search for "OB 121", "OB 100", and "diagnostic buffer" against your specific NCU part number.