Choose a production tracking algorithm

Pick the rule that turns a machine's signal into part counts.

A detection algorithm is the rule IoTFlows applies to a sensor's signal to decide that one cycle has finished. Every operation carries exactly one, chosen in the Parts List. It decides the part count and the measured cycle time, which makes it the most common reason a number on the screen disagrees with the number on the floor.

There are four. The device on the machine decides which ones you can pick. The shape of the signal decides which one you should.

Before you start

Sign in as an Organization Owner or Organization Administrator. See Roles reference.
Create the part and at least one operation. The algorithm is a field on the operation, not on the machine. See Create parts and operations.

Choose in one question

Start with the device, because it removes most of the choice.

BeamTracker takes Counter and nothing else: it counts units passing a point rather than deriving counts from a machine's own cycle.
SenseAi and SenseAi Embedded take one of the three analysis algorithms. Counter is not offered for them.

For a SenseAi machine, one question decides it. Does the signal fall back to the stopped level between parts?

No, the machine runs steadily and the trace stays up → Continuous Analysis. For example, an injection molder that holds pressure through the cycle.
Yes, and each part is one burst with quiet either side → Discrete Analysis. For example, a CNC mill that sits idle while the operator unloads and reloads.
Yes, and each part is one sharp impact you want counted on its own → Discrete w/o Merge. For example, a press where every stroke is a part.

When the answer is not obvious, start with Discrete Analysis. It adapts to cycle-time variation instead of assuming a fixed cycle, which makes it the least wrong choice on a machine nobody has measured.

You do not need to revisit this on a machine whose counts already validate. Switching to chase one bad shift replaces a right number with a wrong one.

How each algorithm reads the signal

The four differ in what they treat as the end of a cycle, not in how hard they look.

The four algorithms drawn as the signal each one reads, with the point it counts marked.

Note the bottom two rows. They are the same trace drawn twice, and the counts differ by one.

Discrete Analysis reads the dip in the middle burst as noise inside one cycle and merges it. Discrete w/o Merge reads it as the end of one cycle and the start of the next. That is why a machine that rings twice per part counts double under one and correctly under the other.

Compare the four algorithms

Algorithm	Detects	Best for	Cycle time needed	Typical failure
Counter	Each break of the beam	Any BeamTracker. Counting units as they pass a point	Ideal only, for goals	Parts pass without breaking the beam, so nothing is counted
Continuous Analysis	Running time, divided by the cycle time	Machines that hold a steady, predictable cycle	Measured and accurate. It is the divisor	The entered cycle time drifts from the real one, and the count drifts with it
Discrete Analysis	One cycle per burst, short dips merged back in	Machines with variable cycles and clear idle time between parts	Ideal only, for goals	Two fast parts merge into one burst and the count comes in low
Discrete w/o Merge	Every burst, with nothing merged	Machines whose every impact is one part	Ideal only, for goals	One part rings more than once and the count comes in double or worse

Ideal cycle time is the target you enter on the operation. Where the table says "ideal only, for goals", the algorithm counts without reading it, and the number drives the shift goal and the parts gauge instead. See Set cycle times and downtime filters and Cycle time.

Counter

Counter takes each break of the BeamTracker beam as one cycle, multiplied by the operation's quantity per cycle. There is no pattern analysis and nothing to tune in the algorithm itself.

What it needs is a device that sees the parts, which is a calibration job rather than an algorithm one. See Set what counts as a part.

Short gaps between parts are handled on the device too, by the BeamTracker Downtime Filter, which holds the machine as running when parts pass less than that far apart. See Set the downtime filter.

Counter end to end on a line, from the count point to the validated count, is on Configure tracking for bottling and packaging lines.

Continuous Analysis

Continuous Analysis divides running time by the cycle time. It never looks at the shape of the trace, which is what makes it right for a machine that never returns to the stopped level and wrong for one that does.

The cycle time you enter is the divisor, not a target, so its accuracy is the accuracy of the count. Measure it over 10 to 20 cycles rather than taking it off a quote or a router.

This is the only algorithm that shows a Downtime Filter percentage on the operation row. The filter converts any stop shorter than that percentage of the cycle time into uptime, so brief in-cycle pauses stop reading as downtime. The field accepts 0 to 200% and clamps anything higher; set it on Set cycle times and downtime filters.

Discrete Analysis

Discrete Analysis detects individual cycles from the vibration pattern and merges short pauses back into the cycle they interrupted. It counts the events it detects rather than dividing by a number, so it tolerates parts that take 1:50 and parts that take 2:10 on the same machine.

Enter a cycle time anyway. The algorithm does not read it to count, but the shift goal and the parts gauge do.

Discrete w/o Merge

Discrete w/o Merge counts every burst it detects and merges nothing. It is for a machine whose events are the parts, where merging would combine two strokes into one.

Because nothing is merged, short stops between strokes reach the downtime record as hundreds of one-minute rows unless the machine absorbs them first. Set Downtime Threshold with Treat short downtimes as uptime switched on, so stops under the cutoff become runtime. See Handle short stops.

Counting twice as many parts as you make? On this algorithm that is one part ringing more than once, not a sensor fault. Move to Discrete Analysis, which merges the second ring back into the cycle. See Troubleshoot inaccurate part counts.

Set the algorithm on an operation

Open Parts List at /production?select=parts_list.
Expand the part to show its operations.
Click the algorithm pill in the operation's row, or Select Algorithm if it has none yet.
Hover an option to read what it detects, then click it.

The change saves as soon as you pick it. There is no separate save.

Validate your choice

Validate against a hand count, never against a total that looks about right.

Let the machine run normally for one to two hours, or one full shift.
Open Shift Production at /production?select=part and read the count for that operation.
Compare it with a hand count, the machine's own counter, or the count implied by the runtime and the cycle time.
Open Downtimes at /assets?select=downtimes and check that real stops are there and brief pauses are not filling the list.
Calculate accuracy as the IoTFlows count divided by the actual count, times 100.

Read the result against these bands:

Accuracy	Verdict	What to do
95 to 105%	Good	Nothing
90 to 95%, or 105 to 110%	Acceptable	Tune the cycle time or the downtime filter
Below 90%, or above 110%	Wrong	The algorithm is a misfit, or the cycle time is badly off

Validate with ten parts, not one shift. A count that is right ten times in a row is right. A shift total that happens to land near the truth is a coincidence you pay for later.

Switch to a different algorithm

Switch when the count fails validation the same way repeatedly, not after one bad day.

Symptom	Move from	Move to
Count runs 10 to 20% high, and real cycle times vary by more than 20%	Continuous Analysis	Discrete Analysis
Count runs low on a machine that runs very consistently	Discrete Analysis	Continuous Analysis
Strokes are missed on a machine firing events close together	Discrete Analysis	Discrete w/o Merge
Count is two or three times the real output	Discrete w/o Merge	Continuous Analysis

Changing the algorithm can collide with machines that already run other operations on that part. When it does, a Confirm Algorithm Change dialog lists every machine affected and explains the conflict. Confirming removes those other operations from the machines listed, so read the list before you click Confirm.

Revalidate after every switch. The counts either side of the change come from different rules, so they are not comparable.

Common mistakes

Continuous Analysis on a machine with variable cycles. Parts take 30, 45 and 60 seconds and the operation is set to the 45-second average. Short cycles are overcounted and long ones undercounted, so the total is wrong even though the average is right. Use Discrete Analysis.

Discrete w/o Merge with no short-stop handling. Every gap between strokes lands in the downtime record, and the report fills with one-minute stops nobody can classify. Set the machine's short-stop cutoff first, in Handle short stops.

Trusting a configuration nobody checked. The count looks plausible for weeks, and by the time someone compares it with a hand count the history is already wrong.

Quantity per cycle left at 1 on a multi-cavity mold. A four-cavity mold set to 1 reports a quarter of its real output, and no algorithm change fixes it. Set quantity per cycle to the parts the machine makes per cycle, in Set cycle times and downtime filters.