Configuring Discrete Alarms in TIA Portal for TP1200 HMI Panels

Overview

SIMATIC TP1200 Comfort panels running on TIA Portal accept three principal alarm categories: discrete alarms, analog alarms, and controller (system) alarms. Discrete alarms are bit-triggered events; they fire when a specific bit inside a configured trigger tag transitions to a defined state. Analog alarms are limit-value events evaluated on a numeric tag. Controller alarms are generated automatically by the SIMATIC S7-1500 or ET200S CPU for system diagnostics such as module faults or rack errors.

This article targets the most common source of confusion: a project where the controller exposes a multi-state variable (an INT or WORD that holds a process code) and the engineer wants a separate alarm message for each state. Discrete alarms can only be bound to a single bit of a trigger word, but the trigger word itself can be an INT, WORD, or DWORD - the HMI does not care about the data type's full width, only the bit you select. The remainder of this reference walks through the configuration, explains the bit-selection rule, and shows how to derive one alarm per process state.

Prerequisites

Before configuring discrete alarms, verify the following project assets exist:

1. TIA Portal project with the ET200S station and the TP1200 HMI device added to the same project. The HMI must be connected to the PLC through a PROFINET or PROFIBUS connection in "Devices & Networks".
2. PLC tags accessible on the HMI. In the TP1200's HMI tags table, the trigger variable must be defined as an HMI tag with the same name and data type as the PLC tag, or be linked through a direct PLC tag reference (recommended for S7-1500/ET200S).
3. Alarm class assigned in the HMI alarm configuration. Out-of-the-box, TIA Portal provides Errors, Warnings, and System; user-defined classes can be added (for example, ProcessCritical, ProcessInfo) with custom acknowledge requirements.
4. HMI runtime authorization. The user group running the alarm view must have at least the "Operate" permission on the alarm class. Edit user administration under "Runtime Settings > Users and Roles" if acknowledgement is required.

Hardware reference for the ET200S CPU is the SIMATIC ET 200S manual collection; the TP1200 Comfort is documented in the SIMATIC HMI TP1200 Comfort operating instructions. Alarm configuration rules are covered in the TIA Portal online help under "Configuring alarms > Discrete alarms".

Alarm Types in TIA Portal HMI Runtime

The WinCC Comfort/Advanced runtime distinguishes the alarm sources shown below. Choosing the wrong source for a use case is the most common configuration error.

For the "one alarm per INT value" use case, discrete alarms with a single trigger word are still the correct mechanism. The TIA Portal HMI runtime evaluates only the bit you point at; the remaining bits in the word are ignored by that alarm. This is the key insight that resolves the original question.

Discrete Alarm Architecture: Tag and Bit Mapping

A discrete alarm is bound to a single bit position of a tag. The tag can be declared as a Boolean (BOOL) - one bit, one alarm - or as a wider data type. When the tag is wider, you must specify the bit number (0-15 for WORD, 0-31 for DWORD, 0-7 for BYTE) when creating the alarm.

The bit-selection rule is the only technical constraint you must respect. Beyond that, the TIA Portal dialog allows up to 32 alarms to share one tag (in the case of a DWORD), or 16 for a WORD, or 8 for a BYTE. In practice, an INT or WORD exposes 16 alarm "slots" per tag, which is more than enough for a typical process code register.

Why the dialog asks for a bit number

The alarm runtime in WinCC Comfort stores the alarm state as a bit index into the configured trigger word. To determine whether the alarm is active, the runtime polls the trigger tag from the controller, masks the configured bit, and compares the masked result against the configured trigger state. This is why a 16-bit word can drive up to 16 alarms but never more - the resolution is one alarm per bit.

Memory layout example

Assume a process status word in the ET200S declared as:

// PLC tag in ET200S
"ProcessStatus" : WORD   // %MW100, status bits from auxiliary logic

Bit assignments:

Each row in this table becomes one discrete alarm in the TP1200 alarm editor, all bound to ProcessStatus at the relevant bit number. Eight alarms consume a single WORD tag - no extra HMI tags required.

Step-by-Step: Configuring Discrete Alarms

The procedure below creates the eight discrete alarms listed above and assigns them to the alarm view on the TP1200 screen.

1. Open the HMI device editor. In the project tree, double-click the TP1200 device to open the HMI editor.
2. Open the alarm editor. In the editor tree, expand "Runtime settings > Alarms". Right-click "Discrete alarms" and choose "Add new discrete alarm".
3. Bind the trigger tag. In the alarm row, click the trigger tag field. The selection dialog shows all PLC tags visible to the HMI. Select ProcessStatus (data type WORD).
4. Set the bit number. When the tag is wider than one bit, the dialog reveals a "Bit number" column. Enter 0 for the first alarm, 1 for the second, and so on through 7 for the eighth.
5. Choose trigger mode. Open the "Trigger" column. Choose between Rising edge, Falling edge, and Status. The default is rising edge; for "maintenance due" the status mode is often more useful because the trigger word stays set until the operator clears the bit manually.
6. Set the alarm text. Click the alarm text cell and enter the operator-facing string. Use multiline alarms for diagnostics, e.g. "Drive overload - investigate\nCheck motor current and conveyor load".
7. Assign an alarm class. Use Errors for E-Stop and overload, Warnings for starved/blocked/maintenance, and System (or a custom info class) for state changes such as idle/running/manual mode.
8. Configure acknowledgement. If acknowledgement is required, expand the alarm class properties and set "Acknowledgement" to "With acknowledgement". By default, discrete alarms are not acknowledged; events appear and clear without operator action.
9. Add the alarm view to a screen. Drag the "Alarm view" control from the toolbox onto the process overview screen. Configure its filter to show all configured alarm classes.
10. Compile and download. Compile the HMI first, then the PLC. Download to the TP1200 and the ET200S in that order. Cycle power on the HMI if the runtime reports "alarm configuration outdated".

Trigger Modes: Rising Edge, Falling Edge, and Status

The trigger mode determines when the alarm transitions from Inactive to Active and back. Choosing the wrong mode leads to alarms that never clear, or alarms that fire repeatedly while the condition holds.

Mapping a Multi-State INT to Discrete Alarms

Some applications expose a process state as a small enum: 0 = Idle, 1 = Running, 2 = Starved, 3 = Blocked, 4 = E-Stop. TIA Portal discrete alarms cannot be bound to a numeric range, only to a bit. There are two supported techniques to map an enum to discrete alarms.

Technique 1 - Decode the enum into a bit pattern in the PLC

Add a small helper word and let the ET200S program maintain a one-hot representation of the current state. Each state corresponds to one bit:

// ET200S S7-150 / ET200S STL excerpt
// StateWord : WORD, %MW102
// ProcessState : INT, %MW100 input
LAR1  P##StateWord      // pointer to local copy of StateWord
L     W#16#0
T     LW [AR1,P#0.0]    // clear all bits
L     #ProcessState
JL    _ERR              // out-of-range jumps to error handler

JU    _IDL
_0:   L     W#16#0
      JU    _WR
_IDL: L     0
      L     W#16#0       // bit 0 = idle
      JU    _WR
_1:   L     2            // bit 1 = running
      JU    _WR
_2:   L     4            // bit 2 = starved
      JU    _WR
_3:   L     8            // bit 3 = blocked
      JU    _WR
_4:   L     16           // bit 4 = E-Stop
_WR:  T     LW [AR1,P#0.0]
_ERR: NOP 0

Once StateWord is published to the HMI, configure one discrete alarm per state, all bound to StateWord with the bit number equal to the state index.

Technique 2 - Use separate BOOL tags per state

Less efficient on the wire (one tag per alarm) but simpler to commission. The PLC sets or clears individual BOOL tags in mutual exclusion. Each tag is bound to a single discrete alarm with bit number 0.

For projects on a constrained PROFINET line where update bandwidth matters, Technique 1 is preferred. For small machines with fewer than ten states, Technique 2 is more readable and the bandwidth cost is negligible.

Acknowledgement, Logging, and HMI Display

Discrete alarms support an optional acknowledgement workflow. When acknowledgement is required for the alarm class, the alarm stays in the To acknowledge state until an operator with the appropriate rights presses the "Acknowledge" button in the alarm view. The runtime event log records came in, went out, and acknowledged events with millisecond timestamps sourced from the HMI clock. To keep the log consistent with the controller, enable time synchronization on the HMI to the PLC (Runtime Settings > Time synchronization) so the HMI clock follows the ET200S CPU time.

For long-term archival, configure a log target under "Logs > Alarm log". The TP1200 supports logging to a CSV file on a plugged SD card or to a remote SQL database through the WinCC option WinCC/Logging. The alarm log retains entries even after a power cycle, provided the SD card is present and not write-protected.

Showing alarms on the TP1200

Three screen objects are useful for alarm display:

• Alarm view - tabular display of active and historical alarms, with sort, filter, and acknowledge controls.
• Alarm indicator - compact icon shown on a header bar that flashes red or yellow depending on the highest active alarm class.
• Alarm window - pop-up that appears on every new alarm and requires acknowledgement before it closes (configure under "Screen > Events").

For most production HMIs, the alarm indicator on the header combined with a full-screen alarm view on a dedicated "Alarms" page is the standard layout.

Sending PLC Alarms Automatically to the HMI

If the ET200S CPU is an S7-1500-class controller (IM 151-8 PN/DP), the runtime also supports controller alarms (also called "PLC alarms" or "program alarms"). These are messages that you write in the PLC program using the Program_Alarm instruction (in SCL) or the ALARM_8P / NOTIFY_8P legacy block (in STL). The text and any associated process values travel with the alarm; the HMI receives them automatically without any per-message configuration.

This approach is documented in the TIA Portal cloud help: Sending complete alarms from the controller to the HMI device and automatically updating them. The advantage over discrete alarms is that the alarm text lives in the PLC program (one source of truth, version-controlled with the controller source) and the HMI is reconfigured automatically when the controller source changes. The disadvantage is that the project must be built on TIA Portal V16+ and the controller must support the Program_Alarm instruction (S7-1500 series and IM 151-8 PN/DP from firmware V3.0).

A minimal SCL example:

// SCL on IM 151-8 PN/DP
IF #Overload THEN
    "DB_Alarms".AlarmOverload.In := TRUE;
    "DB_Alarms".AlarmOverload.Latch := TRUE;
    "DB_Alarms".AlarmOverload.Severity := 2;  // 0=info, 1=warn, 2=error
    "DB_Alarms".AlarmOverload.Text1 := 'Drive overload';
    "DB_Alarms".AlarmOverload.Text2 := CONCAT('Current=', REAL_TO_STRING(#Current_A));
    "DB_Alarms".AlarmOverload();  // call the Program_Alarm instance
END_IF;

For greenfield projects that use a SIMATIC S7-1500 or IM 151-8 PN/DP with V3.0 firmware, prefer program alarms. For brownfield work on legacy S7-300 / S7-400 / IM 151-7 CPUs, the discrete alarm mechanism described above is the only available approach.

Verification and Commissioning

After the project has been built and downloaded, perform the following checks before handing the line over to production:

1. Tag online test. In the HMI tag table, set the trigger tag ProcessStatus to a value with the bit you want to test. The corresponding alarm must appear in the alarm view within the configured polling cycle (default 1 s). For a status-mode alarm, reset the bit and confirm the alarm clears.
2. Acknowledge path. With an alarm class that requires acknowledgement, log in as a user with the "Operate" permission and confirm the acknowledge button is enabled. Log out and verify the button is disabled.
3. Time stamp drift. Compare the HMI clock with the PLC clock. If the difference exceeds 1 s, enable time synchronization under "Runtime Settings > Time Synchronization".
4. Power cycle. Power off the HMI, then power it back on. The active alarm list should be restored from the controller; the alarm log should remain intact on the SD card.
5. Network loss. Disconnect the PROFINET cable between the ET200S and the TP1200 for at least 5 s. The runtime should generate a system alarm "Connection to PLC interrupted" within the configured time-out (default 3 s). Reconnect and confirm the alarm clears.

Troubleshooting Matrix

Notes on Edge Cases and Interoperability

On TP1200 panels configured as PROFINET IO devices, the HMI itself becomes a node on the bus. The discrete alarm polling cycle must be shorter than the controller's update cycle, otherwise alarms will lag by one cycle. The default 1-s poll is acceptable for most discrete alarms; reduce to 250 ms for E-Stop-class events by adjusting the HMI tag acquisition cycle.

When migrating projects from WinCC Flexible 2008 to TIA Portal, discrete alarm configurations are imported as-is, but the bit-number column is hidden behind the "Advanced" view in the alarm editor. Engineers familiar with WinCC Flexible may assume the bit number is implicit and discover the configuration issue only at runtime. Make the bit column visible by right-clicking the alarm table header and enabling "Bit number".

For HMI panels that talk to a third-party controller (Allen-Bradley CompactLogix, Schneider Modicon M340) over EtherNet/IP or Modbus TCP, the discrete alarm mechanism in the TIA Portal HMI still works, but the trigger tag must be a Modbus holding register or an EtherNet/IP assembly mapped to a Boolean or 16-bit tag. Allen-Bradley C-More Micro HMI alarm setup uses an entirely different configuration model with separate "alarm screen" objects, illustrating the value of documenting the chosen toolchain up front.

Frequently Asked Questions