Copying Data Blocks in S5 PLCs Using OB182 System Function

Overview

Copying a contiguous range of data words from one Siemens S5 data block (DB) to another is a recurring requirement in STEP 5 programming: mirroring process images, replicating recipes, shifting parameter sets, or staging work data before a sequence change. The recommended solution is the system function OB 182 – Copying Data Area, which copies a defined span of data words from a source DB/DX to a destination DB/DX in a single call. This article covers the parameter block layout, CPU compatibility, sample call, status/evaluation, and the manual-loop fallback for older CPU firmware that does not export OB 182.

Prerequisites

• Siemens SIMATIC S5 programmable controller with a CPU that supports OB 182 (CPU 945-7UA1/-7UA2 in the S5-115U family, CPU 928B in the S5-135U/155U family). For other CPU types, verify in the corresponding CPU manual.
• STEP 5 programming environment (PG with COM 115/155 or PG 7xx/PG720) and online connection to the CPU.
• Both source and destination data blocks (DB 10 and DB 11 in the example) must already exist in the CPU's DB RAM with a sufficient length to hold the source range and destination range respectively.
• Documentation: Siemens Industry Online Support – search for the S5-115U / CPU 945 manual, document EWA 4NEB 811 6150-02d, for the canonical OB 182 description.

OB 182 – Copying Data Area: Function Contract

OB 182 copies a contiguous span of data words from a source block to a destination block. Both blocks must already be open (or be opened by the OB through its internal mechanism); the call leaves the source block unchanged and overwrites the destination range.

Parameter Block Layout

OB 182 reads a parameter list from a freely addressable area of the user program. In practice the list is placed in a flag word (FW) range, a data word range, or a system data area, and its start address is loaded into the accumulator before the call. The exact byte layout for the standard CPU 945 / CPU 928B implementation is:

Step-by-Step: Copying DW 89–101 of DB 10 to DW 35–47 of DB 11

The example from the source thread: copy 13 data words (DW 89 … DW 101 inclusive = 13 DW) from DB 10 to DW 35 … DW 47 of DB 11.

1. Create or open the parameter block. Reserve 13 bytes of free memory for the parameter list. A typical location is in the flag area (FW) or in a work DB. Below, the list is placed starting at FW 200.
2. Pre-load the parameter bytes with constant values. Using STEP 5 STL, transfer the byte / word literals in the order source type, source DB, source start, destination type, destination DB, destination start, length. Leave the result byte untouched.
3. Call OB 182 with the address of the parameter block in accumulator 1. The exact call sequence is CPU-specific; for the CPU 945 / 928B family the standard pattern is to load the start address of the parameter list (e.g. FY 200 or the absolute byte address) and then issue SP OB 182.
4. Evaluate the result byte after the call to confirm that the copy completed without error.

Sample STEP 5 STL sequence (illustrative – verify mnemonic conventions against your PG version):

      :      L   KB 1                 \   source block type = DB
      T   FY 200
      L   KF +10                /   source DB = 10
      T   FW 201
      L   KF +89                /   source start = DW 89
      T   FW 203
      L   KB 2                 \   destination block type = DB
      T   FY 205
      L   KF +11                /   destination DB = 11
      T   FW 206
      L   KF +35                /   destination start = DW 35
      T   FW 208
      L   KF +13                /   number of DW = 13
      T   FW 210
      L   FY 200                /   pointer to parameter block in ACCU1
      SP  OB 182                /   call system function
      L   FY 212                /   read result byte
      <evaluate, e.g. SPB ERR>

Result / Status Byte Semantics

OB 182 writes its execution status into the result byte (offset +12 in the parameter block). Typical return values on the CPU 945 / 928B:

Treat this table as a working hypothesis – consult the manual for the canonical error list. The non-zero pattern itself (any value ≠ 00H) is a reliable signal that OB 182 rejected the request and that no data was modified.

CPU Compatibility Matrix

Manual Loop Fallback (for CPUs Without OB 182)

On S5-90U / 95U / 100U / 115U (CPU 941–944) the OB 182 is not present. The portable solution is a counted loop that opens both DBs, transfers one DW per iteration, then closes the blocks. This is also the right pattern when the data set is large and you want to break it up across multiple OB 1 cycles (avoiding scan-time blow-out).

      :      C   DB  10                /   open source DB
      C   DB  11                /   open destination DB
      L   KF +13                /   loop counter = 13 DW
NEXT: T   FW 250                /   save remaining count
      L   DW  89                /   ACCU1 = source DW (offset 89)
                              /   next iteration must advance DW pointer
      T   DW  35                /   store into destination
      ...                      /   increment offsets and decrement count
      L   FW 250
      LO  =N-1
      JC  =NEXT
      BE

The pointer to the active DW is implicit in the most recent A DB / T DW / L DW access. To advance to the next DW on each iteration, insert L DW +0 / T DW +0 in sequence with DO DW 0 to bump the data-block pointer, or use the address-register indirect scheme documented for your CPU (CPU 945 / 928B support DO DW / DO FW with address registers; smaller CPUs do not).

Wrapping OB 182 in a Reusable FB

If multiple call sites need to copy DB ranges with varying parameters, encapsulate the parameter list and the OB 182 call in a single FB. The FB exposes formal parameters for source DB, source start, destination DB, destination start, and word count. Internally it copies the formal parameters into a local parameter block in the FB's instance DW area and then calls OB 182.

• Name the FB, e.g. FB 200 – COPY_DB_AREA.
• Define formal parameters: S_DB (source DB), S_DW (source start), D_DB (destination DB), D_DW (destination start), N (word count), RET_VAL (result byte).
• Reserve an instance-DW range long enough for the 13-byte parameter list; align to a word boundary (e.g. start at DW 0 of the instance).
• Hand each call a dedicated DB instance (DB 200, DB 201, …) so that nested / concurrent calls do not share the parameter block.
• Test with deliberate boundary values (N=0, S_DB=0, D_DW past end of dest) and verify the result byte to make sure the FB surfaces errors instead of swallowing them.

Edge Cases and Field-Proven Caveats

• Open DBs and the implicit pointer. The S5 CPU maintains a "current" data block per DB number slot. After an OB 182 call, the implicit pointer state is implementation-defined; do not assume the source DB is still "open" in the sense that the next L DW accesses its data. Re-issue A DB if you continue to use the data.
• DB length must include start + N. If DB 10 is 100 DW long and you start at DW 89 with N = 13, the last source address is DW 101 – within the 100-DW range, copy proceeds only if the DB is at least 102 DW long. The CPU returns a length error otherwise; the result byte carries the error code but the destination is left untouched.
• DX vs DB. The block type byte selects between standard data blocks (DB, code 01H) and extended data blocks (DX, code 02H). On CPUs that support DX, you can copy from a DB to a DX or vice-versa – only the type codes matter, the word size is identical.
• Number of words = 0. A zero length is rejected. To "copy nothing," skip the call entirely; do not pass N = 0 just to leave the result byte at 0.
• Overlapping source and destination. OB 182 is not specified to handle overlapping ranges portably. If the source and destination ranges overlap, copy through an intermediate DB or use two calls to avoid aliasing artifacts.
• Watchdog and scan time. A 13-DW copy is negligible. A 4 000-DW copy in a single OB 1 cycle can still take milliseconds – on tight watchdogs (e.g. CPU 941 in default 100 ms) split the copy into chunks triggered by a timer/counter.
• Retentive vs volatile. Data block contents are stored in the same RAM that survives a power cycle only if the DB is loaded into the retentive area (CPU-dependent). If the destination DB must survive a power-down, verify the CPU's retentive DB capacity and select the destination DB number from that range.
• PG online update. When you change a DB length with the PG, the new length is committed on next cold restart or after an explicit "Transfer" / "Block download" depending on PG mode. OB 182 will report a length error against the old image until the new one is active.

Verification Procedure

1. Static DB check. From the PG, open DB 10 and DB 11 and confirm both lengths cover start + N. Write distinct test patterns into DB 10 DW 89 … 101 (e.g. 89H, 8AH, 8BH … 95H) so that the destination can be visually verified.
2. Single-cycle test. Force the program to call OB 182 once (set a flag, OB 1 only executes the call when the flag is set) and observe the destination range in PG Status Block or Monitor / Modify. The destination should mirror the source pattern exactly.
3. Error test. Temporarily set N = 0 or set the destination start past the end of DB 11. The result byte should become non-zero, and the destination must remain unchanged. Restore correct values.
4. Edge test. Copy the maximum supported N for the source and destination (the lesser of the two block lengths minus the start). If the CPU accepts it without error, the parameter list and call sequence are correct.
5. Long-run test. Run the program in automatic mode for several hours with the copy triggered on each scan or on a timer. Watch the CPU's diagnostic buffer for any OB 182-related events and monitor the destination range in the PG to ensure stability.

Troubleshooting Matrix

FAQ