Code Matching¶
Overview¶
Code Matching provides a way to ensure that the scanned barcode data matches against expected data included in the print job. This prevents e.g. an existing barcode on a product to be mistaken for a successfully applied label.
Example scenario: Applying label X on a product with an existing barcode Y.
![@startuml
hide footbox
skinparam BackgroundColor transparent
skinparam shadowing false
skinparam ActorBorderColor black
skinparam ParticipantBorderColor black
skinparam ParticipantBackgroundColor #EEEEEE
skinparam ArrowColor black
participant "Host PC" as host
participant "Marker" as print
participant "Product" as prod
participant "Scanner" as scan
host -[#green]-> print: Job A with data X
activate print
print -[#red]-> prod: Label A with data X\nwas dropped.
print -[#green]-> scan: request scan
activate scan
scan -[#green]-> prod: reading existing barcode Y
scan -[#green]-> print: send result Y (from an existing barcode)
deactivate scan
activate print
print -[#green]-> print: Y = X?
deactivate print
print -[#green]-> host: A: no_match
deactivate print
note over host #lightgreen
Detected mismatch
reported to host
end note
@enduml](../_images/plantuml-baedd9db27e989dd38d588f10ad37795fe383db4.png)
If Code Matching would have not been used, the existing barcode Y of the same type would have been mistaken as a successful application of label X.
Expected data can be included in print jobs using the special variable
"_code_matching". This works for JSON-RPC and ZPL.
See also
Code Matching in the JSON-RPC API documentation for details on pattern matching and matching policy.
See also
Including Job Metadata in the ZPL Guide.
Error Classes¶
Barcode errors have been categorized in three different classes:
- ERR_TOO_FEW
One or more barcode not readable because:
- Label does not stick to the product.
- Broken printhead dots.
- Layout errors.
- Media errors.
- ERR_TOO_MANY
Unexpected barcodes read because of:
- A stray label is visible by the scanner.
- Barcodes already present on the product.
- ERR_SYNC
Unexpected barcodes read because of:
- Synchronization error (the host and the printer are mismatched – possibly due to differing views on the job queue state).
- Product conveying issues (products unexpectedly appearing or missing) before printing and applying.
Validation Techniques¶
Using a scanner it is possible to validate the existance of barcodes in different ways:
- Require n barcodes
- The basic way to use a scanner is to require a number of readable barcodes on each scan. This is only effective against ERR_TOO_FEW which is implied in all cases below.
- Require no_read - Not implemented
- A scanner can also give feedback whether any readable barcodes exist prior to label application.
- Internal Matching
- The printer matches the scanner against a stored expected data set.
- External Code Matching - Not implemented
- The expected data set is sent in a host-controlled scanning command. This way the marker doesn’t need to hold any state, and any synchronization errors are catched as well. Requires the most integration work in the host system.
The table describes which combination of errors (ERR_TOO_FEW and Require n barcodes is implied in all cases) can be detected using different validation strategies.
- The first two columns denotes which error classes that are expected to be present.
- The next three columns describes which validation techniques that are used.
- Finally the Detection column sums up whether the combination of employed validation techniques will reliably detect the present error classes.
| ERR TOO MANY | ERR SYNC | Require no_read | Internal Matching | External Matching | Detection |
|---|---|---|---|---|---|
| – | – | – | – | – | OK – Scanner detects non-readable barcodes. |
| Yes | – | – | – | – | UNRELIABLE – if scanner cannot distinguish between a stray label/barcode and the printed label. |
| Yes | – | – | Yes | – | Fair – Code Matching increases probability to find stray labels, but will only work for unique labels. |
| Yes | – | Yes | – | – | OK – Requiring no_read before applying prevents stray labels or present barcordes to be mixed up with the last printed label. |
| – | Yes | Yes/– | Yes/– | – | UNRELIABLE – Synchronization errors risk to pass undetected. |
| – | Yes | Yes/– | – | Yes | OK – external Code Matching finds synchronization errors. |
| Yes | Yes | – | – | Yes | Possibly UNRELIABLE – if scanner cannot distinguish between stray label and the printed label. |
| Yes | Yes | Yes | – | Yes | OK – Requiring no read before applying prevents stray labels or present barcodes to be mixed up with the last printed label. Combined with external Code Matching this is the safest option. |
Scenarios¶
Failed Application With Scanner¶
With a scanner, an unreadable barcode or non-existent label will be detected.
![@startuml
hide footbox
skinparam BackgroundColor transparent
skinparam shadowing false
skinparam ActorBorderColor black
skinparam ParticipantBorderColor black
skinparam ParticipantBackgroundColor #EEEEEE
skinparam ArrowColor black
participant "Host PC" as host
participant "Printer" as print
participant "Applicator" as appl
participant "Product" as prod
participant "Scanner" as scan
host -[#green]-> print: Job A with data X
activate print
print -[#green]-> appl: Label A with data X
appl -[#red]-> prod: Label A with data X\nwas dropped\nor unreadable.
print -[#green]-> scan: request scan
activate scan
scan -[#green]-> print: send no_read
deactivate scan
print -[#green]-> host: A: failed
deactivate print
note over host #lightgreen
failure reported
to host
end note
@enduml](../_images/plantuml-33368fadc7f797d25137739bfb9343928d99a445.png)
UNDETECTED: Failed Application With Scanner and Stray Label¶
Even with a scanner, a stray label, or old barcodes on the product itself could potentially be mistakenly taken for a successful labeling.
![@startuml
hide footbox
skinparam BackgroundColor transparent
skinparam shadowing false
skinparam ActorBorderColor black
skinparam ParticipantBorderColor black
skinparam ParticipantBackgroundColor #EEEEEE
skinparam ArrowColor black
participant "Host PC" as host
participant "Printer" as print
participant "Applicator" as appl
participant "Product" as prod
participant "Scanner" as scan
host -[#green]-> print: Job A with data X
activate print
print -[#green]-> appl: Label A with data X
appl -[#red]-> prod: Label A with data X\nwas dropped\nor unreadable.
print -[#green]-> scan: request scan
activate scan
scan -[#red]-> print: send result Y (from a stray label)
deactivate scan
print -[#green]-> host: A: success
deactivate print
note over host #FFAAAA
UNDETECTED FAILURE
success reported
to host
end note
@enduml](../_images/plantuml-aed324b03b24454108a6ecb85ecfa97935df5d9b.png)
Failed Application With Code Matching and Stray Label¶
Using Code Matching we can decrease the probablity that a stray label would be mistaken for the real label.
![@startuml
hide footbox
skinparam BackgroundColor transparent
skinparam shadowing false
skinparam ActorBorderColor black
skinparam ParticipantBorderColor black
skinparam ParticipantBackgroundColor #EEEEEE
skinparam ArrowColor black
participant "Host PC" as host
participant "Printer" as print
participant "Applicator" as appl
participant "Product" as prod
participant "Scanner" as scan
host -[#green]-> print: Job A with data X, MS=X
activate print
print -[#green]-> appl: Label A with data X
appl -[#red]-> prod: Label A with data X\nwas dropped\nor unreadable.
print -[#green]-> scan: request scan
activate scan
scan -[#red]-> print: send result Y (from a stray label)
deactivate scan
activate print
print -[#green]-> print: Y in {X}?
deactivate print
print -[#green]-> host: A: failed
deactivate print
note over host #lightgreen
failed match
with expected data
reported to host
end note
@enduml](../_images/plantuml-ee8bd3a8629b081314060d704172dd9f3e832106.png)
In summary, internal Code Matching helps with errors that happens external to the printer sequence. E.g. labels being mechanically dropped, or scanner potentially scanning other labels.
UNDETECTED: Printer Synchronization Error With Code Matching¶
If the host system and printer fails to synchronize their world views on the expected product to print and apply due to e.g. queuing issues, there is a risk that internal Code Matching does not detect any errors.
![@startuml
hide footbox
skinparam BackgroundColor transparent
skinparam shadowing false
skinparam ActorBorderColor black
skinparam ParticipantBorderColor black
skinparam ParticipantBackgroundColor #EEEEEE
skinparam ArrowColor black
participant "Host PC" as host
participant "Printer" as print
participant "Applicator" as appl
participant "Product" as prod
participant "Scanner" as scan
host -[#lightgray]-> print: Job A with data X, MS=X
activate print
note over host #FFAAAA
the host has forgot A
and now wants to print B
end note
host -[#green]-> print: Job B with data Y, MS=Y
print -[#green]-> appl: Label A with data X\n(the host wanted to print B)
appl -[#green]-> prod: Label A with data X.
print -[#green]-> scan: request scan
activate scan
scan -[#green]-> print: send result X
deactivate scan
activate print
print -[#green]-> print: X in {X}?
deactivate print
print -[#green]-> host: A: success
deactivate print
note over host #FFAAAA
UNDETECTED MISMATCH
with expected data
reported to host as
success
end note
@enduml](../_images/plantuml-6a8deb5571ad6012265355007eb273fc002bd682.png)
Printer Synchronization Error With External Code Matching¶
By letting the host request the scanning with an explicit match data set, any synchronization errors can be detected. This requires a higher level of integration but would give the most robust solution to any interference during the print and apply sequence.
![@startuml
hide footbox
skinparam BackgroundColor transparent
skinparam shadowing false
skinparam ActorBorderColor black
skinparam ParticipantBorderColor black
skinparam ParticipantBackgroundColor #EEEEEE
skinparam ArrowColor black
participant "Host PC" as host
participant "Printer" as print
participant "Applicator" as appl
participant "Product" as prod
participant "Scanner" as scan
host -[#lightgray]-> print: Job A with data X
activate print
note over host #FFAAAA
the host has forgot A
and now wants to print B
end note
host -[#green]-> print: Job B with data Y
print -[#green]-> appl: Label A with data X\n(the host wanted to print B)
appl -[#green]-> prod: Label A with data X.
print -[#green]-> host: Apply Sequence finished
host -[#green]-> print: request scan with match set {Y}
print -[#green]-> scan: request scan
activate scan
scan -[#green]-> print: send result X
deactivate scan
activate print
print -[#green]-> print: X in {Y}?
deactivate print
print -[#green]-> host: fail {Y} not matched by X
deactivate print
note over host #lightgreen
detected mismatch
reported correctly
to host as failure
end note
@enduml](../_images/plantuml-d967dd39fd5cf1e0f9d17e4fb0f2deb7c73a6d51.png)
Moving Products¶
For stationary marking, the scanner result is always matched against the code matching data associated with the latest label that was printed. When moving products are marked, the barcodes that are scanned are not necessarily the last to have been printed, and a queue of code matching data is used.
Configuration¶
In order to be able to synchronize code matching data with a scanner result, specific configuration is required.
Scanner Configuration¶
The scanner needs to have its Output Delay such that it always produces a result a certain time period after the scan command was issued. Even if the scanning completes before the configured time, the scanner should withhold the result so that it is delivered to the printer after the configured amount of time has passed.
Printer Configuration¶
Since the printer must be aware of which label a certain scanner result is associated with, only the follwing start conditions are supported for moving products:
- Label Printing
- Label Printed
- Label Applied
- Applicator Home
Set this to be equal to the Output Delay configured for the scanner.
Behavior¶
Scanning Windows¶
A scanning window is the time during which the printer accepts a result from the scanner for a specific label.
When a label has been printed and applied, scanning is triggered on
the configured Start Condition. The printer expects a result from
the scanner within a time window covering the configured Output
Delay. If the scanner fails to produce a scan result within the
configured time window, a code_matching_timeout alarm will be
raised.
The size of the scanning window is based on the Minimum Cycle Time to ensure that no two scanning windows overlap.
Revision 2022-03-29
- Added support for moving products
Revision 2021-02-05
- Updated transport of expected data in ZPL files.
Revision 2021-01-31
- Minor changes to UI element naming and examples.
Revision 2021-01-22
- Changed pattern matching syntax from regular expressions to Unix shell style matching
using easier to understand
*and?wildcards.
Revision 2021-01-21
- Changed name from Match Count to Matching Policy.
- Changed name from Match Method to Matching Method.
- Updated pattern matching examples using valid regular expression syntax.