Case study

A one-scan RFID encoding station — Zebra ZD621R, 1,200 labels/day

A labeling line encoding 1,200 RFID tags a day was losing time to manual verification and silent void handling. A ZPL ^RF encoding station with an inline verify-read cut operator touches to one per label.

A labeling operation encoding around 1,200 RFID tags a day was running its ZD621R printers with stock label templates and a manual verification step: print a label, hand-scan it with a separate handheld to confirm the encode took, then either release it to stock or discard it. On a slow day that was fine. On a day with a bad reel of stock — which happened more often than anyone wanted to admit — bad tags made it past the operator because the manual scan step got skipped under time pressure.

The goal was a station where one trigger pull did the whole job: encode, verify, and either release or void the label automatically, with no separate handheld step relying on the operator's diligence.

The problem

The ZD621R can both print and RFID-encode in a single pass using ZPL's ^RF command set, but the vendor's default templates encode and print without a verification read — they assume the tag encoded correctly because the printer reported no ZPL error. In practice, RFID encode failures on marginal reels don't always throw a printer-level error; the tag can silently fail to accept the write or accept a corrupted EPC, and the printer will still eject a label that looks fine.

The line needed a template and control layer that treated a completed print as provisional until a verification read confirmed the EPC on the label matched the EPC that was supposed to be written — and that voided the label automatically, with a visible mark, when it didn't.

Hardware used

Architecture

A .NET service holds the print queue and is the single source of truth for which EPC gets assigned to which label — this matters because retrying a failed encode must reuse the same EPC assignment rather than skipping ahead, or the sequence drifts out of sync with the physical label count.

Copy[.NET job queue] --EPC + ZPL job--> [ZD621R]
                                        |
                                        | ^RF write, then ^RF read-back
                                        v
                                [Printer encode result]
                                        |
                     match? ----yes----> release to output bin
                        |
                        no
                        |
                        v
              [VOID overprint + log] --> retry same EPC, next label

The ZPL template issues the ^RF write for the assigned EPC, then immediately issues an ^RF read-back on the same tag before the label advances past the print head. The read-back result comes back through the Link-OS SDK's printer feedback channel to the .NET service. A match releases the label to the output bin. A mismatch triggers a second ZPL job that overprints a visible "VOID" mark on the same physical label as it ejects — so a bad label is never ambiguous on the belt — and the same EPC is requeued for the next blank rather than advancing to a new one, keeping the EPC sequence table gapless.

What was tricky

The failure mode that took the longest to track down wasn't the encode failure itself — it was a printer/host race condition. The read-back status doesn't always come back to the host before the label mechanically advances far enough that a void overprint would land in the wrong position. Early versions occasionally printed "VOID" a few millimeters off the actual bad label, once even landing on the following good one. The fix was to hold the label at the print head — using the printer's pause-after-print behavior rather than software timing — until the SDK confirmed the read-back had actually completed, instead of assuming a fixed delay was long enough. Fixed delays worked in testing and then failed intermittently on the floor once the RFID module started running warm after a few hours, which quietly shifted the read timing.

Result

Operator touches per label dropped from two (print, then separate handheld verify) to one (a single trigger pull, verify happens inline). Void labels are now unambiguous and physically marked instead of relying on an operator noticing a beep. Across the first month of production, roughly 3% of labels were caught and voided automatically that would previously have shipped as silent bad encodes — tags that read fine on the printer's own ZPL success response but failed the independent read-back check.