Count discrete input events on an HMI without PLC edits

What the alarm count does

A discrete alarm watches one boolean tag and raises one event when that bit turns on. That is the mechanism behind every HMI alarm system, whether the text warns of a fault or only notes that a sensor fired. The panel's event manager ties the tag to the action, and an alarm count display on a screen shows how many times that action has fired, so one OFF-to-ON transition of X0 adds one to the number.

Two limits decide whether that number serves you. The tally counts turn-on events, and one complete on/off cycle holds exactly one of them, so a requirement written as state changes reads at half the rate on this display. And the number is a display figure inside the panel project: the ladder has no register to read, nothing samples the value at the 60-minute mark, and nothing zeroes it for the next interval.

The total means X0 turn-ons only while this event is the only tag in the project carrying an alarm action. A second alarmed event mixes into the same figure.

Set up the event and the count display

What you need: the panel project connected to the PLC with the input resolvable in the tag database, a screen with room for one more object, and a way to toggle the input on demand for a test.

1. Add the input to the tag database as X0, pointed at the PLC input the sensor uses.
2. In the event manager, add an event with Event Type Tag, tag X0, condition when ON.
3. Set the action to Alarm and give it event text such as "X0 turns ON".
4. Open a screen, add an Alarm Message object, and select its Alarm Count display.
5. Download the project to the panel using your site's normal procedure, then test with controlled transitions before anyone reads the number for production.

The trigger itself is generic: HMI software raises one event per OFF-to-ON transition, the same pattern described in this guide to configuring events for OFF-to-ON triggering. Keep this event the only alarm action in the project unless the count object can filter to a single event; check that filter before you add real alarms.

Symptoms and what each one points to

• Count holds at 1 while X0 stays ON. Correct turn-on behavior. If the machine cycled twice and the count moved once, the input never returned OFF between events, and the panel counted one ON state, not two parts.
• Count runs ahead of the parts. Contact bounce or a chattering sensor is being counted, or a second alarm action in the project feeds the same object. Debounce the signal in the controller or filter the count.
• Count falls behind the parts. The input pulses are shorter than the panel's tag update time, so no tag read landed inside the ON window. The worked example below puts numbers on this.
• Two counts per part. The project is reacting to both edges of the cycle. A per-part tally adds 1 per complete on/off cycle, never 2.
• The number vanishes or zeroes when alarms are acknowledged or cleared. That tells you the total lived in alarm display state, not in storage. Write the value down before any clear if you lean on the display at all.

Check the input before trusting the count

Watch the raw bit as the machine runs: does X0 return OFF between events, how long does it stay ON, can it bounce. The setup in displaying 16 PLC input and output bits on one screen puts a single input on screen the same way. Then run a controlled test: note the displayed count, produce a known number of OFF-to-ON transitions with the machine in an approved test state under your lockout procedure, leave the input OFF between transitions so every event is unambiguous, and compare the count change against the transitions you caused.

A slow test passing tells you little about a fast input. Repeat at full line speed and compare the count against the parts actually produced. If the event never fires at speed, the tag was sampled between pulses, the same visibility failure described in why an R_TRIG pulse never shows on the HMI screen.

Example: a box line counted through the panel

Say a packaging line counts boxes off X0, one pulse per box at 600 boxes per hour, so one pulse every 6 s (3600 s / 600 = 6 s). The sensor holds X0 ON for 250 ms per box. The panel reads its tags on its own scan; take this project's tag update as 500 ms, an illustrative value, and read the real one from your driver settings. The arithmetic works for any pair.

The event fires only if a tag read lands while X0 is ON. On a 500 ms read cycle with a 250 ms ON window, the share of reads that land inside the window is 250 ms / 500 ms = 0.5. Over the hour: 600 boxes × 0.5 = about 300 counted. The display loses roughly half the production, and the misses land at random, so nobody can correct for them by feel.

The rule out of these numbers: any ON window longer than the tag update means the event fires on every read, so with a 500 ms update the input must hold ON past 500 ms, and 250 ms fails that test. The PLC sees the same input differently because it samples X0 inside its logic scan, every few milliseconds on a small machine, so a 250 ms pulse spans dozens of scans and none are missed. Even a perfect panel tally would still show one running total from project start; slicing it into hours needs a capture at each boundary, a function this configuration has no hook for.

Decision for this line: the panel tally is unusable at 250 ms pulses and 600 per hour, showing about 300 of 600. It becomes trustworthy when pulses hold ON past one full tag read, here over 500 ms, and the hourly record belongs in the controller either way.

Where the hourly counter belongs

The job breaks into three functions: count each turn-on, capture the value at the hour, reset for the next hour. The first can live in either device. The second and third are controller functions: a counter incremented on the OFF-to-ON edge of X0, a register that copies the accumulated value when the real-time clock reads the top of the hour, then a reset of the working counter. That is a short rung set and an engineering change order.

Until the change is approved, an operator can read the panel tally at the hour and write it down, with the clear-behavior warning above in mind. If the record has to survive untouched, a data server that logs the tag on an hourly schedule and holds the records is the usual layer for it; keeping protected hourly records in a data server walks through that setup. Once the register exists, display it: how to display a PLC counter value where operators can see it covers the screen side, and showing motor run hours on an HMI from a PLC counter uses the same capture-and-display pattern at an hourly interval.

Recommendation: Configure the tag event on X0 with an alarm action and an alarm count object when the crew needs a visible turn-on tally, the input holds ON longer than one full tag update (for example 500 ms ON against a 500 ms update), and this event is the only alarm action in the project. Move the counter into the PLC, with the hourly capture and reset on top, as soon as the number feeds an hourly report, a rate, or anything someone might audit; keep the panel object as the indicator on the floor and put the PLC register on screen instead.

Questions