zpl.tools
RFID

^RU - Read Unique RFID Chip Serialization

Builds a 38-bit serial number from the tag's factory identifier for use in EPC data and in printed fields.

^RU turns a transponder's factory identifier into a 38-bit serial number, so a run of labels can carry unique numbers without a counter and without host data. Its reach goes past the RFID commands. Once ^RU is active, a token such as #H expands inside any ^FD, including an ordinary printed text field. It is therefore the one command in this category that can change a field meant for print.

Syntax

^RUa,b

Support

Not implemented yetparsed: none · state: none · rendered: none

Recognised as valid ZPL and not implemented yet, so it has no effect on the output.

Derives a serial number from the transponder's TID. With no transponder, no TID exists to derive from. The renderer does not parse it, so it reports "valid ZPL, not supported yet". Labelary does not implement it either, so neither renderer returns tag data; only the warning list differs. Read the deviations below: this one does reach printed fields. The 2006 ZPL II Programming Guide does not document this command, and the parameters below come from Zebra's later RFID documentation for Gen 2 printers. — not pinned by a test

Labelary does not implement it either, so there is no parity reference.

Parameters

aPrefixoptional · text

The most significant bits of the serial number, written as ASCII 1 and 0 characters. At most 38 characters; its length sets the length of the prefix.

Default
derived from the chip's manufacturer identifier: 100 EM Micro, 101 Impinj, 110 Alien, 111 NXP
Invalid value
not documented, and we have not measured it. The renderer does not parse this command or validate its arguments. The guide does not state what a printer does with an out-of-range value.
Test coverage
bSpecial characteroptional · single character

The character that introduces a serial-number token in ^FD. Any ASCII character that is not the current command, control or delimiter character, and not a real-time-clock character.

Default
#
Invalid value
not documented, and we have not measured it. The renderer does not parse this command or validate its arguments. The guide does not state what a printer does with an out-of-range value.
Test coverage

Behavior

The prefix a is written as ASCII 1 and 0 characters and not as a number, and its length sets how many of the 38 bits it occupies. Without it the printer derives the prefix from the chip manufacturer. The special character b can be any ASCII character that is not the command, control or delimiter character, and not a real-time-clock character. ^SN and ^SC follow the same collision rule.

The renderer does not parse ^RU, so no substitution happens and the token prints literally. The guide's own field ^FDSerial Number: #H^FS puts the two characters #H on the label where the serial number belongs. Labelary does the same, measured 2026-07-30, so this is a gap against the guide and not a difference between the two renderers.

Differences from the specification

zpl.tools against the ZPL II guide

Where our renderer behaves differently from the specification.

  • The renderer prints the serial-number tokens literally. ^RU makes #S, #H, #E, #F, #P and #Q expand inside any ^FD, as ^SN and the real-time-clock tokens do. This includes ordinary printed text fields. The renderer does not parse ^RU, so it substitutes nothing: the guide's own example field ^FDSerial Number: #H prints the two characters #H instead of a serial number. This is the one RFID command whose absence changes a field that always had to print. We measured this on 2026-07-30. Labelary prints the literal #H too, so this is a gap against the guide, not a divergence from Labelary. — not pinned by a test

Example

The #H placeholder a Gen 2 printer would fill in from the chip:

^XA
^RU
^FO50,50^A0N,40,40^FDSerial Number: #H^FS
^XZ

Open in viewer