---
title: "Choose a production tracking algorithm"
description: "The detection algorithm on an operation is the rule that turns a sensor's signal into part counts. BeamTracker takes Counter and nothing else. A SenseAi machine takes Continuous Analysis when the trace never returns to the stopped level, Discrete Analysis when each part is one burst with idle time around it, and Discrete w/o Merge when every impact is a part. Compare all four, validate against a hand count over ten parts, and switch without losing the operations already assigned to a machine."
category: "Set up parts and operations"
source_url: "https://www.iotflows.com/docs/production/choose-an-algorithm/"
---
# 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](/docs/monitoring/metrics-reference/#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](/docs/admin/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](/docs/production/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.

Diagram: Four rows, one per detection algorithm, each drawing the signal the sensor reports and marking every point that becomes a count. Counter, labeled BeamTracker only, is a line that sits high while the beam is clear and dips each time a part passes; each of its five dips is one count. Continuous Analysis is one long unbroken running block divided into six equal time slices, because it divides running time by the cycle time rather than reading the shape of the trace. Discrete Analysis and Discrete w/o Merge are drawn on the same irregular trace of three bursts, where the middle burst carries a short dip in it. Discrete Analysis marks three counts, merging that dip back into one burst. Discrete w/o Merge marks four on the identical trace, because it reads the dip as the end of one cycle and the start of another.

*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](/docs/production/cycle-times-and-filters/) and [Cycle time](/docs/monitoring/metrics-reference/#cycle-time).

## Counter
Counter takes each break of the BeamTracker beam as one cycle, multiplied by the operation's [quantity per cycle](/docs/production/cycle-times-and-filters/). 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](/docs/hardware/calibrate-beamtracker/#beam-values).

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](/docs/hardware/calibrate-beamtracker/#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](/docs/production/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](/docs/monitoring/metrics-reference/#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](/docs/production/cycle-times-and-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](/docs/hardware/calibrate-senseai/#short-stops).

> **Warning:**
> **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](/docs/production/troubleshoot-part-counts/).

## Set the algorithm on an operation
1. Open **Parts List** at `/production?select=parts_list`.
2. Expand the part to show its operations.
3. Click the algorithm pill in the operation's row, or **Select Algorithm** if it has none yet.
4. 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.

1. Let the machine run normally for one to two hours, or one full shift.
2. Open **Shift Production** at `/production?select=part` and read the count for that operation.
3. Compare it with a hand count, the machine's own counter, or the count implied by the runtime and the cycle time.
4. Open **Downtimes** at `/assets?select=downtimes` and check that real stops are there and brief pauses are not filling the list.
5. 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](/docs/hardware/calibrate-senseai/#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](/docs/production/cycle-times-and-filters/).

## See also
- [Configure tracking for CNC mills and lathes](/docs/production/cnc-machines/)
- [Configure tracking for injection molding](/docs/production/injection-molding/)
- [Configure tracking for stamping and punch presses](/docs/production/stamping-presses/)
- [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/)
- [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/)