Report unique barcodes only: set the duplicate window

A fixed code reader in presentation mode reads the same label again and again. The first report is the one your PLC wants; the repeats that arrive every default timeout — often 10 s or less — flood the log, double-count parts in the MES and create duplicate rows downstream. The fix is one timing setting, named a double-read timeout, decode session timeout or delay mode depending on the reader. Size it to the longest time a code sits in view and the reader reports each unique barcode only once, while still firing instantly on anything new. This guide gives you the sizing rule with the arithmetic, the steps to set and persist the value, the commissioning tests that prove it, and the case where suppression is the wrong tool.

How do you report a barcode only once in presentation mode?

Set the duplicate-report window — the double-read timeout, decode session timeout or delay mode setting in your reader's configuration tool — longer than the longest time one code stays in view; for a parked part that means 30-120 s, not the 1-10 s defaults readers commonly ship with.

The mechanism is simple. The reader reports the first decode of a content string immediately, then holds back that same string until the window expires. Defaults differ by model: 1 s, 5 s and 9.9 s are all shipped as factory values, and none of them assumes a part parked in front of the lens for a minute. Every window that expires while the label is still in view produces another report, another PLC message and another row in the log. Raise the window to cover the whole dwell and five reports become one, with nothing else in the configuration changed.

Why does a presentation reader keep sending the same code?

Presentation mode is free-run decoding: the reader attempts a read on every frame and reports each decode whose content it has not reported within the duplicate window, so a label parked in view re-fires every time the window runs out.

Nothing about this is a fault. Presentation mode holds the illumination on and decodes continuously because handheld-style workflows need it: drop a code in front, hear the beep, pull it away. A fixed-mount integration inherits the same behavior. The reporting chain runs decode, content-key check, report, repeated at the decoder rate — tens of decodes per second on a modern reader. The window is the only stage in that chain you can stretch from the configuration tool.

Two other timers sit nearby and cause most of the confusion. An idle dim timer drops the illumination to a low state after roughly 5 s without a read on some models; it saves power and changes nothing about which decodes get reported. Exposure and gain settings do not gate reports at all, so they are the wrong knob when the symptom is repetition.

How long should the duplicate-report window be?

Measure the longest dwell — the time one code can sit continuously in view — and set the window to 1.3-1.5 times that value: a 45 s verification park calls for a 60 s window.

Here t_dwell is the longest continuous presentation of one code, in seconds, and t_gap is the shortest time between two legitimate appearances of identical code content. The second line is the guard rail that matters on shared lines: it keeps you from suppressing a real second part.

One assumption sits under the arithmetic: the reader decodes reliably through the whole park. If glare drops the decode rate mid-park, the repeats stop but so do the good reads, and that is an illumination problem — the 1D barcode preprocessing for rotation, blur and glare guide treats the image side of it.

How do you set the window on a fixed code reader, step by step?

Open the reader's configuration utility, find the timing setting in the reading or trigger group, enter the window from your dwell measurement and commit it to non-volatile memory so it survives power cycles — minutes of work once the dwell is known.

1. Time the dwell. Watch ten real parks at the station and take the longest, not the average — the window must cover the worst case.
2. Connect the configuration tool over Ethernet or USB and read the current parameter set back before changing anything; the first-connection and readback routine in the fixed code reader setup over USB guide is the pattern.
3. Locate the setting in the reading, decoding or trigger group of the tool. Names in use across the industry include Double Read Timeout, Decode Session Timeout and Delay Mode; note the unit, which is milliseconds on most readers.
4. Enter the value from your measurement: a 60 s window is 60000 ms, a 120 s window is 120000 ms. If the tool caps the field, take the cap only when it still exceeds 1.3 times the dwell.
5. Leave first-read reporting enabled. The window gates repeats of known content; it must never gate the first report.
6. Commit the value to the non-volatile user set so it loads on power-up, then export a backup for the station file; the settings across power cycles guide and the configuration backup before troubleshooting guide show both halves.
7. Run the acceptance tests below before the station returns to production.

What happens when an identical code arrives during the window?

Suppression keys on the decoded content, so a new part wearing a different serial reports instantly, while a second part carrying identical content inside the window stays silent — the failure mode that rules the technique out wherever identical labels repeat.

That trade is exactly right at a verification bench, where every part carries a unique serial. It is wrong on a conveyor of same-SKU cartons: with one carton every 3 s and a 60 s window, twenty cartons share one window and nineteen go unreported. Where identical content can arrive faster than the window, arm a fresh decode per part instead — the fixed barcode reader trigger modes guide covers sensor, serial and free-run arming, and the configurator's trigger step walks the wiring. The window can then stay short or be turned off.

Software has a role too. If reads flow straight into a database and duplicate rows are the pain you are solving, deduplication belongs in the schema: the guide on handling duplicate key violations in Ignition SQL shows the composite-index pattern.

Which reader suits a parked-part verification station?

Any fixed reader with free-run presentation behavior and a configurable duplicate window does this job; choose on field of view, code size and interface, then apply the same window sizing to whichever model you pick from the fixed code readers range.

For a bench where the operator parks a tray under the optics, the LS-CRD-0028 decodes up to 60 codes/s at 30 fps, and its 8 mm lens covers a compact overhead field from the 2560 x 2048 sensor.

At close range, the LS-CRD-0047 covers a 60-120 mm reading distance and connects over USB 2.0, which suits a single bench-top station.

For small codes or a wider overhead field, the MV-ID5120RM-08M-RBN resolves 12 MP over GigE; the MV-ID3013PM-12M-WBN pairs a 12 mm focal length with a 1.3 MP sensor on Fast Ethernet for a tighter field.

Dark cells and shrink-wrap glare are lighting problems, not timeout problems; lens covers and add-on light boards for these readers sit in the code reader accessories category, and the code reader finder filters all of them by interface, resolution and mount.

What do you check before going live?

Prove the window with three presentations and one power cycle: a long park, a new code straight after and an identical label inside the window — the reader must pass all three before the station runs.

• Park one label for 1.5 times the measured dwell — about 68 s against the 45 s example — and count PLC messages: exactly one.
• Present a different code within 2 s of the first; it must report within a decode cycle. If it does not, your reader keys the window on position as well as content, and the tests need one fixed parking spot.
• Present a second label with identical content inside the window and confirm it stays silent — the accepted trade, not a fault.
• Power the reader down for 10 s, repeat the long park and confirm the count is still one; if repeats return, the value never reached the startup user set.
• Instrument the reporting path once and note scan-to-message latency, so you know the first report reaches the PLC in time for the process; the scan-to-flag response time guide shows the timing chain to measure.
• Grade decodes before they drive a downstream decision; the read confidence guide explains the check.

Set the window from the measured dwell, commit it to the user set and run the three-presentation test — that is the whole job. To choose the reader itself, start at the fixed code readers category, or work through the code-reading guides hub for the neighboring decoding fixes; expert support comes with every order.