Multiple codes: region rules and duplicate-read control

Problem and prerequisites

Reading every visible code can associate a neighbor’s label with the current part. Define the expected code roles and count before testing; confirm whether the reader supports regions, multiple results and the required trigger window.

Prepare the test

Prepare two labels on one part plus a nearby unrelated label. Give test parts independent identifiers. Write the deduplication scope explicitly: within one part event, not globally across the batch.

Draw the physical part boundary before drawing reading regions. A camera image may contain the intended label, a neighboring part and stationary fixture labels simultaneously. Obtain reference images at the permitted extremes of part position and rotation, and map each required field to a role rather than to discovery order. For every role, define allowed symbology, expected count and content rule. Decide whether an extra code is ignored by a documented exclusion or makes the event invalid; an unreviewed ignore rule can conceal a misplaced label. Keep the region definition in the recipe revision so that a later geometry change is traceable to the result it affected.

Procedure

1. Assign a permitted region, code type and content rule to each role.
2. Test both expected codes, then remove one, add a third and exchange their positions.
3. Associate the complete result set with one trigger identifier; missing or extra required results cause a controlled reject.
4. Suppress repeated observations within that event only; a new part may legitimately carry the same batch code.
5. Close the event on the defined acquisition boundary and test a late repeated result.

Begin with one event containing both required labels in their normal positions. Observe the detected code positions and the final role assignment, not just a green read indicator. Move a neighboring label into the image without changing the intended labels and check the exclusion behavior. Remove each required label in turn, then exchange their positions. Add a third readable code to expose first-result shortcuts. Submit repeated results before the event closes and delayed results afterward. The result set should remain associated with one part identifier, and its completion rule must be explicit. A decoder’s ability to return multiple codes does not by itself supply part association, role validation or a correct application transaction boundary.

Illustrative test record

Illustrative assumptions, not measured Deyi performance. Replace these values with your own signed test records.

Suppose the left region must contain a part identifier and the right region a batch identifier. Two readable strings are insufficient if their roles are exchanged. Validate region, symbology and payload rule before binding each value to T100. A repeated result for T100 can be suppressed after recording it; the same batch string on T101 must remain valid. Reject a missing role without borrowing a previous part’s value.

Build the record as an event with a set of role results. Retain each raw payload, code type, detected region or position, arrival time and acceptance reason. If the transport can send repeated messages, keep a repeat counter or diagnostic record while suppressing only a duplicate application action. Scope the duplicate key to the current event and role; decide whether different content for the same role is a conflict rather than a duplicate. Never deduplicate globally on a batch string, because many legitimate consecutive parts share it. On event closure, record missing, extra and conflicting roles explicitly instead of copying a value from an earlier event.

Two views of the workflow

Troubleshooting

• A neighboring label entering the permitted region requires tighter presentation or region control.
• An expected duplicate across different parts must not disappear due to a global text cache.
• Out-of-order output needs explicit role mapping, not an assumption that the first string is the product code.

Acceptance and handover

All 50 assumed test events must retain their part association and expected role set. Accept only the defined combination; document missing, extra and late-result outcomes. The number 50 is a trial example, not a statistical qualification.

Set acceptance limits before testing and retain the original evidence. The examples here do not establish a supplied model’s capabilities.

Verify the implementation with an independently prepared expected-result list. For every planned event, the reviewer should compare expected roles with received roles and confirm exactly one final disposition. Include adjacent parts carrying the same batch identifier, an exchanged-label case and an old result arriving during the next event. Restart or clear the receiver queue under controlled conditions and confirm that no earlier role result enters the new event. The proposed 50 events are an illustrative coverage set, not a statistical reliability claim. Production acceptance also requires the agreed positional envelope, actual operating speed and fault recovery. Hand over the region images and role rules together with the recipe, so that maintenance does not widen an ROI without reviewing the association risk.

Related reading

Read the related selection and application guides before choosing equipment. For an engineering review, provide sample images, the required result, operating conditions and the completed test record.