Print the barcode on the first page only, stop double scans

A report that wraps to three pages re-prints its page-level bands on every sheet, so one work order leaves the printer carrying three identical barcodes — and an operator who scans page one and later scans page three enters the same record twice. The usual defence, comparing each scan with the previous one, leaks: it only catches back-to-back repeats. This guide fixes the problem at both ends. You will move the symbol into a band that renders once per report, size it so it scans from a header, set a 5-second duplicate window on the reader, and prove the result with one three-page test print.

Why does the barcode print on every page of my report?

Because the barcode sits in a band the report engine re-renders for every page: a page header, a page footer, or a table header row that repeats when the table wraps. A parent table wrapping five peer tables to three pages re-prints anything in those bands three times.

Report engines lay content out in bands, and every band has a scope. Page headers and page footers have page scope — the engine stamps them on every sheet. A table header row belongs to its table, and when the table spills onto a second page the header row follows it, because re-printing the header on each wrapped page is the default behaviour. A detail row renders once per record. Your barcode inherits the scope of the band that holds it; the data never changes, only the count of symbols.

Spreadsheet printing uses the same mechanism on purpose, repeating a title row at the top of every printed page. In a multi-page report whose pages all describe one work order, that repeat is the defect: three pages, three scannable codes, three identical strings for the tracker to absorb.

Where do I put the barcode so it prints only once?

Move it into a band that renders once per report: the report header above the first table, or the report footer after the last one. Those two bands fire a single time no matter how many pages the tables generate.

1. Open the report layout, click the barcode and note which band owns it — page header, page footer, or a table band.
2. Cut it from that band.
3. Paste it into the report header band, above the parent table. It renders once, at the top of page one.
4. If the sheet needs the code low on the page, paste it into the report footer band instead. It renders once, after the last peer table, on the last page.
5. Leave no copy in a peer table header row unless that table's header-repeat behaviour is off and the table cannot wrap.
6. Print the longest data set you have and count the symbols: exactly one.

In the layout that produces this defect — a parent table with five peer tables — the header row of peer table 1 is the tempting slot, because it sits at the top of page one. It survives only while peer table 1 fits on a single page. The week that table wraps, its header row lands on page two with it and the doubles return. The report header has no such dependency: it renders before any table is laid out.

Where the sheet parks in a fixture rather than an operator's hand, the LS-CRD-0047 with its 60-120 mm reading distance mounts on a bracket over the header position.

Can I keep the barcode at the bottom of page one?

No band can promise that when the peer tables wrap dynamically, because page breaks are decided while the report renders, after the layout is fixed. Nothing at design time knows which peer table summary will end page one. Commit to one of two deterministic positions instead.

The report header puts the code at the top of page one, read as the sheet feeds. The report footer puts it after the last peer table on the last page, read after review — and on a one-page report the two positions coincide. Chasing the bottom of page one against today's data means the symbol walks every time a row count changes, which is how the defect returns a month after the fix.

Decision: feed-and-scan stations take the report header; review-then-scan desks take the report footer.

How big does the printed barcode need to be?

Plan on a 0.33 mm module (narrow bar) and a symbol about 55 mm wide for a 10-character Code 128 ID — that fits any page header and reads at hand-scan distance. The sizing arithmetic:

Code 128 gives every data character 11 modules, the mandatory check character 11, and the stop pattern 13. For a 10-character work order at a 0.33 mm module:

• modules = 11 × (10 + 2) + 13 = 145
• bars = 145 × 0.33 mm = 47.9 mm
• quiet zones = 2 × 10 × 0.33 mm = 6.6 mm
• total = 47.9 + 6.6 = 54.5 mm

A header about 190 mm wide holds that block beside the title text. A 0.25 mm module brings the total nearer 41 mm but leaves less margin on photocopies; 0.33 mm is the default that survives the copier. The quiet zone on each side is 10 module widths, the symbology's stated minimum.

For the paper, resolution and contrast side, read barcode module width for document scanning; for how far away and at what angle the reader copes, Code 128 barcode module size, reading angle and reader distance. If you generate the symbol from your own program in the simpler symbology, print a readable Code 39 barcode from your own program covers its sizing rules.

Why did my equal-to-last-scan check still let doubles through?

Because comparing the current scan to the previous scan only catches back-to-back repeats: any different code scanned between the two copies of the same sheet resets the comparison, and a cleared or half-updated buffer hides the second read. Four failure paths cover nearly every leak:

1. Adjacent-pair logic. The operator scans sheet A page one, a different document, then sheet A page three. The middle scan overwrites the stored last value, and the third scan passes as new — the A-B-A pattern defeats equality with the previous value.
2. A polled buffer. Two reads landing inside one controller scan overwrite each other, so the comparison runs once and never sees a pair. Latch the read as an event instead — stop duplicate barcode scans in a batch table: event over polling shows the pattern.
3. A cleared register. A screen change, a timer or a shift routine empties the stored last scan, and the rescan compares against nothing.
4. Two listeners. Two screens or fields consuming one scanner can rewrite the read before the compare runs; two barcode listeners on one screen fixes the routing.

The replacement rule compares string plus elapsed time, so interleaved codes cannot reset it:

// Illustrative names and IEC 61131-3 types; initial values shown.
scanCode : STRING := '';     // code delivered by the reader event
newRead  : BOOL   := FALSE;  // set by the event, cleared below
lastCode : STRING := '';     // last accepted code
lastMS   : UDINT  := 0;      // timestamp of last accepted read, ms
dupCount : UDINT  := 0;      // suppressed duplicates
DUP_MS   : UDINT  := 5000;   // duplicate window: 5000 ms = 5 s
nowMS    : UDINT  := 0;      // controller millisecond clock

IF newRead THEN
    IF (scanCode = lastCode) AND ((nowMS - lastMS) < DUP_MS) THEN
        dupCount := dupCount + 1;   // same string inside 5 s: same sheet
    ELSE
        lastCode := scanCode;
        lastMS   := nowMS;
        // forward scanCode to the record write here
    END_IF;
    newRead := FALSE;
END_IF;

Test it with numbers: a read of WO-4471 at nowMS = 86,524,300 is accepted and stored. The operator turns two pages and rescans at nowMS = 86,528,600: 86,528,600 − 86,524,300 = 4,300 ms, which is under the 5,000 ms window, so the read is counted and discarded. A different order scanned between the two changes nothing, because the comparison is against lastCode and the clock, not against the immediately previous scan.

If the record write hangs off a tag-change event in the SCADA, an identical value never fires it — and forcing it to fire reintroduces the double you are blocking. Forcing OPC UA tag change events on duplicate barcode scans walks through that trade-off.

Most industrial readers ship the same rule built in as a duplicate-code filter; report unique barcodes only: set the duplicate window shows where the setting sits and what it does to the data reaching your host.

How long should the duplicate window be on the reader?

Start at 5 seconds: long enough to swallow a page-flip rescan of the same sheet — an operator turning a page and re-aiming needs 2-4 s — and short enough that a legitimate second record minutes later still goes through.

1. Open the reader's configuration, its setup tool or the programming barcodes printed in its manual, and enable the duplicate-code filter.
2. Set the window to 5 s.
3. Scan one sheet twice, two seconds apart: the host must receive exactly one string.
4. Wait six seconds and scan again: the string must arrive.
5. Read the production log for the doubles that got through before the fix. If their spacing exceeds 5 s, raise the window above the largest spacing you find, with 10 s as the practical ceiling for hand scanning — beyond that you start eating deliberate reprints of the same order.

Worked timing: first read at 14:32:07.2, rescan at 14:32:11.6. The difference is 4.4 s, inside the 5 s window, so the reader suppresses the second output and the host sees one record. The same order scanned again at 14:41:00 is 528.4 s later and passes.

At the desk, handheld code readers do the scanning: the wired LS-HCR-0001 (1.0 MP over USB 2.0) or the wireless 1.0 MP LS-HCR-0002 cover the desk and the aisle.

Keep the aiming beam on the paper and off faces. When a smart cameras station reads the header on every trigger, the camera does not dedupe for you: apply the same string-plus-timestamp rule in the result handler, since the camera reports one read per trigger. If the host routine should stop after the first good read, read a code once: stop after the first good read covers that side.

How do I verify the fix before releasing the report?

Print a three-page test report, count the symbols — you must find exactly one — then scan the first page, turn to page three and scan again: the reader reports one code, and the duplicate log shows the second read suppressed.

• Print the longest real data set, the one that wraps to three pages, and count symbols: one, on the page you chose.
• Scan page one, turn to page three, scan again: one record in the system, one increment in the reader's duplicate counter.
• Scan sheet A, then sheet B, then page three of sheet A: two records, not three.
• Add rows until peer table 1 wraps: the symbol must not reappear on page two.
• Photocopy the print and scan the copy: the 0.33 mm module still reads.

With one symbol and one window, the doubles are gone at the source and caught at the reader. For a new station, the code reader finder narrows models by interface and resolution, fixed code readers covers fixture-mounted reading, and if the station must grade the print as well as decode it, date code print quality inspection is the next read. Send a sample report through the contact page to have the layout checked before rollout.