Skip to content

Quality

Quality shows how much of what you make is good, and why the rest is rejected.

Rejected units are recorded against a quality reason, so you can break bad production down by cause and by cost. Operators record bad units and their reasons in the Operator Interface, or devices send them.

How it works

Bad units come from one of two sources. You can use both on the same station. Bad units count towards the production count but not towards the good count.

From the Operator Interface

Operators record bad units as they happen, in the Operator Interface's production screen. When an operator records a bad quantity, the Operator Interface offers a quality reason to go with it. The pick is optional and can be skipped. If the operator undoes an entry, the undo is recorded against the same reason. The free-form correction screen records no reason.

From a device

A device sends bad units in the same MQTT message as its other signals: production_complete_bad (or production_count_bad for a cumulative count), with an optional bad_production_reason that gives the quality reason code. See Station signals for the full field list.

How reasons are attributed

  • Bad production recorded without a reason is reported as Unknown.
  • A reason code that is not configured on the account, or has since been removed, is still recorded and is shown as the raw code. An attribution is never lost because configuration was behind.

Only while a schedule runs

Production, good or bad, is only recorded while a production schedule runs. See Scheduling.

Set it up

  1. On the Reasons admin page, create reasons of type Quality, for example "Scratched", "Out of tolerance" or "Wrong colour". You can nest them under parent reasons. Which stations offer each reason follows the same include/exclude cascade as downtime reasons.
  2. For operators to record bad units, turn on Allow Rejecting Production on the Station admin page for each station where they do so. There is no separate setting for quality reasons. Then put the Operator Interface on a screen at the station. See Operator screens.
  3. For devices to send bad units, connect the station with a machine connector and send the bad-production fields described in Station signals.
  4. Make sure a production schedule is running on the station. See Scheduling.
  5. To put a cost on bad units, set a Value on each SKU on the SKU admin page. Without it, Quality cost is zero.

Where you see it

  • Operator Interface: operators record bad units and pick a quality reason for each entry.
  • Cockpit: live OEE for each station, which includes the quality factor.
  • Quality Analysis: bad production grouped by quality reason, with the bad count and its cost for each reason. It is under the Quality menu.
  • Production reports: the Bad Quality view of Production Entries lists each bad entry with its quality reason ("Unknown" where none was given).
  • OEE Analysis: quality as one of the three OEE factors. It has no breakdown by reason: that is on Quality Analysis.
  • Trend Viewer: Quality and Bad/Reject Production Count over time.

Metrics

Quality rate

%

The share of units produced that are good.

good count ÷ (good count + bad count) × 100

  • Notes This is the Quality factor of OEE. When no units were produced in the range, quality rate is 100%. The Trend Viewer plots it as Quality.

Bad count

units

The number of units recorded as bad, by quality reason.

  • Notes A parent reason includes the bad count of all its sub-reasons. Bad units with no reason are counted under Unknown. The Trend Viewer plots the total as Bad/Reject Production Count. Good count is production count minus bad count.

Quality cost

£ (the account currency)

The value of the units recorded as bad.

bad count × the SKU's Value