Barcode part life tracking for maintenance: scans and MES runtime

A wear part that fails on the line costs production, and a wear part replaced too early costs money twice. Most shops handle the trade-off with a calendar — swap every three months — because nobody can say how many cycles each part actually saw. You can say it. Scan a barcode on the part at every install and removal, carry the machine counter snapshot inside each scan event, and join those events to the production data your MES already records.

The result is part life in cycles and run hours, a mean time between removals for the fleet, and a replacement trigger that fires when a specific machine reaches its threshold, not when a date arrives. This guide gives you the record layout, the reader choices, the integration paths and the arithmetic, with a worked example you can copy onto your own line.

Replace by the counter, not the calendar

Calendar replacement guesses; counter replacement measures. A part life starts at its install scan and ends at its removal scan, measured in whatever the machine counts: press strokes, weld cycles, spindle hours. The whole system is two scans per life plus one join to the production counters. Everything else exists to keep those numbers honest.

The decision rule: when a machine counter passes a threshold measured from the current part's install scan, schedule that part into the next planned stop. Set the threshold from fleet history, not from a data sheet: 80% of the mean cycles between removals across the fleet. In the worked example below that is a trigger at 332,500 cycles against a fleet mean of 415,700. The 20% margin absorbs the spread between a hard-running press and a gentle one; the counter absorbs the shift patterns a calendar never sees.

The record every scan must carry

A life number is only as good as the weakest field in its two scan records. Write all eight fields with every event:

Two details decide whether the log survives contact with the floor. Encode meaning in the label where you print it: a GS1 serial (application identifier 21) or lot code (10) lets the reader hand over labelled data instead of a bare string, and you keep the raw string too. And treat the station as a verification point: the reader confirms the SKU matches the work order before the part is fitted, which is the pass/fail check station pattern applied to maintenance.

Where the scans happen: station readers and handhelds

Install scans belong where parts are fitted: a load nest, a tool-change station, a service bench at the line. A fixed code reader mounted over the nest reads the part as it is presented, at install and at planned changeovers, and the controller that owns the machine counter stamps the event in the same breath. For a nest where the part lands in a known spot, a compact unit with a 12 mm focal length covers the install scan:

The MV-ID3013PM-12M-WBN exposes Fast Ethernet on an M12 mount with a global shutter, so the event reaches the plant network directly and the PLC attaches its counter values on the spot.

Removals are the opposite problem: they happen wherever the part fails. A technician finds a chipped jaw mid-shift, swaps it at the machine, and the scan still has to reach the log. Handheld code readers keep those events in the same database as the station scans. Near a network drop, a wired handheld that talks Fast Ethernet behaves like the fixed unit above:

Away from any drop — a press at the far end of the hall, outdoor tooling — a wireless ultra-rugged package keeps the log complete:

That ultra-rugged wireless handheld is built for exactly that walk. The one habit to ban is typed entry: a mistyped serial never arrives, and a slow one arrives too late to matter.

Size the reader by pixels per module

Life tracking lives or dies on one physical detail: the reader must decode the label every single time, because a missed install scan silently deletes a life from the history. Size the optics by pixels per module. Direct-marked 2D codes decode reliably from about 5 pixels across each module, and a well-printed label on a flat field can run at 3 as a floor; below that, no software setting rescues the frame.

Worked check. A DataMatrix with 0.375 mm modules sits on a jaw carrier that can land anywhere in a 40 mm window. Modules across the view: 40 / 0.375 = 107. Pixels needed at 5 per module: 107 × 5 = 535. The LS-CRD-0028 reads through a 2560 x 2048 sensor behind an 8 mm lens, rated 60 codes/s at 30 fps over Fast Ethernet. At that 40 mm window the pixel pitch is 40 / 2560 = 0.016 mm, so one 0.375 mm module spans 24 pixels — nearly five times the requirement — and the same reader could cover a 150 mm nest view and still hold 6 pixels per module (150 / 2560 = 0.059 mm per pixel; 0.375 / 0.059 = 6.4). At this code size pixels are not the constraint; focus and contrast are.

Run your own module width and nest size through the calculator before ordering: it converts the two numbers into the pixel count you need and filters the readers that meet it.

Getting install and removal events into the MES

Two integration paths cover every plant.

The strong path routes the event through the controller that owns the counter. The reader decodes over the link you choose — serial, USB and Ethernet all work, and Ethernet wins when the counter lives in a PLC. The PLC appends the scan string and its counter snapshot into one message and posts it upward, so install, removal and life measurement are atomic: nothing to join, nothing to drift. Most MES platforms accept production postings through a defined message interface where you register which messages are valid and watch the queue; ask your MES owner for that interface's message catalog early, because it decides the event format.

The fast path sends reader events straight to an edge application that writes the MES database or API. It ships sooner and needs no PLC work, but the join is then by timestamp: every reader, controller and MES node must sync to one time source, and each event carries its own sequence number, because MES integration layers process event types in a defined order and can hand a removal to the logic before its install arrives.

Which path fits which scanner is the vision, MES or web-scanner path question — settle it before buying hardware. Whichever you run, queue on comms loss instead of dropping: an outage at shift change must cost a delay, not a missing life, which is the queue every scan without drops discipline. The stop-line trigger alarm rides the live path — the scan-to-flag latency work matters there — while the history tolerates minutes of delay.

The worked example: nine removals, one fleet mean

Press 7 reports through the MES: serial J-04812 installed on 2 June 2025 at counter 1,284,600 cycles and 18,940 run hours; removed on 9 October at 1,712,400 cycles and 21,120 hours, reason wear.

Life in cycles: 1,712,400 − 1,284,600 = 427,800.

Life in hours: 21,120 − 18,940 = 2,180 h.

Observed rate: 427,800 / 2,180 ≈ 196 cycles/h. Treat this as a free integrity check — when it sits near the line's known production rate, the counter and the scan log agree.

Nine wear-out removals of that jaw SKU across twelve presses in six months give these lives, in cycles: 427,800, 396,200, 452,100, 388,900, 401,300, 433,600, 419,800, 376,400 and 445,000. The sum is 3,741,100, so the fleet mean is 3,741,100 / 9 ≈ 415,700 cycles, with a band of 376,400 to 452,100 — about 10% either side of the mean, or 1,920 to 2,310 run hours at the observed 196 cycles/h.

Now hold that against the calendar habit. A quarterly swap assumes 13 weeks of production. On a line averaging 196 cycles/h over 80 run hours a week, a quarter is 1,040 × 196 ≈ 203,800 cycles: the part comes off at half its life. On a press running 420 cycles/h, the same quarter is 1,040 × 420 = 436,800 cycles — past the fleet mean, so the calendar invites a failure before the date even arrives. The counter trigger at 0.8 × 415,700 ≈ 332,500 cycles fires at 332,500 / 196 ≈ 1,700 h on the slow line and 332,500 / 280 ≈ 1,190 h on a 280 cycles/h line: the same point in wear, about six weeks apart on the calendar.

Set the trigger, then let the data move it

Start conservative and revise on a schedule. Until a SKU has about nine removals on record, set the trigger at 90% of the shortest life observed — loose on purpose, because one lucky part should not set policy. From nine removals, move to 80% of the fleet mean and re-check the number quarterly.

Three things move it:

• Reason codes. Count only wear-out removals in the mean. A jaw removed because a foreign part jammed the press says nothing about jaw life and drags the mean down.
• Rate spread. If one press runs twice the cycles per hour of its neighbour, its parts age twice as fast. The counter trigger handles that automatically, which is the entire point.
• The second denominator. Seals, wipers and lubricated parts track run hours better than cycles. Keep both snapshots in the record and choose per SKU.

The same timestamps give you part cycle time per workstation at no extra cost, since install and removal events are already stamped at the station.

When counter-based life tracking is the wrong tool

Three cases where the trigger disappoints, and what to do instead.

Random failures. Proximity sensors, solenoid valves and electronics do not accumulate wear with cycles, so no threshold prevents their failures. The log still pays: failures per 1,000 run hours tells you how many spares to hold at the line and which position fails most. Track them; just do not call a trigger prevention.

Damage. A tenth removal that quarter reads 188,000 cycles with the reason damage — a mis-fed part cracked the jaw. No trigger prevents it; the reason code keeps it out of the statistics, and a photo taken at removal keeps the evidence. The image archiving pattern bolts straight onto the removal event.

Parts cheaper than the analysis. If a filter costs little and its failure is benign, a conservative trigger and a fixed swap beat a statistics program. Life tracking earns its keep on parts whose failure stops a line.

A single machine with a single wear part produces two removals a year. Run the bootstrap rule and let the data accumulate; the method works at fleet scale, and it still works, slowly, at one.

Before you order: the check list

1. Smallest code. Measure the module width on the worst label you accept today, not the best, and run the 5-pixels-per-module check above. A tighter field of view or a higher-resolution reader fixes a shortfall — the code-reader finder filters by sensor resolution.
2. Nest geometry. Fix the part's position or widen the window, then confirm the reader's focus distance covers the mounting height you can actually build.
3. Counter ownership. Decide which device owns cycles and run hours, and put the station reader on its network so the snapshot is written in one place.
4. MES write path. Agree with the MES owner which queue or table receives install and removal events, and who registers the message types. That conversation takes a week; hardware takes a day. Start with the conversation.
5. Label survival. Coolant, abrasion and rework kill codes. If the label cannot survive a full life in place, plan re-marking at each removal or fall back to lot code plus an install sequence.
6. One time source. NTP on the readers, the controllers and the MES node, before the first event is written.

Send the module width, the nest window and the counter type through the build-a-system configurator and we will return a reader, a mount and a data path that fit the line. The code-reading topic holds the scanning-side detail, and contact puts you through to the applications team.