---
title: "Troubleshoot inaccurate part counts"
description: "Symptom, cause and fix for a part count that does not match the floor. Check QTY/OP in the Parts List first, because an exact 2x or 0.5x error is a multiplier rather than a detector: one cycle producing two parts, or two cycles producing one. A count that drifts over a shift is the ideal cycle time on Continuous Analysis, which divides running time by it. Also covers a count of zero, BeamTracker counting things that are not parts, counts that stop when the sensor goes offline, and why the platform's gross count and an ERP's good-parts figure are not the same number."
category: "Reference"
source_url: "https://www.iotflows.com/docs/production/troubleshoot-part-counts/"
---
# Troubleshoot inaccurate part counts

Symptom, cause and fix for a count that does not match the floor.

A part count is built from three things in a fixed order: the sensor's signal, the detection algorithm that decides where one cycle ends, and the quantity per cycle that turns cycles into parts. A wrong count is a fault in one of them, and the shape of the error tells you which.

Every metric named on this page is defined in [How each metric is calculated](/docs/monitoring/metrics-reference/).

## Start here: three checks
Diagram: A decision tree headed My part count does not match the floor, branching into three symptoms, each with the field to check first and the cause to check after it. Branch 1, the count reads too high, more parts than the floor made: check QTY/OP first, because exactly two or three times the real number means the field multiplies every count by what it holds; then check the algorithm, where one part ringing twice is counted twice on Discrete w/o Merge. Branch 2, the count reads too low, fewer parts than the floor made: check QTY/OP first, because exactly half or a quarter means a four-cavity mold is left at 1 and reports a quarter of its output; then check the detector, where two cycles merge into one or parts cross outside the beam. Branch 3, the count drifts over a shift, right at first and wrong by the end: check the ideal cycle time first, because there is no clean ratio and Continuous Analysis divides running time by that figure, so an error compounds; then check the downtime filter, where a value set too low turns in-cycle pauses into stops and drops the cycles inside them. A note across the bottom reads: check QTY/OP before the algorithm. An exact 2x or 0.5x error is almost never the detector; it is one cycle producing two parts, or two cycles producing one.

*Count too high, too low, or drifting: three branches, starting with quantity per cycle.*

**Check quantity per cycle before you change the algorithm.** An exact 2× or 0.5× error is almost never the detector. It is one cycle producing two parts, or two cycles producing one, and no algorithm change corrects a multiplier.

Work these three before you read a symptom below.

1. **Compare like with like.** Read the count on **Shift Production** at `/production?select=part` for the same operation, machine and shift the floor counted. Most reports of a wrong number are two people reading two different windows.
2. **Read QTY/OP** on the operation's row in the **Parts List** at `/production?select=parts_list`, then divide the platform's count by the floor's. Exactly 2, 4, 0.5 or 0.25 is this field. See [Set quantity per cycle](/docs/production/cycle-times-and-filters/#qty).
3. **Read the machine's status bar** across that window. Gray is time the sensor said nothing, and nothing was counted in it. Red is time it reported the machine stopped. See [The header](/docs/monitoring/asset-detail/#header).

Then jump to your symptom.

| Symptom | Likely cause | Check | Fix | Page |
|---|---|---|---|---|
| Count is a clean multiple of the truth | QTY/OP higher than the cycle yields | **QTY/OP** on the operation row | Set it to the parts one cycle makes | [Count is roughly double](#double) |
| Count is a clean fraction of the truth | QTY/OP left at `1` on a multi-part cycle | **QTY/OP** on the operation row | Set it to the parts one cycle makes | [Count is roughly half](#half) |
| Right early in the shift, wrong by the end | Ideal cycle time off, on Continuous Analysis | The measured cycle against the ideal | Re-time over 10 to 20 cycles | [Count drifts](#drift) |
| No count at all | No operation assigned to the machine | The operation block on the machine's row | Assign one | [Count is zero](#zero) |
| BeamTracker counts more than passed | Something that is not a part crossing the zone | **Depth of View** and **Gap from Background** | Pull the zone off the background | [BeamTracker extras](#beamtracker) |
| Counting stops partway through a shift | The sensor went offline | Gray on the status bar, then the device | Get it online, then backfill | [Counts stop mid-shift](#stops) |
| IoTFlows and the ERP disagree | The two count different things | Whether the ERP figure is good parts only | Compare gross against gross | [ERP mismatch](#erp) |
| A change will not save | The request failed, nothing was written | Reopen the cell and read the value back | Retype it once | [Still stuck](#stuck) |

**You do not need to change anything on a count within a few percent.** Accuracy of 95 to 105% against a hand count is a working configuration, and chasing the last two points replaces a right number with a wrong one. The bands are on [Validate your choice](/docs/production/choose-an-algorithm/#validate).

## Count is roughly double
Divide the platform's count by the real count, and read the answer rather than the difference.

1. **Exactly 2.00, 3.00 or 4.00.** This is **QTY/OP**, which multiplies every count by what it holds. An operation whose cycle makes one part reports double at `2`. See [Set quantity per cycle](/docs/production/cycle-times-and-filters/#qty).
2. **Near 2× but not exact, on Discrete w/o Merge.** One part is ringing more than once, and that algorithm merges nothing, so each ring is a cycle. Move to Discrete Analysis, which merges the second ring back in. See [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete).
3. **High by a varying amount, on Continuous Analysis.** The ideal cycle time is the divisor there, so a cycle entered shorter than the real one manufactures parts. A molder timed at `11.0` seconds that really runs 22 reports twice its output. See [Set the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal).
4. **High, with the machine reading as running while it sits idle.** The stopping threshold is below the idle band, so standby vibration is counted as production. Raise it. See [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds).

An operation that overcounts on one machine and is correct on the others running it is a calibration problem on that machine, not an operation problem.

## Count is roughly half
The same division, in the other direction.

1. **Exactly 0.5, 0.33 or 0.25.** **QTY/OP** is left at `1` on a cycle that yields more than one part. A four-cavity mold at `1` reports a quarter of its output, and no algorithm change recovers the rest. See [Set quantity per cycle](/docs/production/cycle-times-and-filters/#qty).
2. **Low by a varying amount, on Discrete Analysis.** Two fast parts are landing inside one burst and merging into a single cycle. Move to Discrete w/o Merge, then set the machine's short-stop cutoff, because nothing absorbs the gaps between strokes there. See [Discrete w/o Merge](/docs/production/choose-an-algorithm/#no-merge) and [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops).
3. **Low on Continuous Analysis.** The entered cycle time is longer than the real one, so each real cycle is credited as a fraction of one. Re-time it.
4. **Low, with short green runs missing from the status bar.** The **Uptime Filter** drops any run shorter than its value, so a machine whose cycle is shorter than the filter loses those cycles. Lower it. See [Filter out short uptimes](/docs/hardware/calibrate-senseai/#uptime-filter).
5. **Low on a BeamTracker.** Parts are crossing outside the detection zone or under the thickness floor. **Min Object Thickness** is a floor, not a ceiling: set it to the thinnest part you must count, because a floor above that drops small parts silently. A transparent or highly reflective part can pass without registering at all. See [Set what counts as a part](/docs/hardware/calibrate-beamtracker/#beam-values).

## Count drifts over a shift
Drift has its own signature: right in the first hour, wrong by the end, and the error grows with running time rather than holding a clean ratio.

That points at **Continuous Analysis**, the only algorithm that reads the ideal cycle time to produce a count. It divides running time by that figure, so every minute the machine runs compounds the error. A press entered at 21 seconds against a real 22-second cycle runs about 5% high, which is invisible in ten minutes and half an hour of phantom production across a week.

1. Open the machine's row on the **Assets** page and read the **Cycle time** beside the operation. That figure is measured from detection events, not from anything you typed. See [Review the detected cycle time](/docs/production/auto-detect-operations/#cycle-time).
2. Compare it against the ideal on the operation. A gap of more than a few percent is your drift.
3. Re-time the cycle over 10 to 20 consecutive cycles on a good day, and enter that. See [Set the ideal cycle time](/docs/production/cycle-times-and-filters/#ideal).
4. Read the **Downtime Filter** on the same row. Set too low, brief in-cycle pauses are recorded as downtime, running time shrinks, and the cycles inside those pauses are never counted. Set too high, real stops become running time and the count rises. See [Set the continuous downtime filter](/docs/production/cycle-times-and-filters/#filter).

Drift that survives all four is usually the machine. Tool wear, a worn mold and a heater struggling to hold temperature all lengthen the real cycle, and the platform is reporting that correctly. Watch the measured cycle time for a week before moving the ideal to meet it, see [Cycle time](/docs/monitoring/metrics-reference/#cycle-time).

> **Info:**
> **Is it drift or a step change?** Drift widens with running time. A count that was right until Tuesday and has been wrong by the same margin since is a change somebody made: an algorithm switch, a new QTY/OP, or a recalibration. Check the operation's settings before you re-time anything.

## Count is zero
Nothing counted at all is a different problem from a count that is wrong. Work these in order, because each is cheaper to check than the next.

1. **The window.** Shift Production reads the shift and date you selected, not the current moment, and says **There are no parts in production for this shift.** when that window holds nothing.
2. **The operation assignment.** Counts are recorded against an operation assigned to that machine. Open **Assets** at `/assets` in list view: a machine with nothing assigned carries a **Set operation** button where the part and count would be. See [Start from the Assets page](/docs/production/auto-detect-operations/#from-card).
3. **The algorithm.** An operation with none shows **Select Algorithm** in the Parts List instead of an algorithm pill, and detects nothing until one is picked. See [Set the algorithm on an operation](/docs/production/choose-an-algorithm/#set).
4. **The device.** A status bar gray for the whole window means the sensor reported nothing, so there was no signal to count. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/).
5. **The machine's state.** A status bar red for the whole window means the sensor was reporting, and reporting stopped. If the machine was running, the running threshold sits above the vibration it produces. See [Set the running and stopping thresholds](/docs/hardware/calibrate-senseai/#thresholds).

## BeamTracker counts extra parts
BeamTracker counts units passing a point, so an extra count is something other than a part crossing the detection zone, or one part crossing it twice.

| Cause | How to tell | Fix |
|---|---|---|
| The zone reaches past the background | Counts arrive while the line is idle | Reduce **Depth of View** until the background sits outside the zone |
| Nothing separates the zone from the background | Counts come in bursts, with dust or vibration on the line | Raise **Gap from Background** to leave spare room |
| A part registers twice | The count runs near double at high line speed | Choose a slower **Reading Speed**, so readings are averaged more heavily |
| The bracket vibrates | Extra counts rise and fall with the machine running | Remount the device so the beam holds still across the part flow |
| The thickness floor is too low | A shallow feature on the part counts as a second part | Raise **Min Object Thickness** toward the thinnest part you must count |

All five fields are on the device's **Calibration** tab, and the fastest way to set them is to watch a real part cross the thresholds in the live view. See [Run a live beam calibration](/docs/hardware/calibrate-beamtracker/#live) and [BeamTracker calibration fields](/docs/hardware/calibration-settings/#beamtracker-fields). If saving reports **Detection distance plus thickness must be between 6 and 800 cm**, those two values together have left the range the device holds; reduce whichever you set last.

**Fix the counts before you touch the downtime filter.** The beam values decide what is counted, while the filter only decides how long a gap between parts may run before the line reads as stopped. Counts right but uptime wrong is the filter's problem. See [Set the downtime filter](/docs/hardware/calibrate-beamtracker/#downtime-filter).

## Counts stop mid-shift
A count that runs correctly and then stops is usually the link to the sensor rather than the sensor's judgment.

1. Read the machine's status bar across the shift. A gray stretch beginning where the counts stopped is a device that went silent, and gray is not stopped time: nothing was recorded for it in either direction. See [Not sure whether the machine or the link is down?](/docs/hardware/troubleshoot-offline-device/#stopped-or-offline).
2. Get the device back online. Power, Wi-Fi range and a router moved since installation cover most cases. See [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/).
3. Expect nothing to arrive late. Parts made during the gap are not counted when the device reconnects, so the shift total stays short unless somebody enters them.
4. If you know the true number, backfill it. On the machine's **Operation(s) Production** card, click **Modify Counts**, set the session time to the gap, and enter the parts made. See [Production counts and backfilling](/docs/monitoring/asset-detail/#backfill).

Two other causes flatten the same line. The operation was switched mid-shift, so later parts are counted against the new operation rather than the one you are reading. Or the page has not been reloaded, because Shift Production has no refresh timer, see [Put the board on a TV](/docs/production/shift-production/#tv).

**Backfill only when you know the true number and why the sensor missed it.** A backfilled count changes uptime, performance and FPY for that window permanently, and nothing on any report marks it as manual.

## Counts do not match the ERP
Start by establishing that the two systems are counting the same thing. They usually are not.

| Difference | Why |
|---|---|
| IoTFlows counts cycles, not good parts | The count is detected cycles multiplied by QTY/OP, so it is gross output, including anything the floor later rejected |
| Logged scrap is not deducted | Scrap logged against a job is recorded beside the good count, and nothing subtracts it. See [Where scrap appears](/docs/production/log-scrap/#where) |
| The ERP records a declaration, IoTFlows records an event | A part counted at 11:58 and declared at end of shift lands in two different hours, sometimes two different days |
| Setup and test pieces are counted | The sensor cannot tell a qualification piece from a production piece. The ERP usually never sees it |
| The windows are not the same | The ERP's day is a plant calendar; the platform's is the organization timezone and shift schedule. See [Shift boundaries look wrong](/docs/monitoring/troubleshoot-monitoring/#shift-boundaries) |

Compare gross against gross, for one shift, on one machine, on one operation. If the platform's count matches the ERP's declared quantity plus its scrap and its setup pieces, both systems are right and there is nothing to fix. If a gap survives that, work it as a count problem: divide one figure by the other and follow the branch it lands in.

**Do not reconcile to the part.** A machine-derived count and a hand declaration will never agree exactly, and a configuration tuned until they do is tuned to somebody's paperwork rather than to the machine.

## Still stuck
**Something went wrong** and **An error occurred** are the platform's generic failures. Either means the request did not complete and nothing was saved, so the field still holds its old value however the form looks. Retype the value once, then reopen the row and read it back before assuming the change took.

Two symptoms belong elsewhere. Uptime, downtime or OEE that looks wrong while the counts are fine is on [Troubleshoot wrong utilization or OEE](/docs/monitoring/troubleshoot-monitoring/). A device that is silent rather than miscounting is on [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/).

Otherwise, [contact support](/docs/get-started/get-support/) with the machine, the operation, the exact window, the count you expected and the count you saw. Send the ratio between the two as well: it is the one fact that decides which section above applies.

## See also
- [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/)
- [Set cycle times and downtime filters](/docs/production/cycle-times-and-filters/)
- [Calibrate BeamTracker](/docs/hardware/calibrate-beamtracker/)
- [Troubleshoot a device that is offline](/docs/hardware/troubleshoot-offline-device/)
- [How each metric is calculated](/docs/monitoring/metrics-reference/)