Resolving Siemens S7 Bit-Byte Swap in WinCC Alarm Trigger

1. Overview: The Siemens S7 / WinCC Discrete Alarm Bit-Order Problem

Engineers configuring STEP 7 (S7-300 / S7-400) data blocks for use with SIMATIC WinCC Flexible 2007 (or its successor WinCC Comfort / Advanced in the TIA Portal) frequently encounter an apparent anomaly when wiring discrete alarm trigger bits to tags of type INT or WORD. A trigger bit of value 1 fires the first alarm; a trigger bit of value 16 should fire the sixteenth. Yet the sixteenth bit in DB4.DBW0 — at absolute address DB4.DBX1.7 — fires correctly, while the first bit of the second word — at absolute address DB4.DBX2.0 — is reported by WinCC Flexible as Trigger Bit 24, not Trigger Bit 16.

This is not a bug, a misconfiguration, or a corrupt tag. It is the documented difference between the big-endian bit ordering used by the S7-CPU for symbolic / absolute bit addresses and the little-endian bit ordering used by the WinCC HMI runtime on Windows/Intel. The PLC lays out word 0 as bits 0-7 (low byte) followed by bits 8-15 (high byte); WinCC Flexible numbers the same 16 bits 0-15 but the low byte is rendered last when you read left-to-right, producing a swap of the two bytes inside the word.

This reference documents the exact cross-reference, the underlying endianness rule, three production-proven workarounds (symbolic bit decomposition, Excel helper tool, and TIA Portal migration), and a step-by-step alarm configuration procedure with verification checks. References are drawn from the official Siemens SIMATIC Technical Documentation, the Siemens SiePortal addressing forum, and the Inductive University Siemens addressing reference for cross-platform address translation.

2. Root Cause: Big-Endian vs Little-Endian Bit Numbering

The S7-CPU stores a 16-bit WORD in memory as two bytes: the high byte at the lower absolute address, the low byte at the higher absolute address. The bit numbering within a byte is itself big-endian: bit 0 is the MSB (most significant bit) and bit 7 is the LSB (least significant bit) of that byte. The STEP 7 absolute address DB4.DBX1.0 therefore refers to the MSB of the second byte in the word — what most engineers would intuitively call "bit 8" of the WORD.

The WinCC Flexible HMI runtime, executing on Windows / Intel x86, numbers bits 0-15 left-to-right across the displayed WORD with little-endian byte order. The first byte WinCC paints is the LSB byte (the byte stored at the higher STEP 7 address), and the second byte is the MSB byte (the byte stored at the lower STEP 7 address). Within each byte, the bit numbering also flips relative to STEP 7: WinCC bit 0 is the LSB of its displayed byte, while STEP 7 DBX0.0 is the MSB of its absolute byte.

Both ends are consistent within their own convention; the mismatch is purely in the projection of the same 16 bits onto the integer index that the alarm configuration dialog reads. The transformation between the two schemes is the byte-and-bit reversal documented in Section 4 of this article.

3. The DBW-to-Alarm-Trigger Mapping in WinCC Flexible 2007

When you declare a tag of data type INT with array length 15 — i.e. a 15-element array of 16-bit integers — and wire it to a discrete alarm source in WinCC Flexible, the HMI runtime evaluates one trigger bit per array element per configured alarm. The trigger bit is a 1-based index, not a 0-based index, because WinCC Flexible numbers the discrete alarm bits 1-16 within each 16-bit word of the array.

For an array element that begins at absolute byte n in the data block, the bit index i used in the alarm configuration corresponds to a STEP 7 absolute address derived from the table in Section 4. The engineer who originally raised the question observed the following alarm wiring on DB4.DBW0 with a 15-element array:

The second element of the array — i.e. the WORD beginning at absolute address DB4.DBX2.0 in STEP 7 — is reported by WinCC Flexible as Trigger Bit 24. This is because the bit-number sequence continues across the array: the first alarm of the second word is bit 17 (DB4.DBX2.1 in STEP 7) and the sixteenth is bit 32 (DB4.DBX0.0 in STEP 7, completing the second word). The engineer who saw "Bit 24" had simply entered the discrete alarm configuration in a different starting order; the math is consistent.

4. Complete DBX-to-WinCC-Trigger-Bit Cross-Reference

The table below gives the canonical mapping for any alarm wiring on a STEP 7 WORD that is exposed to WinCC Flexible as an INT array element. Use the formula

wincc_bit_index_1based = 16 * n_word + reverse_byte_swap(i_step7_zero_based)

where:
  n_word           = WORD offset within the array (0 for DBW0, 1 for DBW2, 2 for DBW4 ...)
  i_step7          = 0..15, the bit index WinCC would expect from sequential 1..16
  reverse_byte_swap(i) = 15 - (i XOR 8)   ; i.e. swap the two bytes then reverse the bit order within each byte

The expanded form, suitable for direct copy into commissioning notes, is shown below for DB4.DBW0 and DB4.DBW2:

The "Word-internal bit" column (0..15) is the bit index used inside STEP 7 logic when you assemble the WORD with a bit-OR (e.g. L B#16#0F to set the low four bits of a byte, or the SLW / SRW rotate instructions to position individual flags).

5. Workaround 1 — Symbolic Bit Decomposition in STEP 7

The most maintainable solution is to abandon the byte-packed representation and declare the alarm words as a STRUCT of BOOL fields inside the data block. Each BOOL gets a symbolic name in the STEP 7 symbol table; the HMI tag in WinCC Flexible then references the individual bit by its symbolic name and the bit-order issue disappears because the HMI driver resolves the bit transparently.

1. Open the data block (e.g. DB4) in STEP 7 and declare a structure of BOOLs. A useful convention is to group 16 alarms per word and to name each field with a functional identifier (e.g. Alarm_Motor1_Overtemp, Alarm_Pump2_DryRun).
2. Add a multi-line comment column inside the DB declaration. In that comment, record the WinCC Flexible trigger-bit number that the BOOL will be wired to. This becomes a permanent commissioning record that survives handover.
3. Compile the DB. STEP 7 will assign absolute addresses automatically; DB4.Alarm_Motor1_Overtemp will land at one of the addresses in the table in Section 4.
4. In WinCC Flexible 2007, create a discrete alarm. In the trigger tag field, browse to the connection, the PLC, and the DB. From the DB, pick the symbolic BOOL — not the parent WORD. WinCC Flexible will then map the trigger to a single bit automatically.
5. Repeat for each alarm. The mapping comment in the DB ensures the alarm text, the trigger condition in the PLC, and the HMI display all stay aligned across commissioning iterations.

6. Workaround 2 — Excel Helper for Manual Bit Calculation

For engineers who must keep the byte-packed layout (e.g. because the alarms are populated by an FB that writes a single WORD, or because of plant-wide naming conventions), an Excel helper sheet removes the arithmetic at the desk. A proven layout is:

Use Column D to record the alarm text, the PLC rung that sets the bit, and the operator that acknowledges it. Print the sheet and file it inside the cabinet for the maintenance crew; it converts an invisible convention into a hard-copy lookup that survives a crashed HMI project file.

7. Workaround 3 — Migrating to TIA Portal and WinCC Comfort / Advanced

For new projects on S7-1200 / S7-1500 the convention is unchanged in TIA Portal — the HMI still uses the Intel little-endian bit projection — but the configuration tool makes the mapping explicit. The recommended workflow is:

1. Create a PLC data type (UDT) in TIA Portal with a STRUCT of named BOOLs for the alarms.
2. Instantiate the UDT in a global DB. The TIA Portal compiler assigns each BOOL to a single bit in the data block; the bit order is no longer the engineer's concern.
3. In the HMI tag editor, create one HMI tag per BOOL. The tag's PLC tag field points at the symbolic BOOL in the UDT instance DB; WinCC / TIA Portal resolves the absolute address automatically.
4. Wire each alarm's trigger tag to the corresponding HMI tag. No bit index has to be entered; no Excel lookup is needed.

The trade-off is wire count: 16 HMI tags per 16 alarms, where the older approach used one tag with an array of 15. For plants with thousands of alarms this multiplies the HMI tag count significantly; weigh against the savings in commissioning time and in "alarm appeared on the wrong line" tickets during the warranty period.

8. Step-by-Step: Configuring Discrete Alarms in WinCC Flexible 2007

The original symptom (Trigger Bit 24 appearing when bit 1 of the second word was expected) typically traces back to a single configuration error: the array length of the HMI tag is one element short of what the engineer assumed. The following procedure eliminates that class of error and applies the bit mapping deterministically.

1. Define the alarm word in the DB. Open DB4 in STEP 7. Declare DBW0 as a WORD with a comment block listing all 16 alarms the word will carry, in the order you want them displayed in the HMI alarm view.
2. Decide the packing strategy. Either: (a) keep the word packed and accept the byte-swap, using the Section 4 table to compute trigger bits; or (b) break the word into 16 individual BOOLs with symbolic names and the WinCC side stays simple. For maintenance-heavy plants, choose (b).
3. Create the HMI connection. In WinCC Flexible 2007 open Communication > Connections. Add an MPI / PROFIBUS / TCP connection to the S7 station. Confirm the connection status turns green in the runtime.
4. Add the tag. In Tags create a new tag. Set the connection, address DB 4 DBW 0, data type INT (or WORD). Set the array length to the number of 16-bit words the alarm set will occupy. For a 15-element array, set the length to 15 and WinCC will use addresses DBW0, DBW2, ... DBW28.
5. Configure the discrete alarm. Open Alarms > Discrete Alarms. For each alarm set the trigger tag to the array element, then enter the trigger bit (1-16 for the first word, 17-32 for the second, and so on). Use the Section 4 table to translate from the STEP 7 absolute address to the WinCC trigger bit number.
6. Set the alarm class. Choose the alarm class (Errors, Warnings, System, etc.) and the acknowledgment model. Discrete alarms default to "Incoming", "Outgoing", "Acknowledge" events.
7. Compile and download. Use Project > Compiler > All, then transfer the runtime to the panel. In the WinCC Flexible transfer dialog, set the operating mode to "Transfer" before clicking "Load".
8. Test. From STEP 7 use Monitor / Modify to force each bit of DB4.DBW0 individually. Verify that the corresponding alarm text appears in the alarm view, that the correct color is applied, and that acknowledgment writes back the ACK bit if you have configured it.

9. Verification: Forcing and Observing the Bit-to-Alarm Path

Verification must cover three independent paths: the PLC bit set, the HMI bit read, and the HMI alarm rendered. Force each independently and observe the next stage.

If Test 1 shows the wrong value in the tag monitor, the HMI connection or the tag address is wrong — the byte-swap itself is correct and the alarm configuration is the only suspect. If Test 1 is correct but the alarm is fired on the wrong line of the alarm view, the trigger bit index in the discrete alarm configuration is wrong and must be re-keyed using the Section 4 table.

10. PLC Logic Patterns for Setting Alarm Bits

When the alarm word is built up in the PLC, two patterns are common. The first is a sequence of S (set) instructions on individual flags that are OR-merged by STEP 7's load-and-OR mechanism. The second is to compute the WORD value and assign it in a single move.

Pattern A — explicit per-bit set (clearer, more I-code):

// STL excerpt — S7-300/400
A       M 100.0       // alarm condition 1
S       DB4.DBX 0.1   // maps to WinCC trigger bit 1
A       M 100.1       // alarm condition 2
S       DB4.DBX 0.2   // maps to WinCC trigger bit 2
A       M 100.2       // alarm condition 3
S       DB4.DBX 0.3   // maps to WinCC trigger bit 3
// ... continue for all 16 alarms of the word
A       M 100.7       // alarm condition 8
S       DB4.DBX 1.0   // maps to WinCC trigger bit 8

Pattern B — single-word assembly with cross-reference helper:

// SCL excerpt — S7-300/400
DB4.AlarmWord0.%X0  := AlarmCond01;  // DBX0.0, WinCC bit 16
DB4.AlarmWord0.%X1  := AlarmCond02;  // DBX0.1, WinCC bit 1
DB4.AlarmWord0.%X2  := AlarmCond03;  // DBX0.2, WinCC bit 2
DB4.AlarmWord0.%X3  := AlarmCond04;  // DBX0.3, WinCC bit 3
DB4.AlarmWord0.%X4  := AlarmCond05;  // DBX0.4, WinCC bit 4
DB4.AlarmWord0.%X5  := AlarmCond06;  // DBX0.5, WinCC bit 5
DB4.AlarmWord0.%X6  := AlarmCond07;  // DBX0.6, WinCC bit 6
DB4.AlarmWord0.%X7  := AlarmCond08;  // DBX0.7, WinCC bit 7
DB4.AlarmWord0.%X8  := AlarmCond09;  // DBX1.0, WinCC bit 8
DB4.AlarmWord0.%X9  := AlarmCond10;  // DBX1.1, WinCC bit 9
DB4.AlarmWord0.%X10 := AlarmCond11;  // DBX1.2, WinCC bit 10
DB4.AlarmWord0.%X11 := AlarmCond12;  // DBX1.3, WinCC bit 11
DB4.AlarmWord0.%X12 := AlarmCond13;  // DBX1.4, WinCC bit 12
DB4.AlarmWord0.%X13 := AlarmCond14;  // DBX1.5, WinCC bit 13
DB4.AlarmWord0.%X14 := AlarmCond15;  // DBX1.6, WinCC bit 14
DB4.AlarmWord0.%X15 := AlarmCond16;  // DBX1.7, WinCC bit 15

The SCL version reads in the same order as the WinCC trigger bits if you use the %X0 indexing. Note however that %X0 in SCL is the leftmost bit of the S7-CPU's representation — the MSB of the low byte in absolute addressing — which is the same bit the operator sees as Trigger Bit 16 in WinCC. To make the SCL code read 1-16 in operator order, write the %X access in the same sequence as the comments above.

11. Best-Practices Checklist for Alarm-Word Projects

1. Group by 16. Always pack alarms in 16-bit WORDs. Mixing WORDs and DWORDs in the same array confuses the byte-swap arithmetic and the Excel helper.
2. Comment the DB heavily. Every WORD should carry a multi-line comment that names the WinCC trigger-bit number for each bit. Maintenance crews will read the DB long after the HMI project is archived.
3. Prefer BOOLs for new projects. The symbolic BOOL approach (Workaround 1) eliminates the swap entirely. Use it on every new DB and back-fit it on existing DBs during the next outage.
4. Validate with PLCSIM. S7-PLCSIM and WinCC Flexible / TIA Portal can run on the same engineering station. Force the alarm word, watch the HMI render, and confirm the mapping before going to plant.
5. Document endianness in the project QA pack. The convention is consistent across S7-300, S7-400, S7-1200 and S7-1500. A one-page "Bit-order convention" note inside the project folder saves hours during handover. Reference the convention in the Functional Design Specification.
6. Avoid cross-platform HMI drivers without a translation layer. Third-party SCADA packages (e.g. Ignition) sometimes expose S7 tags using the PLC's native bit ordering rather than the Intel projection. Verify with the vendor that the alarm-trigger configuration uses the same convention as WinCC before going to plant — see the Inductive Automation Siemens addressing note for an example of a third-party driver that resolves absolute addresses only, not symbolic ones.
7. Use address priority on TIA Portal projects. When migrating an S7-300/400 alarm DB to TIA Portal, set the BOOLs to high address priority. Re-laying out the DB to add a new alarm class will not break the HMI tag wiring. Procedure documented in the SiePortal TIA Portal V15.1 address priority Q&A.
8. Keep a cabinet copy of the Excel helper. When the HMI project file is missing or corrupted the on-site engineer must be able to look up which absolute DBX drives which alarm. A printed sheet inside the cabinet door is the cheapest insurance available.

12. Troubleshooting Matrix: Symptom, Cause, Fix

Frequently Asked Questions