S7-1500 DPRD_DAT Error 8090 (-32624): Replacing the Legacy I/O Address with the TIA Portal HW-ID
The DPRD_DAT instruction is the modern, unified name used across the S7-300, S7-400, S7-1200, and S7-1500 CPU families to read consistent data from a DP standard slave / PROFINET IO device. In legacy STEP 7 (S7-300/400) the same block was exposed as System Function 14 (SFC14) in the standard library. Code that runs unchanged on a S7-300 CPU will fail on a S7-1500 CPU with the runtime error -32624 (hexadecimal 0x8090) when the project is migrated or re-implemented in TIA Portal, even though the hardware configuration, the slot assignments, and the data-block structure are byte-for-byte identical. This article documents the root cause, the parameter mapping change, and the verified field procedure for eliminating the fault.
1. Problem Description
1.1 Symptom
After migrating an S7-300 station to an S7-1500 CPU, or when porting a working S7-300 program to a fresh S7-1500 project, the call
// S7-300 / S7-400 (STEP 7 V5.x or TIA Portal V13+ running on a 300/400 CPU)
CALL SFC14
LADDR := W#16#0100 // logical base address of the input slot
RET_VAL:= MW20 // status word
RECORD := P#DB10.DBX0.0 BYTE 16
compiles cleanly and downloads to the S7-1500 CPU without compile or download errors. At runtime, the call returns
RET_VAL = -32624 (decimal)
RET_VAL = W#16#8090 (hex)
STATUS = 0x8090
The target data block is not written; the input image of the ID reader / DP slave / PROFINET device remains at the last valid value or zero. The CPU does not transition to STOP, and the diagnostic buffer does not contain a hardware fault entry — the failure is reported only through the RET_VAL of the block.
1.2 Typical Application Context
The most common scenarios observed in field service:
- Migration of an S7-315/S7-317 station that reads a 16-, 32-, or 64-byte consistent record from an ID reader, barcode scanner, weighing module, or third-party DP slave.
- Replacing an S7-300 master with an S7-1511 / S7-1515 / S7-1516 / S7-1518 CPU while keeping the existing PROFIBUS DP or PROFINET IO topology.
- Duplicating a working S7-1200 program (which already used DPRD_DAT) to an S7-1500 CPU, where the slot was assigned a different I/O start address than the one used in the original
LADDR.
2. Error Code Decoding
2.1 Converting -32624 to Hexadecimal
Siemens runtime error codes are 16-bit signed integers. Decimal -32624 corresponds to the unsigned hexadecimal value 0x8090:
-32624 (signed decimal, 16-bit two's complement)
= 0x10000 - 32624
= 0x10000 - 0x7F70
= 0x8090
Always check the hexadecimal value when working with the Siemens online help, because the Siemens documentation index and the entry in PLC > Online & Diagnostics > Diagnostic buffer both display the hex form.
2.2 Meaning of 0x8090 for DPRD_DAT
For the DPRD_DAT / DPWR_DAT family, the error 0x8090 is defined as:
| RET_VAL (hex) | RET_VAL (dec) | Meaning |
|---|---|---|
| 0x8090 | -32624 | Specified logical base address invalid: the LADDR input does not match the HW-ID of any submodule/input/output slot configured in the device configuration. |
| 0x8091 | -32623 | No module present at the specified address / HW-ID. |
| 0x8092 | -32622 | DP slave / IO device reports a type error at the specified slot. |
| 0x8093 | -32621 | Access to a slot that is not assigned (empty slot in the configuration). |
| 0x80A0 | -32608 | Negative acknowledgment when reading from the I/O — slave/device diagnostic interrupt pending. |
| 0x80A1 | -32607 | Negative acknowledgment when writing to the I/O. |
| 0x80B0 | -32600 | DP slave / IO device not in the expected state (e.g. not in RUN, configuration mismatch). |
| 0x80B1 | -32599 | Specifed length is inconsistent with the slot length or with RECORD size. |
| 0x80C0 | -32576 | Data read has not yet been received from the I/O module. |
| 0x80C1 | -32575 | Same as 0x80C0 for DPWR_DAT. |
| 0x8xyy | — | General I/O access error from the I/O manager; x = 5 (read) or 6 (write), yy = specific cause. |
The single most frequent cause of 0x8090 in ported code is the address-model change described in the next section.
3. Root Cause: I/O Address vs. HW-ID
3.1 Classic STEP 7 (S7-300 / S7-400) Model
In STEP 7 V5.x and in the early S7-300 firmware, the input to SFC14 / SFC15 is the logical base address of the input or output slot as it appears in the I/O address table. A 16-byte input slot starting at byte 100 is referenced as W#16#100 (decimal 256). The address is defined by the slot position in the rack and by the address offsets in HW Config.
3.2 TIA Portal / S7-1500 Model
In TIA Portal, each configured submodule, slot, or channel is assigned a system-wide Hardware Identifier (HW-ID). The HW-ID is a DWORD that is unique within the S7-1500 station. The I/O start address is still displayed in the device view, but the DPRD_DAT / DPWR_DAT / DPNRM_DG / DPSYNC_FR family of instructions on the S7-1200 and S7-1500 expects the HW-ID, not the I/O address.
The HW-ID is independent of the slot order in the rack and is assigned automatically by TIA Portal when the device is added to the project. A re-compile, a re-plug of a module, or a port to a different CPU may renumber the HW-IDs. The I/O addresses, in contrast, are bound to the physical slot and to the address offsets assigned in the device configuration.
4. Architecture Comparison: SFC14 on S7-300 vs. DPRD_DAT on S7-1500
| Property | S7-300 / S7-400 (STEP 7 V5.x, TIA V13+ on 300/400) | S7-1200 / S7-1500 (TIA Portal V12+) |
|---|---|---|
| Instruction name in the program editor | SFC14 / SFC15 (system function block), also accessible as "DPRD_DAT"/"DPWR_DAT" in TIA | DPRD_DAT / DPWR_DAT (IEC standard extended instructions) |
| LADDR parameter semantic | Logical base I/O address (W#16#xxx) | HW-ID of the input/output slot (DWORD) |
| RECORD parameter | ANY pointer; consistency maintained for full length | VARIANT pointer; length must match the slot's consistent range |
| Maximum consistent length | Up to 64 bytes (CPU-dependent; older S7-300 CPUs cap at 16 or 32 bytes) | Up to 1024 bytes per slot on PROFINET IO; DP on S7-1500 typically up to 64 bytes (CM/CP dependent) |
| Error reporting | RET_VAL is an INT (negative on error) | RET_VAL is an INT (negative on error) — same encoding |
| Block availability | CPU firmware (SFC area) | Project library (TIA Portal instruction list, "Extended Instructions > Distributed I/O") |
Source: Siemens TIA Portal Help — "DPRD_DAT — Read consistent data of a DP standard slave (S7-300/S7-400)".
5. Locating the Correct HW-ID in TIA Portal
The HW-ID is shown in two places. Always read the value from the live project, never from a printed archive, because re-compile operations may change the number.
5.1 Method 1: System Constants
- Open the PLC project in TIA Portal.
- Navigate to PLC > System constants (or, in newer TIA releases, PLC variables > System constants).
- Locate the entry that corresponds to the input or output slot of the DP slave / PROFINET device. The default name pattern is <DeviceName>~<SlotName>~<IO>, e.g.
ID_Reader~Head_1~Input,ID_Reader~Slot_1~Input, orPROFINET IO > [Device] > Slot 1 Input. - The numeric value in the Value column is the HW-ID (DWORD, decimal representation). For the ID reader discussed in the originating service ticket, the value was 276.
DPRD_DAT reads the I/O slot, not the head. If the head HW-ID is supplied, the call returns 0x8090 because no consistent data range exists on the head module.5.2 Method 2: Device View, Properties, I/O Addresses
- Open the device view of the DP slave / IO device.
- Click the input or output slot of interest.
- In the properties window, switch to the I/O addresses tab.
- The HW-ID is displayed in addition to the start address. Copy the value (decimal or hex, depending on the TIA version) into the
LADDRtag of theDPRD_DATcall.
5.3 Method 3: Cross-reference from the Project Tree
Right-click the slot, choose Cross-references, and inspect all uses of the HW-ID. Any block parameter that accepts a HW-ID will show the same identifier; this is the fastest way to confirm that the value used by DPRD_DAT matches the slot that the code intends to read.
6. Step-by-Step Solution
6.1 Prerequisites
- TIA Portal V13 SP1 or later. (V15.1 / V16 / V17 / V18 are recommended for S7-1500 firmware V2.6 and newer.)
- S7-1500 CPU with firmware ≥ V1.8 (any current S7-151x, S7-152x, ET 200SP CPU, or S7-150V/software controller is supported).
- For PROFIBUS DP: CM 1542-5 or CP 1542-5 (6GK7542-5FX00-0XE0 or 6GK7543-5FX00-0XE0) plugged and configured. For PROFINET IO: a PROFINET interface on the S7-1500 CPU or a CM/CP.
- The GSD file of the ID reader / DP slave installed in TIA Portal.
6.2 Procedure
-
Verify the device configuration. In the device view, confirm that the DP slave / PROFINET device is present, has no diagnostic errors, and that the input slot (or output slot, for
DPWR_DAT) is enabled and not greyed out. -
Read the HW-ID. Use Method 1 (System constants) or Method 2 (device view) above. Record the value as a DWORD tag, e.g.
"DB_Hardware".HW_ID_Inputof type DWORD. -
Replace the LADDR constant. In the
DPRD_DATcall, change theLADDRinput from the legacy hex address (e.g.W#16#100) to the HW-ID (e.g.DW#16#114for decimal 276). - Recompile and download. Use Compile > Software (rebuild all blocks), then download to the CPU. A full download is not required; an incremental download of the affected block is sufficient.
-
Monitor RET_VAL online. Place the CPU online, open the instance / calling block, and watch the
RET_VALoutput. A value of0indicates success;16#8090indicates the HW-ID is still wrong;16#8091indicates the module is missing or has failed.
6.3 Before / After Code Sample (Structured Text)
// BEFORE — S7-300 SFC14 style; fails on S7-1500 with RET_VAL = 16#8090
"ID_Reader_DB".HW_ID := 16#0100; // WRONG: this is the I/O base address
"DPRD_DAT_DB"(REQ := TRUE,
LADDR := "ID_Reader_DB".HW_ID, // 16#0100 -> 0x8090 on S7-1500
RET_VAL := "ID_Reader_DB".Status,
RECORD := "ID_Reader_DB".Payload);
// AFTER — TIA Portal / S7-1500 style; uses HW-ID from System constants
"ID_Reader_DB".HW_ID := 276; // CORRECT: HW-ID of input slot
// or, for clarity, use the symbolic system constant:
"ID_Reader_DB".HW_ID := "ID_Reader_1"."Input slot_1"; // TIA V16+ supports symbolic HW-IDs
"DPRD_DAT_DB"(REQ := TRUE,
LADDR := "ID_Reader_DB".HW_ID,
RET_VAL := "ID_Reader_DB".Status,
RECORD := "ID_Reader_DB".Payload);
6.4 Before / After Code Sample (LAD / FBD)
In the LAD/FBD editor, drag DPRD_DAT from Instructions > Extended Instructions > Distributed I/O, then click the LADDR input and select the HW-ID tag from the drop-down. TIA Portal will list the available HW-IDs in the project.
7. Migrating SFC14 / SFC15 from an S7-300 Project
7.1 Using the LOG2MOD Approach
For large migrations where dozens of SFC14/SFC15 calls exist, manually editing each LADDR is impractical. Siemens and several integrators use a helper block to convert the legacy I/O address to the corresponding HW-ID at runtime. The pattern is:
- Create a function block
LOG2MOD(or use one from the migration library) that takes the oldLADDR(W#16#xxx) and returns the HW-ID of the slot whose I/O start address matches. - Call
LOG2MODonce in OB100 (warm restart) or OB1 on first scan, store the HW-ID in a global DB. - Use the resulting HW-ID in the
DPRD_DAT/DPWR_DATcall.
LOG2MOD approach is acceptable as a transition step but should be replaced with the direct HW-ID before project sign-off. Indirect resolution hides the configuration; if the device is re-plugged into a different slot, the I/O address and the HW-ID both change, and the conversion logic must be re-validated.7.2 Using the Migration Tool
When the entire S7-300 project is migrated via Project > Migrate to TIA Portal, the migration wizard inserts the legacy I/O address into LADDR in the new S7-1500 program. The block compiles, but it returns 0x8090 at runtime. Always run the offline/online compare after migration and search for any remaining SFC14 / SFC15 calls; replace the LADDR constant with the HW-ID from the system constants of the migrated project.
8. Consistent Data Limits
Per the Siemens TIA Portal V21 documentation for the DPRD_DAT extended instruction for S7-300/S7-400 CPUs:
- CPUs of the S7-300 / S7-400 product range support up to 64 bytes of consistent data in a single
DPRD_DAT/DPWR_DATcall. The exact maximum depends on the CPU firmware and on the DP master module. - For data longer than 4 bytes, you must use
DPRD_DAT; the standard process image (PEW / PED) cannot guarantee consistency beyond 4 bytes and may return partially updated data. - On S7-1500 with PROFINET IO, the consistent range can extend to up to 1024 bytes per slot, but only if the IO device declares that length in its GSDML file and the IO controller supports it.
If RECORD is shorter than the consistent range of the slot, the call succeeds but only the first RECORD bytes are transferred. If RECORD is longer than the consistent range, RET_VAL = 0x80B1 is returned.
9. Verification
9.1 Online Check
- Go online with the CPU.
- Open the calling block (OB1 or the cyclic interrupt OB that contains
DPRD_DAT). - Monitor the
RET_VALtag and theREQ/DONE/ERROR/STATUSoutputs of the instance DB. - Successful call:
RET_VAL = 0and the data area atRECORDshows the expected payload from the ID reader.
9.2 Diagnostic Buffer Check
- Open Online & Diagnostics > Diagnostic buffer.
- Filter for entries from the time of the fault. A
DPRD_DATwith an invalid HW-ID does not generate a diagnostic buffer entry, but the absence of "I/O access error" entries is a useful negative confirmation that the fault is purely the parameter-mapping issue described in this article.
9.3 Trace (S7-1500 Only)
For intermittent faults, configure a trace on the RET_VAL tag and the first four bytes of the RECORD. A successful call shows a single rising edge on DONE with RET_VAL = 0; a 0x8090 fault shows a constant 0x8090 on every cycle. This is also the easiest way to confirm that a third-party DP slave is not intermittently dropping off the bus (which would also return 0x8090 / 0x8091 / 0x80B0).
10. Related Errors and Edge Cases
| Symptom | Likely cause | Action |
|---|---|---|
| 0x8090 immediately on first scan after download | HW-ID not yet resolved because the device view has not been compiled to the CPU | Recompile hardware (right-click PLC > Compile > Hardware (rebuild all)) and download hardware configuration again. |
| 0x8090 after device replacement or slot swap | HW-ID changed when the slot order changed | Re-read HW-ID from System constants and update the tag. |
| 0x8090 only on cold restart (OB102), works in RUN | OB100/101/102 not configured or not updated; HW-ID tag initialised to zero | Initialise the HW-ID tag from the system constant in the startup OB, or mark the tag as retentive and initialise it once in OB100. |
| 0x8091 after firmware update on the IO device | Device temporarily missing during re-parameterisation | Check the device diagnostic; restart the IO device if needed. Verify GSD file version matches firmware. |
| 0x80B0 after PROFINET reconfiguration | IO device has not yet completed parameter assignment | Add a startup delay (e.g. DPRD_DAT in OB100 is not recommended) and only call in OB1 after the device reports "IO device ready" via the IO_device_state instruction. |
| 0x80C0 / 0x80C1 on first call | IO device has not yet returned the first consistent frame | Call DPRD_DAT in a cyclic OB and accept that the first one or two calls may return 0x80C0; the data is valid from the third call onward. |
11. Compatibility Notes Across TIA Portal Releases
- TIA Portal V12.0 — first release in which the HW-ID addressing model is mandatory for S7-1500.
-
TIA Portal V13 / V13 SP1 — the migration wizard for S7-300 → S7-1500 leaves the legacy I/O address in
LADDR; the field fix described in this article is required. -
TIA Portal V15.1 and later — symbolic HW-IDs (e.g.
"ID_Reader_1"."Input slot_1") are supported, eliminating the need to look up a numeric constant. - TIA Portal V17 / V18 / V19 / V20 / V21 — behaviour is unchanged. The DPRD_DAT reference manual in the V21 cloud describes the same HW-ID semantic.
12. Summary
Error 0x8090 (decimal -32624) from DPRD_DAT on an S7-1500 is, in the vast majority of field cases, not a hardware fault. It is the runtime expression of a parameter-model change introduced in TIA Portal: the LADDR input is no longer the logical I/O base address but the HW identifier of the slot. Reading the HW-ID from the system constants (not the head module) and updating the LADDR tag resolves the fault without any change to the hardware configuration, the GSD/GSDML, the cabling, or the ID reader. After the fix, monitor RET_VAL online and confirm that the consistent data range declared in the slot matches the length of the RECORD parameter.
What does Siemens error -32624 (hex 0x8090) on DPRD_DAT mean on an S7-1500?
It means the LADDR parameter does not match the HW-ID of any input or output slot in the device configuration. On S7-1500 CPUs, DPRD_DAT requires the HW identifier (HW-ID) of the slot, not the legacy logical I/O base address that SFC14 used on S7-300/S7-400. Re-read the HW-ID from PLC > System constants in TIA Portal and write it into the LADDR tag.
How do I find the correct HW-ID for an ID reader input slot in TIA Portal?
Open PLC > System constants and locate the entry named after the device and the I/O slot, e.g. ID_Reader~Input. The value in the Value column is the HW-ID (decimal DWORD, for example 276). Do not use the HW-ID of the head module; it does not represent a consistent I/O range and will return 0x8090.
Can I keep the original SFC14 / SFC15 call from the S7-300 program in the migrated S7-1500 project?
No. S7-1500 does not expose the SFC14/SFC15 system functions; only the renamed DPRD_DAT/DPWR_DAT extended instructions are available. The LADDR constant from the S7-300 program must be replaced with the HW-ID of the target slot, otherwise the call returns 0x8090 at runtime.
What is the maximum consistent data length for DPRD_DAT on an S7-300 / S7-400 CPU?
CPUs of the S7-300/S7-400 range support up to 64 bytes of consistent data per DPRD_DAT call. For records longer than 4 bytes you must use DPRD_DAT; the standard process image (PEW/PED) cannot guarantee consistency. On S7-1500 with PROFINET IO, the consistent range can extend up to 1024 bytes per slot, subject to the GSDML declaration of the IO device.
After fixing the HW-ID, the first call still returns 0x80C0 / 0x80C1. Is the fix wrong?
No. 0x80C0/0x80C1 indicate that the I/O module has not yet returned the first consistent data frame. This is normal on the first one or two scan cycles after the IO device finishes parameter assignment. Continue calling DPRD_DAT cyclically in OB1; the call returns 0 (success) once the data is available.