Operator text in HMI alarms: configuring event messages

What you need

Before changing the alarm configuration, identify:

• The HMI model, engineering software version and matching manufacturer documentation.
• The PLC condition or trigger bit that creates the alarm.
• The writable string used for text entry, including its declared capacity.
• The alarm field types supported by the configured HMI target.
• The alarm view, acknowledgment behavior and any history or archive used by the application.
• Whether one event or several independent events need their own wording.

Make changes in a controlled commissioning environment. Operator comments should supplement the equipment condition, not replace its identity or determine protective action. Do not alter safety logic to test message formatting.

This work belongs in the control-system HMI. A separate information screen is a different application, as explained in factory status display or operator HMI.

Check what the alarm editor supports

A dynamic alarm field inserts a supported value into a configured message. A text-list field selects wording from a predefined list. These are not interchangeable.

1. Open a test alarm in the configuration for the actual HMI target. Do not rely on a feature available only on another target or software version.
2. Inspect the available message fields and their supported tag types in the matching manufacturer documentation.
3. Try selecting the proposed string tag, then compile the HMI project. Resolve unsupported-type and field-format errors before continuing.

A successful compile confirms configuration compatibility, not correct runtime behavior. You still need to check communication, entry completion and message presentation.

If the editor rejects the string, use a supported alternative. An adjacent text field is useful only if its relationship to the displayed alarm is clear. One shared comment box beside several alarm rows is ambiguous unless the application binds it to the selected event.

Bind and validate the text input

Start by proving the text path without involving the alarm trigger. For a PLC-triggered application, PLC-connected storage lets the controller validate the submitted entry and capture it for an event.

1. Create or identify a writable string and expose it through the configured HMI connection. Confirm its type and declared capacity.
2. Bind the text-entry object to that tag. Check permissions, input mode, maximum entry length and the action that commits an edit.
3. Enter a short, distinctive phrase and finish the entry operation. Inspect the PLC value online. It should match the completed entry.
4. Repeat with the longest permitted entry, a blank entry and any punctuation the application allows. Include non-ASCII characters if they are required in service.

The input limit must fit the destination storage and the alarm field's supported representation. Depending on the platform, a length limit may concern characters, bytes or code units. Check the documented encoding and length rules rather than assuming every visible character occupies the same storage.

Define what happens when an entry is blank or too long. Rejecting an invalid submission with a clear prompt is preferable to silently presenting incomplete wording. Keep the fixed alarm description useful even when no comment is available.

Configure the trigger and fixed message

The trigger and the text parameter have separate jobs. The trigger creates the alarm state. The string supplies extra wording. Editing a string does not, by itself, activate a discrete alarm.

1. Configure the alarm against the intended PLC condition, trigger tag and bit where applicable.
2. Set its class and acknowledgment behavior to match the application's operating requirements.
3. Write a fixed description that identifies the equipment condition. Add the supported dynamic field after it, with a clear label such as Comment:.
4. Under controlled conditions, activate the test trigger and inspect the alarm view.

The expected result is the correct alarm identity, state and fixed text, followed by the intended comment. Check wrapping and available space at the maximum permitted entry length. A stored string can be complete even when the alarm row clips its visible text.

If the fixed message appears but the variable portion is blank, leave the working trigger path alone. Check the string value, field binding, formatting and input completion first.

Capture wording for each event

A live tag reference is not automatically an event record. If the alarm reads directly from an editable tag, a later edit may change the displayed comment. Whether that happens in an active view, history view or archive depends on the HMI's documented handling of alarm parameters.

Use separate editable and captured values when wording must remain associated with an occurrence. Names such as EntryText and EventText make the distinction clear, but the storage arrangement must suit the application.

1. Define an explicit submit action. Completing text entry and requesting submission must be separate from merely typing characters.
2. Establish how the PLC knows the complete submitted value has arrived. Use a documented transfer method or a validated request-and-acknowledgment sequence. Do not assume separate HMI writes reach the PLC together or in the order drawn on the screen.
3. Validate the accepted entry in the PLC, then copy it into storage assigned to that event. Record an event identifier if the application needs to distinguish repeated occurrences.
4. Bind the alarm parameter to the captured value. Prepare that value before activating the corresponding alarm condition.
5. Keep the captured value unchanged for as long as any active view or retained record still depends on it.

An acknowledgment should confirm acceptance of the intended submission, not merely that a request bit was observed. If a revision value is used, verify that the accepted revision belongs to the transferred text.

One snapshot string cannot preserve different wording for several outstanding events if each new event overwrites it. Use separate storage for independent alarm sources or an event-record mechanism that retains each occurrence's text.

Do not delay a necessary equipment alarm while waiting for a comment. Where the condition must be reported immediately, raise it with its fixed description and associate any later comment through a supported event-specific mechanism.

Check active and retained records

Test the views the application actually uses. An active alarm display and an archived record may not resolve dynamic fields in the same way.

Run this sequence with two unmistakably different phrases:

1. Submit the first phrase and confirm that the PLC has accepted it.
2. Trigger the test event and verify its fixed description and captured wording.
3. Change the editable entry to the second phrase without creating another event. The first event should retain the intended wording wherever retention is required.
4. Clear and acknowledge the alarm according to its configuration. Check that view filters show the expected state transitions.
5. Create another occurrence, then inspect both records in every history or archive view used by the application.
6. If the application requires retention across a restart, test that requirement under controlled conditions as well.

Record the expected text for each event before running the sequence. This makes a wrong association easier to detect than a generic check that some text appears.

If an older record changes after its snapshot storage is reused, the application is not retaining independent event text. Use the HMI's documented parameter-capture or event-record facilities, or retain the text in a separate record linked by event identity.

Resolve the result before release

Use the observed symptom to narrow the next check:

• No alarm appears: check the PLC trigger, connection status, alarm class and view filters.
• The alarm appears without its comment: check tag compatibility, the stored value and dynamic-field binding.
• The comment is shortened: compare input limits, string capacity, field formatting and visible row space.
• The previous entry appears: check submission completion and transfer timing before changing the alarm logic.
• An earlier event acquires newer wording: check snapshot reuse and whether the view stores parameter values or reads them again.

Keep a commissioning record of the accepted input length, blank-entry behavior, submission sequence and retention results. Release the configuration only when each required view shows the correct wording for the correct occurrence, not simply when one test alarm displays a string.

Questions