S7-1200 CM1243-5 PROFIBUS DP Slave Alarm Troubleshooting

Resolving S7-1200 CM1243-5 PROFIBUS DP Slave Alarm Detection Errors

When implementing slave-side diagnostic alarming on a Siemens S7-1200 with a CM 1243-5 PROFIBUS master, engineers routinely encounter error code -32622 (hex 16#8092) when calling the DEVICESTATES, RALRM, GET_DIAG, or MODULESTATES extended instructions. The error string reads "LADDR does not exist" — a misleading message that pushes the engineer toward the slave hardware when the actual fault is a hard-coded LADDR constant in the block instance DB that bypasses the TIA Portal system constant tag binding. This reference consolidates the root cause, the corrected block wiring, and the commissioning checks required to make any DP slave alarm visible in the S7-1200 user program.

1. Problem Statement: Slave Alarm Visibility on CM 1243-5

A typical installation places an S7-1200 CPU (for example, 6ES7 215-1AG40-0XB0) on the left bus with one CM 1243-5 master. The master scans four remote I/O systems (for example, ET200SP, ET200MP, ET200S, and a downstream subnet behind a DP/DP coupler) and exchanges cyclic process data. The maintenance team needs to know which physical DP slave raised the alarm — not just that the PROFIBUS cable is intact. The engineer reaches for the diagnostic palette, drags a DEVICESTATES block into OB 1, types a literal LADDR (often the HW identifier of the DP/DP coupler or a slot number seen in the device view), compiles, downloads, and immediately receives RET_VAL = 16#8092 on the block output. A return value of -32622 decimal / 16#8092 hex means the CPU could not associate the LADDR input with a hardware object it owns.

The same fault pattern appears regardless of which diagnostic instruction is used. RALRM, MODULESTATES, and GET_DIAG all return 16#8092 if their LADDR is not bound to a valid hardware identifier at compile time. The original case report documented four failed attempts: LADDR 281 (the DP/DP coupler's HW identifier), LADDR 284 (the network image of slot 1), and several derived guesses. Every attempt failed because none of those numbers was a system constant tag pointing at the CM 1243-5 PROFIBUS interface. Typing the value 281 directly into the block input tells the compiler nothing about which device the value refers to; the firmware verifies the constant at runtime and rejects the call because no hardware object in the project matches.

The corrective procedure is the same in every case: open the PLC tag table, switch the filter to "Show all tags", locate the System constants folder, drag the appropriate hardware identifier tag (for example, "CM 1243_5"~DP-master system~HW_ID_260 or whatever TIA Portal assigned) to the LADDR input of the diagnostic block, re-compile, re-download, and the diagnostic state becomes visible. The remainder of this article explains why the LADDR matters, how to find the right system constant, and how each of the four blocks should be called in production code.

2. Hardware and Network Context

The CM 1243-5 (Siemens part 6GK7 243-5DX30-0XE0, firmware V1.0 and later) is a PROFIBUS DP master module that snaps onto the left bus of an S7-1200 CPU. It operates as a DPV0 master by default and as a DPV1 master when the connected slave supports the extended protocol. The module's key specifications bound the design of the diagnostic application.

The reference network in the original case report contains four DP nodes. The S7-1200 CPU executes the user program. The CM 1243-5 owns the PROFIBUS DP segment and is what the diagnostic blocks must address. Each remote slave is a passive node addressed by its PROFIBUS station number (3, 4, 5, 6 in the example). The DP/DP coupler (Siemens part 6GK1 572-1AM00 or compatible) at DP address 5 acts as a transparent bridge to a secondary PROFIBUS segment. Alarms raised on the secondary segment are not visible to the S7-1200 in the same way; the coupler consumes them and only re-emits the status it has been configured to mirror.

3. Diagnostic Instruction Set Overview

The S7-1200 firmware exposes four extended instructions for PROFIBUS diagnostics. Each serves a different purpose, and the choice of instruction is dictated by the answer the user program needs.

The S7-1500 family uses the same block names but with an extended parameter set. The S7-300/400 family historically used SFB 52 (RDREC) and SFB 54 (RALRM) inside the diagnostic OBs; the S7-1200 version encapsulates that functionality behind the extended-instruction labels. For an installation that mixes S7-1200 and S7-300 slaves, only the S7-1200 blocks work; an S7-300 program cannot call DEVICESTATES, and an S7-1200 program does not expose SFB 52/54 as such.

Choosing the right block is the first decision. DEVICESTATES is the lowest-overhead option when the application only needs to know "is anything wrong?" plus the bit position of the offending slave. RALRM is the only block that returns the human-readable alarm text and the slot/channel location of the fault. GET_DIAG returns the full DPV1 diagnostic record but consumes more CPU time per call. MODULESTATES is useful when an ET200SP station has many sub-modules and the application needs to know which one is in error.

4. Root Cause: Error Code -32622 (16#8092)

The Siemens error-naming convention packs the return value of the diagnostic blocks into a 16-bit word. Bit 15 set indicates an error, and the lower 15 bits contain a code mapped to the TIA Portal online help. Decoding the common return values:

The 16#8092 return is issued by the firmware when the LADDR input cannot be resolved to a hardware object that the CPU has been configured to own. The most common root causes, in order of frequency observed in field commissioning, are:

1. The LADDR input is a literal integer typed into the block instance. The firmware rejects the call because no compile-time check can verify the integer against the project hardware. Solution: bind the input to a system constant tag from the PLC tag table.
2. The LADDR input is bound to a system constant, but the constant points to the wrong object (for example, the DP/DP coupler's HW identifier instead of the master's). The firmware finds the constant but cannot perform the requested operation because the constant is a slave, not a master interface.
3. The hardware catalog in TIA Portal is older than the firmware of the CM 1243-5. The HW identifier is not yet registered. Solution: update the hardware catalog via Options > Manage HSP, or upgrade to a current TIA Portal version that includes the new HSP.
4. The CM 1243-5 has not been downloaded to the project, only to the device. The CPU's online hardware view is out of sync with the offline project. Solution: re-download the project to the CPU in STOP mode so the CM 1243-5 is registered as a known module.
5. The hardware identifier is for a sub-module that does not support the requested operation. For example, the CM 1243-5 head module's HW identifier is valid for GET_DIAG, but not for DEVICESTATES (which requires the DP-master sub-module identifier).

For the original case, the LADDR 281 was almost certainly the HW identifier of the DP/DP coupler, and 284 was the HW identifier of a sub-module on one of the ET200 stations. Neither is a valid target for DEVICESTATES when called from a non-OB-82 context; the firmware returns 16#8092 because the constant resolves to an object that the master-level query cannot address. The system constant for the CM 1243-5 DP-master sub-module is what the block expects.

5. Solution: System Constant Tags for LADDR

The fix is procedural. Open the project in TIA Portal, expand the PLC tag table, change the filter from "User-defined tags" to "All tags", expand the System constants folder, and drag the appropriate HW identifier tag onto the LADDR input of the diagnostic block. TIA Portal binds the input symbolically, and the firmware resolves the symbol at compile time. If the project re-compiles without errors, the LADDR is valid.

The five steps, in order:

1. In the project tree, double-click PLC tags > Show all tags. The default view hides system constants; the toggle is the second icon on the tag table toolbar (or use the filter drop-down at the top of the tag list).
2. Locate the folder System constants > [Your PLC name] > CM 1243-5 > DP-master system. Each hardware object in the project receives a system-constant tag whose name is the symbolic path of the object.
3. Identify the tag named "CM 1243_5"~DP-master interface~HW_ID (or similar). The exact name varies by project; a representative example is "CM 1243_5"~DP-master system~260. The numeric suffix is the HW identifier TIA Portal assigned to the master interface, not the PROFIBUS station address.
4. Drag the tag onto the LADDR input of the DEVICESTATES, RALRM, GET_DIAG, or MODULESTATES instance. The input field displays the symbolic name in italics, indicating a system constant binding. A typed integer displays in regular face and remains a literal.
5. Compile, download to the CPU in STOP mode, and run. The block RET_VAL is now 16#0000, and the STATE output returns the bit pattern described in the next section.

The same system-constant mechanism applies to every diagnostic block and to the DPWR_DAT / DPRD_DAT instructions used to exchange acyclic record data with DPV1 slaves. The S7-1200 system manual walks through the procedure in section "Hardware identifier and logical address". Engineers familiar with legacy S7-300 may recognize this as the modern equivalent of "use the start address from HW Config"; the symbolic binding replaces the I/Q address pair that S7-300 programs used to read directly from the process image.

6. DEVICESTATES Block: Modes 0-6 Reference

DEVICESTATES is the right starting block for the "is anything wrong?" question. It scans all configured DP slaves in one call and returns a DWORD bit mask (STATE) in which bit n corresponds to the slave at PROFIBUS station address n. A bit set to 1 indicates the condition described by the MODE parameter.

A SCL implementation that loops over the 32-bit mask and reports the offending stations. MODE = 2 is the right choice for the "which slave raised an alarm" question:

// OB 1: cyclic diagnostic scan, called every 500 ms
IF "DiagScan_TON".Q THEN
    "DiagScan_TON".TON(IN := FALSE);
    "DiagScan_TON".TON(IN := TRUE, PT := T#500ms);

    // DEVICESTATES mode 2 = diagnostic pending
    "instDEVICESTATES"(MODE   := 2,
                       LADDR  := "CM 1243_5"~DP-master system~260,
                       RET_VAL => "dwDiagRetVal",
                       STATE  => "dwDiagState");

    // Iterate bits 0..31 to find the offending station
    "bAlarmActive" := FALSE;
    FOR "iStation" := 0 TO 31 DO
        IF ("dwDiagState" AND SHL(DWORD#1, "iStation")) <> 0 THEN
            "bAlarmActive" := TRUE;
            "wAlarmStation" := "iStation";
            EXIT;     // first alarm only; remove EXIT to enumerate all
        END_IF;
    END_FOR;
END_IF;

The block call is non-blocking: DEVICESTATES completes in a single OB 1 cycle because the diagnostic data is already cached in the master's firmware. If the loop is the only response to the alarm, the code reports the first offending station and waits for the operator to clear it before resuming. A more elaborate version stores a bitmask in a global DB and surfaces it to the HMI for an alarm list view, with one row per station and the timestamp of the last transition.

7. RALRM Block: AINFO Payload Decoding

RALRM is the block that returns the human-readable payload of an alarm. It is called inside the diagnostic OBs (OB 82 for diagnostic interrupt, OB 40 for process alarm, OB 83 for insert/remove, OB 55-57 for status/update/vendor-specific) where the input LADDR is bound to the HW identifier of the slave that raised the alarm. The TIA Portal "Add new OB" wizard places a pre-wired RALRM call in the generated code that can be used as a starting point; the typical engineer task is to decode the AINFO buffer for the HMI.

The block signature in TIA Portal V16/V17 is:

RALRM(
    MODE     : INT,        // 0 = all data, 1 = TINFO only, 2 = AINFO only
    LADDR    : HW_IO,      // HW identifier of the slave that raised the alarm
    MLEN     : INT,        // max. bytes to write into AINFO (e.g., 200)
    TINFO    : VARIANT,    // task information (OB start info, 34 bytes)
    AINFO    : VARIANT,    // alarm information (alarm-specific payload)
    RET_VAL  : INT         // error code
);

The TINFO output is the 34-byte OB start information. The first 12 bytes (OB_HEADER, OB_PRIORITY, OB_NUMBER) describe which OB was triggered. The next 22 bytes (OB_IO_FLAG, OB_MDL_ID, OB_LENGTH, OB_FAULT_CODE, and so on) are the I/O-specific alarm header. The AINFO output is the alarm payload proper, including the slot number, channel number, and a structured list of channel diagnostics formatted per the PROFIBUS DPV1 specification. A typical channel-diagnostic entry inside AINFO is 6 bytes long: 1 byte channel error type, 1 byte channel number, 2 bytes channel error value, 2 bytes additional vendor-specific data.

A typical OB 82 implementation that pushes the alarm to a global DB for the HMI to display:

// OB 82 - Diagnostic interrupt
VAR_TEMP
    info_OB82    : ARRAY[0..31]  OF BYTE;
    alarm_ainfo  : ARRAY[0..199] OF BYTE;
    dwRetVal     : DWORD;
    wSlot        : WORD;
    wChannel     : WORD;
    wChannelError: WORD;
END_VAR

BEGIN
    "instRALRM"(MODE   := 0,
                LADDR  := #OB82_MDL_ID,    // OB 82 start info; MDL_ID = slave HW-ID
                MLEN   := 200,
                TINFO  := #info_OB82,
                AINFO  := #alarm_ainfo,
                RET_VAL => #dwRetVal);

    IF #dwRetVal = 0 THEN
        // Extract slot (byte 6 of AINFO for DPV1)
        #wSlot := WORD#16#0000 OR #alarm_ainfo[6];
        // Channel (byte 7)
        #wChannel := WORD#16#0000 OR #alarm_ainfo[7];
        // Channel error (bytes 8-9, little-endian)
        #wChannelError := WORD#16#0000
                          OR (WORD#16#00FF AND #alarm_ainfo[9] * 256)
                          OR (WORD#16#00FF AND #alarm_ainfo[8]);

        // Store in global DB for the HMI
        "gDB_DiagAlarm".Slot         := #wSlot;
        "gDB_DiagAlarm".Channel      := #wChannel;
        "gDB_DiagAlarm".ChannelError := #wChannelError;
        "gDB_DiagAlarm".Timestamp    := RD_SYS_T;
        "gDB_DiagAlarm".NewAlarm     := TRUE;
    END_IF;
END_ORGANIZATION_BLOCK

The ChannelError field is a bitmask defined in the PROFIBUS DPV1 specification (IEC 61158-6). Common values encountered in the field: 16#0001 short circuit, 16#0002 overvoltage (U), 16#0003 overtemperature (T), 16#0004 wire break (F), 16#0005 parameter assignment error (P), 16#0006 actuator warning, 16#0007 actuator error, 16#0008 fuse blown, 16#0009 sensor error, 16#000A process-side error, 16#000B communication error. The HMI can map these bit patterns to operator-readable messages and color-code the affected channel on a process overview screen.

8. GET_DIAG and MODULESTATES Companion Blocks

GET_DIAG returns the full DPV1 diagnostic record from a specific hardware object. It is the right block when the application needs the vendor-specific diagnostic data (e.g., the ET200SP module's order number, firmware version, channel-level status word) and not just the alarm header that RALRM provides.

// GET_DIAG in cyclic scan
VAR
    diagInfo : ARRAY[0..199] OF BYTE;
    details  : VARIANT;
    dwRetVal : DWORD;
END_VAR

BEGIN
    "instGET_DIAG"(MODE       := 0,
                   LADDR      := "ET200SP_Head"~Head module~HW_ID,  // system constant
                   COUNT      := 200,
                   DIAG_INFO  := #diagInfo,
                   DETAILS    := #details,
                   RET_VAL    => #dwRetVal);
END

MODE = 0 returns the diagnostic data of the addressed module. MODE = 4 returns the diagnostic data of all sub-modules of the addressed module (a useful bulk read for an ET200SP station with many I/O cards). MODE = 6 returns the maintenance status only. MODE = 8 reads the channel-level diagnostic of a single sub-module. The full MODE list is in the S7-1200 system manual; the behavior of each mode matches the corresponding DPV1 record index defined in the PROFIBUS specification.

MODULESTATES is the per-module companion to DEVICESTATES. While DEVICESTATES reports at the station (slave) level, MODULESTATES reports at the sub-module level of a specific station. Its MODE parameter is the same as DEVICESTATES (0..6), and the STATE output is a DWORD bit mask where bit n corresponds to slot n of the addressed station. For an ET200SP with 16 slot positions, bits 0..15 are used; bits 16..31 remain at zero.

// Detect which slot in ET200SP raised the channel fault
"instMODULESTATES"(MODE   := 6,                 // I/O fault per slot
                   LADDR  := "ET200SP_Head"~Head module~HW_ID,
                   RET_VAL => "dwModRetVal",
                   STATE  => "dwSlotMask");

FOR "iSlot" := 0 TO 15 DO
    IF ("dwSlotMask" AND SHL(DWORD#1, "iSlot")) <> 0 THEN
        "gDB_DiagAlarm".FaultSlot := "iSlot" + 1;  // PROFIBUS slots are 1-based
    END_IF;
END_FOR;

The combination DEVICESTATES + MODULESTATES + RALRM provides a complete diagnostic stack: DEVICESTATES finds the offending slave, MODULESTATES finds the offending slot, RALRM returns the channel-level payload. Most production alarms can be cleared with just DEVICESTATES + RALRM inside OB 82; the MODULESTATES call is reserved for deeper drill-down UIs where the user clicks on a specific station in the HMI tree to see exactly which channel is in fault.

9. DP/DP Coupler, Repeater, and Multi-Master Topology

The DP/DP coupler at station address 5 in the original case is a passive bridge; it does not generate DP-V1 alarms on behalf of slaves on its secondary segment. The S7-1200 program therefore only sees the coupler as a single node. To detect alarms on the secondary segment, the engineer has two options:

1. Add a second CM 1243-5: install a second PROFIBUS master on the S7-1200 (the S7-1200 left bus supports up to three CMs total), run a separate PROFIBUS cable to the secondary segment, and address the slaves directly. This is the cleanest approach for new installations and gives full diagnostic access to the secondary slaves. TIA Portal assigns each CM a separate system-constant tag (e.g., "CM 1243_5_1"~DP-master system~260 and "CM 1243_5_2"~DP-master system~265); the user program instantiates DEVICESTATES twice, once per master, and disambiguates "station 3 on master 1" vs "station 3 on master 2" in the HMI display.
2. Configure the coupler for data-exchange mirroring: the DP/DP coupler (6GK1 572-1AM00) has a configuration utility (SIMATIC iMap or the GSD-based DP/DP coupler configuration tool) that exposes the secondary-side status as input bytes on the primary side. The S7-1200 then reads those input bytes cyclically and decodes the status field. This approach loses the DPV1 alarm semantic but is acceptable for non-critical segments where the maintenance team only needs a "secondary network OK / not OK" indicator.

A repeater (Siemens 6GK1 500-0AB10 or compatible) is transparent at the diagnostic level. If the original case had used a repeater instead of a coupler, DEVICESTATES mode 2 would correctly report alarms on slaves behind the repeater; the LADDR still points at the master, not at the repeater. Repeaters do not appear in the TIA Portal device view because they are not addressable; their only function is signal regeneration on long cable runs.

Optical link modules (OLMs) and optical PROFIBUS terminals introduce a small but measurable diagnostic latency (typically 1-3 ms per OLM hop) and do not require any application-level change; the master and slave see the link as a single electrical segment.

10. Verification, Timing, and Commissioning

The end-to-end diagnostic path can be visualized as a sequence of state changes from the physical event to the HMI alarm row. A reliable commissioning procedure walks through each transition and verifies that the expected state change occurs in the expected time window.

After binding the LADDR to a system constant and downloading the project, verify the diagnostic application end to end with the following procedure.

1. Compile and download the project to the S7-1200 in STOP mode. A download in RUN is possible if the diagnostic blocks are new; otherwise, the CPU will refuse the load with a "module address in use" error.
2. Switch the CPU to RUN. Open a watch table in TIA Portal, add the system-constant tag and the DEVICESTATES instance outputs (RET_VAL, STATE) to the watch list. Confirm RET_VAL = 0 and STATE = 0 (no pending diagnostic) at the first scan.
3. Force a diagnostic event on one of the DP slaves. The easiest method is to disconnect the PROFIBUS connector on the slave while the system is running; the master raises a station-failure alarm within 1 to 2 seconds. Alternatively, if the slave is an ET200SP with analog inputs, short-circuit a 4-20 mA channel at the field terminals to provoke a wire-break or overrange diagnostic.
4. Confirm the DEVICESTATES STATE bit corresponding to the offline station is set. With the LADDR correctly bound, the RET_VAL remains 0; the only change is the bit pattern. This validates the system-constant binding.
5. Confirm OB 82 fires. Open the "Online & diagnostics" view of the CPU and inspect the diagnostic buffer. The buffer should show an entry "Diagnostic interrupt from module [slave HW identifier]" with a timestamp within 100 ms of the physical event.
6. Confirm RALRM populates the AINFO buffer. Watch the global DB fields populated in the OB 82 implementation; the Slot and Channel fields should reflect the offline station or the shorted channel.
7. Restore the slave (reconnect the connector or remove the short circuit). Confirm the DEVICESTATES STATE bit clears after one or two DEVICESTATES scan cycles (typically 500 ms to 2 s, depending on the PROFIBUS retry timing and the user-program scan interval).

PLC trace (TIA Portal V14 SP1 and later) is the most efficient way to record the diagnostic state over time. Configure a trace recording the DEVICESTATES RET_VAL, STATE, and the OB 82 global DB fields; trigger the trace on the rising edge of "NewAlarm"; review the timing of the alarm propagation from physical event to user-program visibility. For deterministic timing analysis, a 10 ms trace interval is sufficient to capture the OB 82 invocation and the RALRM return value transitions.

End-to-end latency expectation: physical event to alarm visible in the user program is typically 10-50 ms on a 1.5 Mbps PROFIBUS network with 4 slaves. A 12 Mbps network with 4 slaves is typically 5-20 ms. These are the times the diagnostic frame spends in transit plus one OB 82 cycle. They do not include the user-program scan interval, which is the limiting factor for cyclic DEVICESTATES-based detection.

11. Error Code Reference Table

The complete list of RET_VAL codes returned by DEVICESTATES, RALRM, GET_DIAG, and MODULESTATES on the S7-1200 is documented in the S7-1200 system manual and the TIA Portal online help. The most common return values encountered in field commissioning are summarized below.

The full list of DPV1 record-level error codes (returned by the lower layer, e.g., 16#DF80 BUSY, 16#DE80 negative acknowledgment) propagates through RALRM in the AINFO buffer as a status byte. The TIA Portal help on RALRM lists every byte of the AINFO structure for each OB type. Cross-reference the S7-1200 system manual appendix on diagnostic block error codes for the complete enumeration.

12. Cross-Platform Compatibility Notes

The DEVICESTATES, RALRM, GET_DIAG, and MODULESTATES instructions are S7-1200- and S7-1500-specific wrappers around the lower-layer SFB/SFC calls of S7-300/400. The mapping for cross-platform debugging and migration is summarised below.

An S7-300 program that has been ported to an S7-1200 typically replaces every SFB 52/53/54 call with the corresponding extended instruction and binds the LADDR to a system constant. The OB 82, OB 40, and OB 83 user code in the S7-300 program can be reused largely verbatim because the S7-1200 OB interfaces are binary-compatible. The diagnostic buffer inspection is identical: Online & diagnostics > Diagnostic buffer in TIA Portal shows the same event format as the STEP 7 V5.x interface.

An S7-1500 program has additional capabilities: the diagnostic blocks return more data per call (longer AINFO buffers, vendor-specific channel information) and the PLC trace supports trigger conditions on diagnostic events. The block names are the same as S7-1200, so the same system-constant binding procedure applies. Where an S7-1200 program is being ported forward to an S7-1500 (e.g., when the 1215C CPU is replaced with a 1515-2 PN), the LADDR system constants may need to be re-bound because TIA Portal assigns new HW identifiers during the device substitution; the project re-compile flags any unresolved constants.

13. Frequently Asked Questions