Why an HMI alarm only logs when the bool state changes

Why a bit alarm goes quiet between changes

Alarm engines in HMI software evaluate a tag against an alarm condition and write a record when the condition turns true. A bool tag has exactly two transitions to offer, so a bit alarm fires once when the bit turns on and once when it turns off. Vendors' alarm and event guides describe alarms the same way: an alarm is an event raised by a condition on a tag, not a sampler that wakes up on its own schedule. The empty stretches in your log are the documented behavior working as intended, and the missing lines have to be manufactured as tag changes.

A trend graph looks richer only because the pen redraws the stored level at its own scan rate, and pens have redraw limits of their own; if yours stalls at a fast sample rate, that is the subject of why an HMI trend graph will not update every half second. The one-shot behavior is the same edge trigger that fires an HMI event once when a PLC alarm bit turns on and then waits for the next edge. The alarm database will not wake up on a schedule to sample a steady bit, so the schedule has to arrive as a changing tag from the PLC.

Symptoms and what each points to

• One line per trip and one per clear, nothing between. The alarm is on the bag monitor bit itself and the bit is steady; no periodic trigger exists in the chain yet.
• Two records per minute, about half a minute apart. The trigger is a clock comparison such as 'seconds below 30', which is on for 30 s and off for 30 s and crosses twice per minute.
• Records missing at random minutes. The trigger pulse is shorter than the HMI's poll interval, so the HMI reads the tag just before it sets and just after it clears and never sees the ON state.
• Two records per cycle, one on the pulse rising and one on it falling. The alarm condition watches both transitions; set it to the ON transition only.
• Graph line flat at one value all shift. The mapped register never changes; watch the register in the PLC monitor while you force the bit on and off, and check both branches of the mapping logic.

Build the 60-second trigger in the PLC

The trigger is a self-resetting cycle timer plus a pulse stretch. Names, types and initial values in the block below are illustrative; use your PLC's own timer instructions and syntax:

(* Types: line_running, bag_ok, sample_pulse are BOOL, FALSE at power-up.
   cycle_timer and pulse_hold are on-delay timers. *)

cycle_timer(IN := line_running, PT := T#60s);   (* 60 s cycle *)
IF cycle_timer.done THEN
    sample_pulse := TRUE;                       (* rising edge fires the alarm *)
    cycle_timer.reset := TRUE;                  (* restart now, cadence stays 60 s *)
END_IF;
pulse_hold(IN := sample_pulse, PT := T#2s);     (* stretch the pulse to 2 s *)
IF pulse_hold.done THEN
    sample_pulse := FALSE;                      (* fall is ignored by an ON-edge alarm *)
END_IF;

Set the preset in the timer's own time base: 60 s is 60000 on a millisecond timer and 60 on a timer that counts seconds. A time base read wrong turns the 60-second plan into a 60-millisecond one, the same conversion trap covered in convert HMI minutes to PLC timer units.

Make the pulse wider than the HMI's poll interval. HMI polls commonly run between 100 ms and 1 s, and an alarm can only react to a value the HMI has actually read. A pulse one PLC scan long, a few milliseconds, can set and clear between two polls, and that minute never reaches the file. Two seconds covers it: a pulse wider than one poll interval must be sampled by at least one poll, whatever the phase between the two clocks.

Point the alarm at sample_pulse, not at bag_ok. Set its condition to the ON transition, the rising-edge or 'bit on' condition your HMI's alarm setup offers. An any-change condition also fires on the fall and doubles the file to 120 records an hour. Put the live state in the alarm message text the way you would print any tag value into a message string, so a line reads bag monitor = RUN or bag monitor = OFF; the history stamps each record with the date and time.

The records collect in the alarm history, the same timestamped store that can record job completion time with an alarm history. Aim that history at a file destination in the HMI's logging setup, then open the file and look at it; the alarm banner on the screen and the stored log are different things.

Recommendation: keep the existing alarm on bag_ok for genuine trips, and add the PLC-built trigger when the file must show one line per interval: the 60 s self-resetting cycle timer that restarts the moment the pulse sets, the 2 s pulse stretch, an ON-transition alarm on sample_pulse with the live state in the message text, and the history pointed at the file. Map the bit to a 0/1 register and trend it when the deliverable is a graph; build both chains when you need the trace and the file.

Map the bit to a number for a graph trace

A trend pen draws a number, so give it one. Write the mapping in the PLC and trend the result:

// trend_value : INT, 0 at power-up
IF bag_ok THEN trend_value := 1 ELSE trend_value := 0 END_IF

Pick values that sit inside the pen's scale: 0 and 1 on an auto-scaled axis, 0 and 100 if the pen reads percent. This is the same one-bit, two-values mapping that shows two text states on an HMI from one PLC bit, with numbers in place of text. You can also build it in the HMI with two event entries, one writing 1 to an internal tag when bag_ok turns on and one writing 0 when it turns off, then trend that internal tag. The PLC register version is easier to watch in PLC monitor mode, and it sidesteps the screen-change resets described in why a real time graph clears when you change HMI screens.

The trace answers where the state sat and when it stepped. The alarm file answers the requirement of one timestamped line per interval. Keep the two deliverables straight when the request comes back as 'a graph that logs'.

Example: one 10-hour shift, 600 records

Scenario: the collector runs one 10-hour shift, the bag monitor never trips, and the file must carry one record every 60 s.

Records per shift: 10 h × 3600 s/h = 36000 s, and 36000 s ÷ 60 s per record = 600 records. Each record is a timestamp plus the state text, call it 40 characters: 600 × 40 = 24000 characters, about 24 kB per shift. A three-shift day writes 1800 records, 1800 × 40 = 72000 characters, 72 kB, and a month of single shifts lands at 600 × 30 = 18000 records, roughly 720 kB. Storage is trivial; the value of the arithmetic is the end-of-shift check it gives you: the file should hold exactly 600 lines.

Now the arithmetic of the clock comparison. 'Seconds below 30' is on for 30 s and off for 30 s, so it crosses twice a minute and an any-change alarm writes 2 records/min = 120 records/h, double the 60 records/h the interval asks for. With the alarm set to the ON edge the comparison does produce one record per minute, but only on a controller whose program can read the real-time clock's seconds register, and every record is pinned to the clock's wrap. The self-resetting timer needs no clock and its cadence is yours: set the preset to 300 s and the same chain writes 36000 ÷ 300 = 120 records per shift.

Pulse width inside the same example: a 2 s pulse against a 1 s poll means every pulse covers at least one poll moment, so no interval is missed. Shrink the pulse to one scan, say 10 ms, and a 1 s poll can straddle it; that minute never reaches the file, and the shift ends with 599 lines where the arithmetic predicts 600.

Checks before you trust the file

1. Run five minutes with the bit untouched: 300 s ÷ 60 s = 5 records expected. Fewer than 5 means a missed pulse; widen the pulse to 4 s and re-run.
2. Open the file at its destination, not the alarm banner. Every line needs a date-time stamp and the state text.
3. Force bag_ok off and on between two records: the next line must carry the new state. If the state text never follows the bit, the message string is bound to the wrong tag.
4. Read two successive timestamps: they sit 60 s apart. A steady 62 s spacing means the cycle timer restarts only after the pulse ends; move the reset to the moment the pulse sets. A 120 s gap is a missed pulse.
5. Count the lines at shift end against the arithmetic: 600 records for a 10-hour shift at 60 s.

One safety point: this file is a record, and the bag monitor's trip action must stay in the PLC where it alarms or stops the collector directly; never route a protective response through the HMI log.

Questions