S7-1200 LED Instruction: Resolving HW Identifier 64 vs 50 Error

Problem: S7-1200 LED Instruction Returns No Status with HW Identifier 64

When the LED extended instruction is wired in TIA Portal with the CPU's own HW identifier (64 on the affected 1214/1215 stations), the function block produces no updated output even though the CPU is physically running, the instruction is being scanned, and ENO returns TRUE. Swapping the LADDR input to HW identifier 50 immediately returns valid RET_VAL values and the expected LED bit patterns. This behaviour is reproducible on both the CPU 1214 DC/DC/DC (6ES7 214-1AG31-0XB0) firmware V3.0.2 and the CPU 1215 DC/DC/DC (6ES7 215-1AG40-0XB0) firmware V4.20.

The root cause is not a firmware defect. It is a misuse of the LADDR input of the LED instruction. The instruction does not interrogate the diagnostic interface of the CPU as a whole; it interrogates the "Local~Common" LED subsystem whose system constant is automatically generated as HW identifier 50 in any default TIA Portal S7-1200 project. HW identifier 64 is the CPU's own hardware object, and the LED instruction is not designed to read its diagnostic mirror.

Root Cause Analysis: Why HW Identifier 64 Fails

The LED instruction belongs to the "Extended Instructions" folder in TIA Portal and reads the current state of physical LEDs on the S7-1200 module whose HW identifier is supplied at LADDR. Internally the instruction uses the standard S7 diagnostic data record set 0 (or its equivalent for S7-1200) to decode the LED bit image.

When LADDR is set to the CPU's own HW identifier (64 in this project), the diagnostic call still succeeds, but the returned LED image is associated with the CPU's own diagnostic frame, which contains different content. On the affected firmware releases (V3.0.2 on the 1214 and V4.20 on the 1215), this CPU-self frame does not surface the LED byte expected by the instruction decoder, so the block produces no usable state.

When LADDR is changed to 50, the call is re-targeted at the "Local~Common" pseudo-module that TIA Portal inserts into every S7-1200 device to expose the front-panel LED image as a coherent hardware object. The LED instruction was written against this exact interface, so it correctly returns RUN/STOP/ERROR/MAINT bit positions, the colour flag, and the flash flag.

Understanding S7-1200 System Constants

Every TIA Portal project automatically generates a set of system constants when the S7-1200 device is compiled. These constants are visible in two locations:

1. PLC tags table (default tag table, "System constants" tab): Lists every HW identifier with its symbolic name. The relevant entries for the LED instruction include:
   • Local~Common – the LED interface (commonly 50)
   • Local – the CPU object itself (commonly 64 on a default 1214 project)
   • Local~DI_0 – first digital input byte (commonly 0 or 1)
   • Local~DQ_0 – first digital output byte
   • Any installed signal board or communication module HW identifiers
2. CPU properties (System constants tab): Right-click the CPU in the project tree, select "Properties", and switch to the "System constants" tab. Every HW identifier belonging to the CPU is enumerated with its hex value, decimal value, and symbolic name. The same list drives the drop-down on the LED instruction's LADDR pin.

Always bind LADDR to the symbolic constant (for example Local~Common) rather than typing the literal decimal value. TIA Portal will re-assign HW identifiers if you add or remove a signal board, a communication module, or even re-order slots, and the literal value 50 will silently become 49, 51, or any other free number. Using the symbolic name prevents the LED instruction from pointing at the wrong object after a re-compile.

Step-by-Step Fix in TIA Portal V13 and Later

Follow this procedure to convert a failing LED instruction into a working one without touching the CPU firmware.

1. Open the affected TIA Portal project and the block (OB/FB/FC) that contains the LED call.
2. Select the LED instruction instance. On the properties inspector (right pane), navigate to the "Configuration" tab.
3. Click the drop-down next to LADDR. The drop-down is populated automatically with all available system constants of type "HW identifier" for the assigned CPU.
4. Replace the literal "64" with the entry labeled Local~Common. The numeric value populated by TIA Portal will match the system constant value for that project (50 in the affected projects).
5. Confirm the input RET_VAL is wired to a tag of type WORD (not BOOL, not INT). The instruction returns a 16-bit status word; if a smaller tag is wired, the upper byte is truncated and the status bits decode incorrectly.
6. Confirm the output LED_status is a tag of type WORD if it is used. Some project templates mistakenly allocate MW0 (a memory word) but then only evaluate bit 0. The instruction writes a full 16-bit word and the project must consume all bits it needs.
7. Recompile the program (Project tree > PLC > Compile > Software (rebuild all blocks)).
8. Download the rebuilt program to the CPU. The CPU stays in STOP during the download, then transitions back to RUN.
9. Force the CPU to STOP from the online panel and observe LED_status decoding bit pattern 2 (STOP LED on). Transition to RUN and observe bit pattern 1 (RUN LED on, green).

Verification Procedure: Confirm the LED Instruction Works

After re-pointing LADDR to Local~Common, perform these verification steps to confirm the fix.

1. Go online with the CPU in TIA Portal.
2. Open the block containing the LED instruction in "Monitor on/off" mode (glasses icon).
3. Toggle the CPU operating mode switch to STOP. The LED_status word should display the value expected for "STOP LED on". On firmware V3.0.2 and V4.20 the bit assignment is:
   • Bit 0: RUN (green)
   • Bit 1: STOP (yellow/orange)
   • Bit 2: ERROR (red, flashing)
   • Bit 3: MAINT (yellow, flashing)
   • Bit 4: Link/Activity (green)
   • Bits 5–15: reserved
4. Toggle the CPU to RUN. Bit 0 should be set; bit 1 should clear.
5. Trigger a diagnostic event (for example, unplug the signal board or cause a wire-break on a supported module). Bit 2 should pulse and the RET_VAL should still equal 0 (no instruction error).
6. Check RET_VAL in the monitor view. Any non-zero value indicates a parameter error. The relevant Siemens error codes are:
   • 0000_H – no error
   • 8090_H – module does not support the LED instruction
   • 8091_H – HW identifier type not supported
   • 80C0_H – diagnostic data record could not be read
   • 80D0_H – module is currently in firmware update

Affected CPUs and Firmware Versions

The following CPUs have been confirmed to expose the Local~Common LED interface and therefore accept the LED instruction with HW identifier 50-style symbolic constant:

Firmware V4.x introduced new diagnostic features but did not change the LED instruction interface. Projects migrated from V3.x to V4.x retain the same Local~Common HW identifier; only the decimal value may shift if the device configuration was modified.

Cross-Reference: LED Instruction Datatype Rules

The LED instruction is documented in the TIA Portal help under "Extended Instructions > Diagnostics > LED". The relevant interface specification is:

• Input LADDR: HW identifier of the LED subsystem. Type must be HW_IO (a system constant) or WORD (literal decimal/hex). Do not wire a BOOL, INT, or DINT.
• Output LED_status: WORD. Bits 0–4 carry the LED states; higher bits are reserved and read as 0.
• Output RET_VAL: WORD. Returns Siemens standard error code as a hex value (see verification section).

A common mistake in OB1 templates is to assign MW0 as the LED_status destination and then evaluate it byte-wise as MB0 and MB1. The instruction writes the full word, but a downstream consumer that treats only the low byte will lose the upper byte of LED state and may report "the instruction never changes". Promote the consumer to read the entire MW0 or use DBW from a dedicated instance DB.

Common Pitfalls and Workarounds

Pitfall 1: Manually entered HW identifier

If the original programmer typed "64" as a literal integer rather than selecting Local~Common from the system constant drop-down, the project will compile but the LED instruction will target the CPU object instead of the LED subsystem. Replace the literal with the symbolic constant.

Pitfall 2: Re-using constants after a hardware change

Adding a signal board (for example the SB 1221 DI 4 x 24 V DC) shifts every downstream HW identifier by one. The literal "50" silently becomes "51" and points at a different module. Re-link LADDR to the Local~Common symbolic constant after any hardware modification, then recompile.

Pitfall 3: Confusion between diagnostic and LED instructions

The "Diagnostics" instructions (such as RD_SINFO, Get_IM_Data, Get_Name) operate on different HW identifiers and have different datatype rules. Do not assume an instruction that works on HW identifier 64 will also work for the LED instruction. Always check the help page for the specific instruction.

Workaround: Read LEDs via diagnostic buffer

If the LED instruction cannot be deployed for any reason (for example on a third-party controller that polls the S7-1200), the diagnostic buffer of the CPU contains a timestamped history of LED state changes. Read it via Get_Diag from a programming station, or expose the buffer through an HMI tag list.

Code Example: STL Implementation of the LED Instruction

For engineers working in Statement List, the equivalent of the LAD LED block looks as follows. The Local~Common HW identifier is referenced symbolically; the actual decimal value is resolved at compile time:

// LED status read in OB1
// Symbolic names: "Local_Common_HW" resolves to the Local~Common HW identifier
// "LED_word"        is a WORD tag in DB100 ("Diagnostics")
// "LED_error"       is a WORD tag in DB100

CALL  LED
      LADDR   := "Local_Common_HW"
      LED_status := DB100.LED_word
      RET_VAL := DB100.LED_error

// Sample decoder
      L     DB100.LED_word
      T     MW    100         // snapshot for HMI display

// Bit-by-bit extraction
      A     DB100.LED_word.%X0   // RUN (green)
      =     "RUN_LED"
      A     DB100.LED_word.%X1   // STOP (yellow)
      =     "STOP_LED"
      A     DB100.LED_word.%X2   // ERROR (red flash)
      =     "ERROR_LED"

Structured Text (SCL) equivalents are also available; both produce identical machine code after compile.

Diagnostic Decision Matrix

Safety and Commissioning Notes

The LED instruction is read-only and has no side effect on the CPU operating state. It is safe to call every OB1 cycle in a running machine.

• Do not use the LED instruction in safety-related logic. It is intended for diagnostics and HMI display only.
• If the LED instruction is used to drive an HMI indicator, debounce the bit transitions in the HMI script to avoid flicker during mode changes.
• On firmware V4.4 and later, additional LEDs (such as the LINK/ACT LED on the PROFINET port) are exposed through the same interface. The bit positions described in the verification section remain unchanged for CPU LEDs but the LINK/ACT mapping moves; refer to the firmware-specific help page for the exact bit.
• Always test the LED instruction on a stopped CPU before deploying to a running line. A wrong LADDR cannot damage hardware but can mask a genuine diagnostic fault that the operator needs to see.

References (linked in body)

• Siemens S7-1200 Programmable Controller - System Manual (entry ID 109478121)
• STEP 7 (TIA Portal) Extended Instructions - LED
• S7-1200 CPU 1214 DC/DC/DC (6ES7 214-1AG31-0XB0) product page
• S7-1200 CPU 1215 DC/DC/DC (6ES7 215-1AG40-0XB0) product page
• Firmware update V4.20 release notes