Cognex DataMan: ResultID Marks a Scan, Not the Code

The Cognex DataMan interface must identify a new read by transaction state, not by barcode-text uniqueness. Use ResultID as the primary new-result discriminator, copy the associated data, then acknowledge the result. The same barcode scanned again is still a separate scan and receives another rolling ID.

Reject the quick fixes first

Do not decide that a scan is new by comparing its decoded text with the previous text. That suppresses valid repeated scans: two cartons, parts, or operator actions can legitimately present the same code. A text comparison answers “Is this value different?” It does not answer “Did another read occur?”

Do not use Result Available as an unqualified one-program-scan pulse. It reports that a completed result is available and data was found. The PLC acknowledges that result, the bit returns to zero, and a later result can assert it again. If PLC logic misses the state transition, acknowledges too early, or expects the associated data in the same program scan, the application can lose or mismatch a transaction.

Do not treat a numerically larger ID as the only valid next event. The ID rolls over. Test whether it changed rather than whether it increased.

Check: Confirm that the production requirement counts scan events, including repeated barcode values. If it only needs unique product codes, apply duplicate filtering after the scan has been captured.

Connect the complete result interface

Map the scanner’s cyclic PROFINET input data into stable PLC tags. At minimum, expose Result Available, ResultID, the decoded barcode data, and every status bit supplied by the configured scanner interface. Map the scanner’s defined result-acknowledgment output as well.

Keep the status, identifier, length information, and payload together as one logical result structure. Scattering them through unrelated routines makes it easy to acknowledge one transaction while another routine is still reading its data.

Signal	Use in PLC logic	Wrong use
Result Available	Qualify when a completed result can be collected	Use as the sole record of event identity
ResultID	Detect a result that differs from the last accepted result	Require it to be greater than the previous value
Barcode data	Copy into a PLC-owned buffer for processing	Compare it with the prior code to detect a scan
Result acknowledgment	Release the collected result after copying it	Acknowledge before the payload is stored
Status bits	Diagnose readiness, transfer state, and sequence timing	Monitor only the decoded string

Check: Watch the mapped input and output structures online. Verify that scanner status changes reach the PLC and that the acknowledgment command reaches the scanner before building the event logic.

Trace one complete transaction

Set up a trace containing Result Available, ResultID, the acknowledgment command, and the other scanner status bits. Add the PLC event latch and stored previous ID. A trace exposes ordering problems that ordinary online monitoring can hide.

1. Start with no unprocessed result and the acknowledgment inactive.
2. Present one readable barcode.
3. Observe Result Available assert and record the accompanying ResultID.
4. Observe when the PLC copies the barcode data and latches its internal new-result event.
5. Apply the configured acknowledgment only after the copy completes.
6. Verify that Result Available clears.

The result indication and every consumer of the result should not be assumed to complete in the same PLC program scan. Cyclic I/O updates, program execution order, and acknowledgment sequencing can place related transitions in adjacent scans. Retain state across scans instead of building logic that depends on a momentary coincidence.

Check: The trace must show one copy and one internal event before acknowledgment, followed by the scanner returning to its ready state.

Detect the rolling ID change

Store the last successfully accepted ResultID. When a result is available, compare the current ID with that stored value. If they differ, copy the complete result into PLC-owned memory and mark it ready for downstream logic. Update the saved ID only after the copy succeeds.

The names other than ResultID represent application tags; bind them to the actual configured I/O fields. Make New_Result either a controlled pulse or a queued record so downstream logic cannot miss it.

Define startup behavior deliberately. To ignore a stale result after a PLC restart, initialize the saved ID from the current interface state before enabling normal detection. To recover a pending result, retain the last accepted ID and process an available result whose ID differs. Do not compare IDs with greater-than logic because a rolling identifier eventually wraps.

Check: Scan two different codes and confirm that each changed ID produces exactly one buffered record, even if the event-processing routine runs more slowly than the I/O routine.

Acknowledge only after securing the data

The acknowledgment is part of the transaction, not a cleanup bit. Once the PLC acknowledges, the scanner can clear Result Available and prepare the interface for another result. If the PLC acknowledges before copying all associated fields, the stored ID and barcode payload can come from different transactions.

1. Detect an available result with a changed ResultID.
2. Copy the ID, barcode data, and required metadata into one PLC buffer.
3. Validate that the buffer is acceptable to the application.
4. Commit it to the application queue or consumer handshake.
5. Save the accepted ResultID.
6. Issue the scanner’s configured result acknowledgment.
7. Remove the acknowledgment according to the configured handshake after the scanner clears the result state.

Keep duplicate filtering separate. If the process forbids the same barcode within a defined production window, compare buffered records in a FIFO or application history after acquisition. Record the repeated scan first; then accept, reject, or alarm it according to process rules.

Check: Hold the downstream consumer busy while scanning. The PLC must either preserve the buffered result or prevent acknowledgment until storage is available; it must not silently discard the result.

Prove repeated scans end to end

Run the test that defeats text-based detection. Scan one barcode, wait for the PLC to capture and acknowledge it, and verify that Result Available returns to zero. Present the same barcode again. The text remains identical, but the rolling ResultID changes and the PLC must generate a second event.

Test	Expected observation	Failure points to
One readable barcode	One new ID, one buffered result, one acknowledgment	Basic mapping or handshake fault
Same barcode again after acknowledgment	Same text, changed ID, second buffered result	Text-based duplicate suppression or stale ID logic
Different barcode	Changed ID and matching new payload	Copy order or data-alignment problem
Repeated production-rate scans	One application record per accepted ID	Queue capacity, acknowledgment timing, or missed state transitions

Compare the scanner trace with PLC records. Every accepted ID must correspond to one complete payload, and every acknowledgment must follow a successful copy.

Check: Release the station only after the repeated-code test records two separate transactions without relying on a text change.

FAQ