While trying to combine two “preflight checklist” steps for confirming printer and barcode scanner functionality, I tried to program a button to:
- Store a randomstring to a variable
- Print a label with a QR code of that value and instructions to scan with the barcode scanner
Upon scanning the barcode, the app device trigger was supposed to compare the output to the stored randonstring and check the boxes for “Printer OK” and “Scanner OK” automatically.
This initially did not work due to what I see as a quirk in the required ZPL syntax for QR codes.
From [labelary.com](https://labelary.com/)
, normal field data content should follow the ^FD command immediately, with any whitespace being reflected in the output:

However, if you format your field data as a QR code using the ^BQ command, depending on the characters at the start of that randomstring, the resulting QR code may be missing the first two or three digits.
Scanning that QR code gives “ED7mhfcgsL76g4w” instead of the “F4ED7mhfcgsL76g4w” in the ZPL after ^FD. Note the “Lintel Warning” error.
If the first character in the randonstring were to be any of H,Q,M, or L, the warning disappears but the QR code still loses the first two characters giving “ED7mhfcgsL76g4w” again.
If the first character is one of those four, and the second happens to be “A”, we actually lose the first three characters, getting only “D7mhfcgsL76g4w” from the resulting QR code.
After a little more digging, I found this labelary example for the ^BQ command, which prescribes the following syntax for the ^FD command following the ^BQ command, which seems to be a deviation from both the normal ZPL syntax and the comprehensiveness of labelary’s documentation on commands (in this case the ^FD command info lacks any detail about these additional parameters). In the info for ^BQ, note the highlighted text about ^FD.
Interestingly enough, the first character after ^FD wants to be either H/Q/M/L and the second wants to be either A/M.
Some additional learnings:
- The error correction level (the first character after ^FD) seems to override whatever was specified in the ^BQ command
- For the input mode (the second character after ^FD), A seems to work just fine, M seems to cause errors I haven’t tried to resolve.
- The example above uses a “,” after the ^FDQA to precede the actual field data for the QR code, but I have found other characters also work: whatever character is next just gets omitted from the QR code output.