A barcode can be decoded twice because the operator held the trigger, because a continuous-reading mode remained active, because the output path delivered the event twice, or because the application retried a transaction. Those causes need different controls. A scanner timeout can reduce rapid repeat decodes, but it cannot decide whether two scans represent one accidental action or two legitimate business events.
This guide uses an editorial warehouse example. It does not claim that an AIDC GO model exposes a particular continuous-read mode, timeout, deduplication API or transaction feature. Confirm the scanner engine, capture service, application version and exact workflow before applying any setting.
Define what a repeat means in the workflow
Start with the business event. Scanning the same tote twice at one checkpoint may be an error. Scanning two separate units that carry the same product code may be intentional. Scanning a serialised asset twice may require a warning, while scanning a location code before each item may be the approved sequence.
Write the accepted sequence as values and events: which identifier is scanned, which record is open, when the event becomes committed, and whether the same value can be valid again. The quantity-entry guide explains why an item identifier and a quantity decision belong to one transaction. This article focuses on repeated decode events before and after that decision.
Locate the layer that produced the second event
Capture a timestamped trace at the scanner or capture-service output, the application input handler and the stored transaction. One physical trigger action that produces two capture events is different from one captured event that the application submits twice. A database with two records does not identify which layer duplicated the action.
Zebra's DataWedge 15.0 Barcode Input guide documents Same Symbol Timeout and Different Symbol Timeout for Continuous Read, and states that a value of zero requires no interval between successive reads. Its separate Intent Output guide shows that the delivered scan data and the receiving application's handling are distinct parts of the path. Those controls are specific to the documented Zebra environment and mode. They do not establish the controls available on another scanner or an AIDC GO device.
Use the scan-feedback guide to separate a decode indication from application acceptance. A second beep, a second input event and a second committed transaction are three different observations.
Treat scanner timeouts as capture controls
A same-symbol timeout can suppress another decode of the same symbol within its configured interval when the documented mode applies. A different-symbol timeout can delay another symbol. Zebra also documents a Minimum Scan Interval that prevents the scan beam from being emitted for a period after a scan is initiated. These settings affect capture behavior; they do not know whether a repeated value is commercially valid.
Record the aim type, timeout values, scanner selection and profile identity. The scanner-profile deployment guide describes how to identify and verify a deployed capture profile. Test unsupported settings as unsupported rather than assuming that a similar menu name has the same behavior.
Compare evidence at four checkpoints
| Checkpoint | Evidence to retain | What it does not prove |
|---|---|---|
| Physical action | Trigger press, aiming period and label presented | How many decode events the capture layer emitted |
| Capture-service output | Value, symbology, timestamp and profile for each delivered event | Whether the application accepted either event |
| Application decision | Open record, validation result and duplicate rule applied | Whether the backend committed once or more than once |
| Stored transaction | Transaction identifier, value, status and server time | Which scanner setting or physical action caused the result |
Zebra's DataWedge Demo documentation describes a named demo application that displays decoded data received through a DataWedge profile. It is useful as a vendor-specific example of observing the capture layer; it is not proof of the path used by another application.
Run an editorial repeated-value scenario
Consider a picking workflow with tote T-204 and product P-771. The approved sequence opens the tote once, then records each unit through an explicit quantity or serial rule. Test four actions: a short trigger press on T-204, a held trigger on the same code, two intentional scans of two units carrying P-771, and a retry after the application shows no confirmation.
For each action, record physical presses, capture events, visible application decisions and committed transaction IDs. If the held trigger produces two capture events, evaluate the documented scanner control. If only one event reaches the app but two records appear, inspect application or service behavior instead. If two identical product-code scans are legitimate, a blanket value-based deduplication rule would lose valid work.
The offline transaction guide covers a different problem: a request may have been processed even when its confirmation is missing. Preserve a logical transaction identity rather than using a scanner timeout as an offline idempotency mechanism.
Test both suppression and permitted repeats
An acceptance run needs a negative and a positive case. Confirm that one held trigger or immediate accidental re-trigger does not create an extra event under the approved configuration. Then confirm that the same value can be accepted again after the business condition that makes it valid, such as a new serial, a confirmed quantity step, a new location or a new transaction.
Vary the actual labels, trigger technique, continuous-read setting, application screen and device build. A timeout long enough to hide operator errors may also hide valid fast work. A timeout short enough for throughput may still allow an accidental second event. The appropriate value belongs to the named workflow and tested configuration, not to a generic scanner category.
Keep application duplicate controls explicit
The application should define which field or transaction key is unique, when a repeat is rejected, when it is counted, and what the operator sees. If the same product code can represent multiple units, use the workflow's quantity or serial evidence rather than silently dropping equal values. If a location or tote may be opened only once, show that rule as an application decision.
The integration-methods guide helps identify whether data arrives through keystrokes, Intent or an SDK. Use Integration Support to request the interface and version documentation for the shortlisted configuration; do not infer duplicate controls from a product photograph or a successful single scan.
Send a repeat-control test record
Provide the device and scanner engine, firmware or OS build, capture-service version, profile export, aim type, timeout settings, output method, application version, sample labels, permitted-repeat rule, rejected-repeat rule and timestamped results at all four checkpoints. Include the operator action that produced each result.
Use Contact to send the configuration and workflow. The supplier can identify available capture controls for the exact hardware and software version; the application owner remains responsible for transaction uniqueness, user feedback and stored records.