S5 to S7 OB180 Conversion: Replacing DB Windowing in STEP 7

Overview

OB180 is a S5-135U system function block (implemented on CPU 928A, 928B, 948, and 948R) that performs DB windowing: it shifts the start address of an opened data block so that subsequent DW (data word) accesses can reach beyond the native 0–255 ceiling. When porting S5 code that uses OB180 to S7, the windowing requirement disappears entirely. STEP 7 allows direct access to any data word via the full 16-bit address range and pointer-based indirect addressing. The conversion task is therefore not to emulate OB180 in S7 but to translate the S5 offset + DW pattern into S7 indirect addressing using area pointers, AR1/AR2, and the SLD/ITD instruction set. This article documents the OB180 mechanism, the S7 addressing model, and the verified STL patterns that produce bit-identical data access after conversion. The patterns apply unchanged to S7-300, S7-400, and S7-1500 (TIA Portal), with platform-specific notes in a dedicated section below.

Architecture Context: S5-135U CPU 928/948 and the 256-DW Ceiling

The S5-135U PLC family uses a 16-bit STEP 5 instruction set in which the operand area for data words within a DB is hard-coded to eight bits, allowing DW addresses from 0 to 255 (256 words = 512 bytes) to be addressed directly. Any DB larger than 512 bytes must be accessed through windowing: the programmer opens the DB with C DBx (or AX DXx for extended data blocks), loads a word offset into ACCU1-L, and calls OB180 to lay a 256-DW window over the DB starting at the offset value. The offset is interpreted in DWs, so an offset of 200 means the next DW 0 access reaches DW 200 of the physical DB, and DW 255 reaches DW 455.

This design reflects the CPU 928's 16-bit address arithmetic. The on-chip address register for the current DB area window holds only 8 bits of DW index, and the upper bits are passed via the accumulator to OB180, which writes them to the area pointer. The window remains active until another C DBx or AX DXx instruction is executed, at which point OB180's offset is cleared. This persistence is the source of several common conversion bugs discussed later in this article.

CPU 928B and 948 add a second register set (B stack) and a richer set of status flags, but the DW windowing contract is identical to 928A. The CPU 948R (redundant) replicates the area pointer across the backplane so that a hot standby can resume mid-scan; this has no impact on OB180 conversion. References for these architectures are available in the S5-135U system manual collection on the Siemens support portal, e.g. Siemens Support: SIMATIC S5-135U System Manual.

OB180 DB Windowing Mechanism

OB180 is invoked with a single integer offset in ACCU1-L (the low word of accumulator 1). The block takes no formal parameters; the entire side effect is the modification of the CPU's active DB-area pointer. The relevant STEP 5 sequence is:

AX DX 102      // open extended DB 102 as current area
L KF +256      // load constant +256 into ACCU1-L (window offset in DWs)
SPA OB 180     // call OB180: shift window by 256 DWs (1024 bytes)
L MW 150       // load MW 150
T DW 68        // store to DW 68 + 256 = physical DW 324

In this example, MW 150 is written to DW 324 of the active DB. The window offset of 256 DWs (= 1024 bytes) remains in effect for every subsequent L DW / T DW until the next AX DX or C DB instruction. The accumulator value is not modified by OB180; the block consumes the offset value during the call and stores the result in the internal area pointer register.

OB180 has no return value and does not modify ACCU1-H, ACCU2, ACCU3, or ACCU4. The CPU 928B and 948 keep a backup copy of the area pointer in the B-stack frame so that a subroutine call does not inherit the parent's window by default; however, a PB or FB that does not open its own DB and uses DW will inherit the offset from the caller. This is the root cause of the "stale-offset propagation" hazard covered in the next section.

Window Persistence and Sequence Hazards

Because the offset written by OB180 is retained across all DW accesses until the next DB open instruction, three failure modes appear frequently in legacy S5 code:

1. Stale-offset propagation: a programmer writes T DW 69 expecting the default (zero) offset, but the previous OB180 call's offset is still active, so the write lands at DW 69 + offset. This typically manifests in S7 conversion as a "writes to wrong location" symptom that disappears when the program is single-stepped with fresh DB opens between blocks.
2. Implicit offset across subroutine calls: code in a called FB or PB assumes a zero-offset window, but the calling block has previously called OB180. The fix in S5 was either an explicit AX DX x with L KF +0 / SPA OB 180, or inserting C DB 0 to clear the area pointer entirely.
3. BX/DX base pointer collision: S5 supports both DB (data block) and DX (extended data block) address spaces. AX DX 0 with a non-zero offset will lay a window that overlaps an existing DB if the DB and DX numbering were not kept disjoint. This is rare on the 928B but common on plants retrofitted from 928A to 948 with the original DX numbers left in place.

When porting to S7, all three failure modes vanish because S7 indirect addressing always uses an explicit pointer. The offset is encoded in the instruction stream (AR1, AR2, or the operand of L DBW [AR1, P#0.0]) and is not retained across statements. This is one of the strongest arguments for replacing OB180 with S7 indirect addressing rather than emulating it with a wrapper FB or instance DB.

S7 Addressing Model: Why OB180 Is Unnecessary

STEP 7 (S7-300/400 and S7-1500) operates on byte-granular pointers in the area-cross addressing format. A data word DBW is addressed by its byte offset (0, 2, 4, ...) and the full 16-bit range is reachable in a single instruction. The pointer format stored in AR1/AR2 is a 32-bit double word with the following layout:

Bits 31-24: Area code (e.g. 0x84 for DB, 0x86 for DI/Instance-DB)
Bits 23-16: Byte offset high (must be 0 for standard area-internal pointers)
Bits 15-3:  Byte number (0..65535), corresponds to the DBW number / 2
Bits 2-0:   Bit number (0..7), always 0 for word-granular DBW access

Two addressing modes replace OB180 in S7:

• Memory-indirect, area-internal: L DBW [AR1, P#0.0] accesses the data word at the byte offset contained in AR1 (lower 24 bits), interpreted within the currently opened DB. This is the form most commonly emitted by the SIMATIC S5 to S7 Converter for dynamic-offset replacements.
• Memory-indirect, area-cross: L DBW [AR1, P#0.0] with the full 32-bit pointer (area code + byte/bit) loaded into AR1 lets one instruction reach into any DB without opening it first. This is the most general replacement for OB180 and is preferred in conversions that target S7-300/400 or S7-1500 with multi-DB algorithms.

Because the byte offset can be calculated at runtime (it is a 16-bit unsigned integer up to 65535, addressing 128 KB of DB area), the 256-DW ceiling that forced OB180 use in S5 simply does not exist in S7. The largest supported DB on a S7-300/400 is 64 KB; on S7-1500 it is 16 MB with the standard DB type. A complete description of pointer formats and the SLD/SRD/LAR1/LAR2 instruction set is available in the STEP 7 programming reference at Siemens Support: STEP 7 (TIA Portal) Programming Reference.

DW-to-DBW Conversion Reference

The following table gives the deterministic mapping for direct (non-windowed) DW accesses. Because STEP 5 numbers DWs in 16-bit words and STEP 7 numbers DBWs in bytes, the relationship is DW_n ↔ DBW_(2n):

The conversion factor is critical: every DW number in S5 must be multiplied by 2 to produce the byte offset for S7 DBW. This factor shows up as SLD 4 in pointer-arithmetic conversions (SLD 1 to multiply by 2, then SLD 3 to convert the byte offset into a pointer-format bit position). A common conversion bug is to use SLD 3 alone, which would access DBW (DW_number) instead of DBW (2 × DW_number) — a factor-of-two error.

Static Offset Conversion: Replacing OB180 with a Constant DBW

For OB180 calls where the offset is a fixed compile-time constant, the S7 conversion is the simplest possible: replace the offset + DW pair with a single direct DBW access. The byte offset is 2 × (offset_DW + accessed_DW).

Example S5 sequence:

AX DX 102
L KF +256
SPA OB 180
L MW 150
T DW 68

Byte offset reached = (256 + 68) × 2 = 648. S7 conversion:

AUF DB 102
L MW 150
T DBW 648

No OB180, no LAR1, no pointer arithmetic. This pattern is generated automatically by the SIMATIC S5 to S7 converter for static-offset cases and is the preferred form when the offset is known at conversion time. Refer to the converter documentation at Siemens Support: S5 to S7 Converter Tool for the full algorithm and the limitations of the auto-conversion pass.

Dynamic Offset Conversion: LAR1 with SLD 4

The more interesting case is dynamic offsets, where the window shift is computed at runtime and stored in a flag word. The S5 source typically looks like this (taken from the original problem statement):

C DB5
L DW 8
L FW 250
-F
T FW250
C DB132
JU OB180
L DW 0

The code computes an offset (the difference between DB5.DW8 and FW250), stores it back into FW250, and then opens DB132 with the offset window. The next L DW 0 reads the value at DW 0 of the windowed DB, which is DW (offset) of the physical DB. In S7 the same logic becomes:

L DB5.DBW 16       // DW 8 in S5 = DBW 16 in S7
L MW 250
-I
T MW 250            // offset now stored in MW 250 as INT
ITD                 // promote to DINT (32-bit) for pointer math
T MD 250            // reserve MD 250 (MW 250 + MW 252) for the offset
SLD 4               // multiply by 16 = (DW * 2) * 8; produces pointer-form bit offset
LAR1                // load address register 1
OPN DB 132
L DBW [AR1, P#0.0] // read the data word at the dynamic offset

Why SLD 4: the S5 DW number must be converted to a byte offset (factor 2, i.e. SLD 1) and then re-encoded as a pointer (factor 8, i.e. SLD 3), giving a total shift of 4 bits. A common error in the field is to use SLD 3 alone; this would access DBW 200 (bytes 200-201) when 400 (bytes 400-401) was intended. This is the source of "off by 200 DWs" symptoms after porting and accounts for a large fraction of OB180 conversion bugs in field-reported cases.

Equivalent SCL formulation (S7-300/400/1500):

#OffsetDW := WORD_TO_DINT("DB_Source".DW8) - WORD_TO_DINT(#FW250);
#FW250 := INT_TO_WORD(DINT_TO_INT(#OffsetDW));
#ByteOffset := #OffsetDW * 2;  // 16-bit byte offset, range 0..65534
"DB_132".ActualValue := WORD_TO_INT("DB_132".DBW[#ByteOffset]);

The SCL form is more readable but compiles to the same LAR1 + SLD 4 + L DBW [AR1, P#0.0] sequence on S7-300/400; on S7-1500 the compiler may emit an area-cross pointer load and a single L DBB/W instruction.

Block-Move (BMW) Conversion

The S5 block-move instruction BMW src dst n copies n words from a source DB to a destination DB. The operands can themselves be dynamic (opened with AX DX before the call). The STEP 5 sequence from the original problem is:

BMW 238
AX DX 0
BMW 252
L DW 0
BMW 240
AX DX 0
BMW 248
T DW 0

Parsing the multi-line BMW syntax: this is a single BMW call with source = DB[MW238], destination = DB[MW240], and count = MW252. The "AX DX 0" / "L DW 0" / "T DW 0" tokens are address-mode modifiers that select the active DB. The S7 conversion using pointer registers and the BLKMOV SFC (SFC 20) is:

AUF DB [MW 238]      // source DB
L MW 252             // word count (16-bit)
ITD                  // promote to DINT
SLD 1                // multiply by 2 -> byte count (BLKMOV counts in bytes)
T MD 260             // store byte count for ANY pointer construction
// Build source ANY pointer at offset 0 in the currently opened DB
LAR1                 // P#0.0 for the start of the source DB
// Build destination ANY pointer
AUF DB [MW 240]
LAR2                 // P#0.0 for the start of the destination DB
// Call SFC 20 BLKMOV with full ANY pointers
CALL SFC 20
  srcblk := P#DBX 0.0 BYTE 32768   // source area (whole source DB, 32 KB max)
  ret_val := MW 300
  dstblk := P#DBX 0.0 BYTE 32768   // destination area

For static source/destination offsets (the common case), the SIMATIC S5 to S7 converter emits direct AUF DB [MW ...] statements with byte-aligned offsets and SFC 20 calls. The 32-bit ANY pointer format used by SFC 20 requires byte counts that are multiples of 2; if the S5 source uses an odd DW count, a corrective SLD 1 is required before the count is encoded into the ANY pointer. The detailed ANY pointer layout is documented in the STEP 7 system and standard functions reference, accessible from the Siemens support portal entry for S7-300/400 at Siemens Support: S7-300 System Manual.

Step-by-Step Conversion Procedure

1. Inventory OB180 calls. Use the cross-reference facility (in STEP 5 this is the "Cross Reference" printout, in STEP 7 / TIA Portal the "Cross-references" view) to list every SPA OB 180 / JU OB 180 occurrence and the AX DX / C DB that precedes it. Note the offset value in ACCU1-L at each call site.
2. Classify each call as static or dynamic. If the offset is loaded via L KF (constant), it is static. If it is computed from MW, DW, or accumulator math (L FW / L DW / -F / +F / -G / +G), it is dynamic.
3. For static calls: compute the effective DW address = offset + accessed DW, then convert to byte offset = 2 × effective DW. Emit a direct L/T DBW instruction at the computed offset. Verify the byte offset is even and within the target DB size.
4. For dynamic calls: ensure the offset word is reserved (e.g. MW 250 → MD 250) and not shared with unrelated 16-bit flags. Emit the ITD / SLD 4 / LAR1 sequence and replace L DW 0 / T DW 0 with L DBW [AR1, P#0.0] / T DBW [AR1, P#0.0].
5. Verify window persistence. For every converted block, scan the S5 source for the next C DB / AX DX after each OB180 call. If the next data word access in the S5 source relies on the offset being cleared, no action is required in S7; if it relied on the offset being retained, the S7 code must explicitly reload the pointer.
6. Check DX vs DB. The S5 AX DX instruction opens an extended data block, which the SIMATIC S5 to S7 converter typically renumbers to a high DB number (e.g. DX 102 → DB 358). Confirm the converter's mapping table before testing; do not assume the original DX number survives.
7. Run the converter in dry-run mode. Both the legacy "S5 to S7 Converter" (for S7-300/400) and the "S5 to S7 Migration Tool" (for S7-1500) emit a change log; review each warning related to OB180 and pointer arithmetic.
8. Compile and cross-check with a test DB. Populate a test DB with a known pattern (e.g. DW 0 = 16#1111, DW 200 = 16#2222, DW 455 = 16#3333), execute the converted STL, and verify the read/write addresses against the S5 simulation.
9. Run PLCscan / cross-reference in TIA Portal. After loading the converted project, generate a fresh cross-reference and confirm that every L DBW [AR1, P#0.0] / T DBW [AR1, P#0.0] resolves to a valid byte offset in the target DB; unresolved references usually indicate a missing LAR1 or a wrong area-cross pointer.

Verification and Commissioning Tests

After conversion, run the following diagnostic checks before the converted program is released to production:

• Address-trace test: in STEP 7, use the "Monitor/Modify" tool with a trigger on the L DBW / T DBW instruction. The byte offset displayed must equal 2 × (S5 offset + S5 DW number). For dynamic cases, the offset value in MD 250 (or wherever the dynamic offset lives) must be correct at the time of the indirect access; place a watchpoint on the SLD 4 instruction and verify the result is the expected byte pointer.
• Window-persistence test: for each OB180 site, verify that the next DB open in the S5 source produces the same DB open in the S7 source. If the S5 source has a path that does not open a new DB after OB180 but the S7 source inserts an implicit OPN, the behavior is unchanged; if the S5 source relies on the window being cleared by a C DB 0 in a path that was eliminated by the converter, add an explicit OPN DB 0 to clear any S7 pointer state.
• Edge cases: test with offset = 0, offset = 255, offset = 256, and offset = 32767. The byte offset must remain within the 16-bit range and the pointer must not overflow into the bit field. The maximum legal S7 pointer byte offset is 65535, corresponding to DW 32767 in S5 — the full upper bound of the 16-bit signed offset space.
• DB size boundary: verify the target DB has been resized to accommodate the largest accessed DW. A 1024-DW DB in S5 (16 KB) corresponds to a 16 KB DB in S7; the converter does not auto-resize DBs, so this must be done manually in the S7 DB editor. On S7-1500, DBs up to 16 MB are supported without reconfiguration; on S7-300/400, DBs are limited to 64 KB and must be split if the S5 source required more.
• Cycle-time check: the SLD 4 + LAR1 + L DBW [AR1, P#0.0] sequence is longer than the equivalent S5 OB180 path (which the CPU 928 executes in microcode). On tight OB1 cycles, an S7-300 with several hundred indirect accesses per cycle can add 1-3 ms of overhead versus the S5 baseline. If cycle time is critical, consider caching the offset in a static variable and using area-cross pointers to eliminate the OPN DB instruction.

Common Conversion Errors and Their Fixes

Worked Example: Full OB180 Replacement in STL

Below is a complete before/after pair for a typical OB180 site. The S5 source is the canonical recipe-pattern example from the original problem statement; the S7 target is a S7-315-2 PN/DP with two DBs and a flag word offset.

S5 source (CPU 928B):

      C   DB 5
      L   DW 8
      L   FW 250
      -F
      T   FW 250
      C   DB 132
      JU  OB 180         // window offset = FW 250 (in DWs)
      L   DW 0           // read DW (FW 250) of DB 132
      L   FD 200
      :G                 // compare: FD 200 < (DW 0)?  CC1 set if yes
      JC  LOW            // branch to "LOW" label if condition met
      // ... process normal range ...
LOW:  // ... process low range ...

S7 target (S7-300, STL):

NETWORK 1   // Compute dynamic window offset
      L    DB5.DBW 16      // DW 8 in S5 = DBW 16 in S7
      L    MW 250
      -I
      T    MW 250          // offset in DWs (16-bit INT)
      ITD                  // promote to DINT
      T    MD 250          // reserve MD 250 (32-bit) for offset

NETWORK 2   // Open DB 132 and load pointer
      OPN  DB 132
      L    MD 250          // DINT offset in DWs
      SLD  4               // DW * 2 (byte) * 8 (bit) = SLD 4
      LAR1                 // load pointer into AR1

NETWORK 3   // Read DW (offset) and compare to FD 200
      L    DBW [AR1, P#0.0]   // read at byte offset = 2 * DW_number
      L    MD 200              // flag double word (32-bit)
      

The SCL equivalent on S7-1500 is more compact and is the preferred form for new development:

IF "DB_Source".DW8 - "FW250" < "FD200" THEN
    // ... process low range ...
ELSE
    // ... process normal range ...
END_IF;

Notes on Migration Targets (S7-300, S7-400, S7-1500)

The patterns above apply unchanged across S7-300, S7-400, and S7-1500, with the following platform-specific notes:

• S7-300 (CPU 313/314/315/316/317/319): standard AR1/AR2 indirect addressing; the LAR1 + SLD 4 pattern is supported in STL. SCL code is transpiled to equivalent STL by the compiler. On CPU 319F (fail-safe), the indirect pointer must be marked as a "safe" variable; consult the F-library documentation for the safety lifecycle.
• S7-400 (CPU 412/414/416/417): identical STL instruction set; some 400-series CPUs allow two parallel area-cross accesses (using AR1 and AR2 simultaneously), which is useful for high-performance SFC 20 calls. The CPU 417-4 also supports 64-bit accumulators, allowing a 32-bit pointer plus a 32-bit data payload to be processed in a single STL network.
• S7-1500 (CPU 1511-1518): STL is fully supported, but TIA Portal also offers the SCL high-level language where the conversion can be expressed as "DataBlock_132".ActualValue := ... with a DINT variable for the offset. The S5 to S7 Migration Tool generates both STL and SCL output; the SCL output is typically more readable and is preferred for new development.
• S7-1500 Software Controller (CPU 1507S / ET 200SP Open Controller): same instruction set as S7-1500; supports a 64-bit pointer extension for addressing beyond the standard 16-bit byte offset. For OB180 conversions where the S5 offset exceeded 32 767 DWs, use the 64-bit LAR1 form on S7-1500 with the optional area-cross pointer format.

For S7-1500, the area-cross pointer format was extended in TIA Portal V17 to support 64-bit byte offsets; LAR1 still loads a 32-bit value, but the upper 32 bits are derived from the area identifier encoded in the instruction. The byte-offset semantics are unchanged, so the SLD 4 conversion remains valid for all offsets up to 2 147 483 647 bytes (1.5 × S5 address space). The migration of older S7-300/400 projects to S7-1500 is described in Siemens Support: S7-300/400 to S7-1500 Migration.

Related STEP 5 / STEP 7 Conversion Topics

OB180 is one of several S5 system functions that disappear in S7. The table below summarizes the most common ones encountered during S5-135U / S5-155U to S7-300/400/1500 conversions:

Refer to the STEP 5 to STEP 7 migration overview at Siemens Support: S7-300/400 to S7-1500 Migration and the STEP 7 (TIA Portal) programming reference at Siemens Support: STEP 7 Programming Reference for the complete mapping list and the supported firmware versions of the converter tools.

FAQ