Count events

A counter counts your definition of an event

If a carton blocks a sensor for 500 ms and the task runs every 10 ms, the program may observe the sensor true about fifty times. Those are fifty observations of one carton, not fifty cartons. The first job in counting is to define what makes one event distinct from the next.

For a simple discharge beam, you might count an observed false-to-true transition. That works only if each carton creates one such transition and the input system captures it. A carton that rocks across the beam can create several transitions. Two touching cartons can create only one. Before choosing a counter instruction, inspect the geometry and the expected signal.

Trace levels and edges separately

Assume the sensor samples below belong to a single carton passing the beam. A rising-edge event is true only when the current sample is true and the previous sample was false.

Replacing the event with the sensor level in an increment statement would add three counts in this trace. The program would be doing exactly what you asked: count true evaluations. The mistake would be in the event definition.

A standard CTU commonly performs its own rising-edge detection at its count input. Consult the chosen library's parameter names, count range, reset priority, and saturation behaviour. Beckhoff's standard-library documentation describes its CTU's count, preset, and reset interface; other environments may expose a different data type or interface. Beckhoff counter reference.

Make reset a production decision

A batch counter does not simply reset “when someone presses a button.” Is reset allowed during a batch? Does it discard the production record? What happens to a carton already between the fill station and the counting sensor? Is a new recipe allowed to change the target of an active batch?

For a teaching batch of twelve cartons, choose these rules: capture the target when a batch is accepted, count accepted discharge events, stop admitting new work when the batch objective is met, and clear the batch count only through an explicit new-batch action while the cell has been reconciled.

If several cartons can be in flight, stopping admission at twelve discharged cartons may already be too late. Track admitted, processed, and discharged quantities separately when needed. The right count depends on the decision you are making. One number cannot describe every stage of a line.

A bounded counter makes its limits visible

Here is an excerpt using a separately calculated DischargeEvent. BatchCount and BatchTarget are DINT values. NewBatchAccepted is a one-invocation event produced by a separate owner that has checked the initial conditions.

IF NewBatchAccepted THEN
    BatchCount := 0;
ELSIF DischargeEvent AND BatchActive THEN
    IF BatchCount < BatchTarget THEN
        BatchCount := BatchCount + 1;
    ELSE
        ExtraDischargeLatched := TRUE;
    END_IF;
END_IF;

BatchComplete := BatchActive AND (BatchCount >= BatchTarget);

The example refuses to increment beyond the target and records an extra event separately. It also gives a new-batch action priority over counting in the same invocation. That priority is acceptable only if the new-batch acceptance contract excludes a legitimate in-flight discharge; otherwise you would lose an event. The code makes the question visible instead of solving it by accident.

A production total may need a larger type and a different overflow policy. Never assume a counter can grow forever. Decide whether saturation, rollover tracking, or a wider representation is appropriate, and test the boundary without producing millions of physical parts.

Debouncing is a measurement policy

Contact bounce or a vibrating carton edge can create rapid transitions. One approach is to require the sensor to remain active for a qualification interval and then remain clear for a rearm interval. This defines a recognized object as a sufficiently stable occupied period followed by a sufficiently stable gap.

The intervals must fit the fastest valid product and smallest valid gap. If a carton blocks the beam for only 15 ms, a 50 ms active qualification rejects real cartons. Filtering cannot distinguish noise from real events unless their time or shape characteristics differ enough for your chosen rule.

An input module's hardware filter acts before the program sees the signal. A software qualifier acts on samples after acquisition. Document both. Adding a software delay while forgetting an existing hardware filter can create unexpected missed counts.

Short pulses require appropriate acquisition

A pulse that rises and falls between task observations may never appear in software. A standard counter called faster does not help if its input value updates slowly elsewhere. Consider the complete chain: sensor response, module filter, acquisition method, fieldbus update, task schedule, and counter evaluation.

High-speed hardware counters and capture inputs exist for events beyond ordinary cyclic sampling. Select and configure them using the target hardware documentation. Then decide how the cyclic program reads their count consistently, handles rollover, and establishes a reference. A hardware count solves acquisition speed; it does not define the meaning of a batch reset for you.

The misconception: a matching total proves correct counting

Ten missing counts and ten duplicate counts can produce the right final total. A useful verification therefore checks event correspondence, not just the number at the end. Use deliberately spaced single objects, pairs with minimum spacing, long obstructions, sensor chatter, and restarts at awkward moments.

Record where the count changes relative to object movement. If reverse motion is possible, decide whether a second passage should add, subtract, or be ignored. One beam alone may not establish direction. Two sensors or encoder information can support a richer event model, but they need their own sequence rules.

Try it

A sensor trace is false, true, true, false, true, false. Physically, one carton wobbled at the beam. A rising-edge counter reports two cartons. A colleague suggests dividing the total by two.

Explain why that is not a root-cause fix. Propose an event rule, name the measurements needed to choose its parameters, and describe a test that could show your proposal wrongly merges two real cartons.

Work through the answer

Dividing by two assumes every carton creates exactly two edges. The next carton may create one or five. Arithmetic after the count hides the acquisition problem without recovering object identity.

One possible rule counts a qualified occupied period once and does not rearm until the beam has remained clear for a minimum interval. You need observed chatter durations, the shortest legitimate occupied time, the shortest legitimate inter-carton gap, and timing uncertainty through the input chain. If noise and valid gaps overlap, time filtering alone may be insufficient; improve sensing geometry or use more evidence.

Test two real cartons at the smallest allowed spacing. If the clear interval is shorter than the rearm requirement, the rule merges them and counts one. That is a failed design even if it fixed the wobbling single carton. The test forces the requirement, measurement, and implementation to agree.

In state models, we will use the same event discipline to decide when a machine moves from one operation to the next.