I have the following ZPL code
^FO25,215^A0,N,25,25^BCN,100,N,N,N,U^FN21^FS
The customer wants this barcode as a UCC 128 barcode, but their data is alphanumeric.
Research
I looked through the ZPL docs which mentions:
option U for the mode defaults to Subset C which automatically strips out the alpha characters.
can prepend the entry with >9 or >7 to make this Subset A which allows alphanumerics.
Issue
I tried:
^FO25,215^A0,N,25,25^BCN,100,N,N,N,U^FN>721^FS
But it still removes the letters from the barcode.
Not only that, but it adds 7 as well.
There is nothing that precludes using alphanumeric with UCC-128 (aka GS1-128).
GS1-128 compliant format
What you must do for a code128 barcode to be GS1-128 compliant is to format the data correctly.
That means the barcode data must be formatted as:
<fnc1> <app-id> <value>
Where:
<FNC1> character in ZPL is >8 for all character sets.
<app-id> is the application-identifier (AI) for your barcode purpose
<value> is the (alpha-numeric) data to be encoded with the barcode
A good summary of UCC application-identifiers (AI) gives UCC-128, EAN-128 & GS1-128 Bar Code Explained (wayback archive from 2017).
Example
Let's say you would use an AI of 10 and are encoding the batch number 1702ABCD.
Then the resulting ZPL field data would be: ^FD>8101702ABCD^FS
Related
I need to print a SSCC Code 128 barcode using Zebra ZPL. My problem is that the escape characters used are also encoded in the barcode, which should not happen.
Here is the code:
^FO50,960^BY3
^BCN,180,N,N,N,A
^FD>;>800{sscc}^FS
The sequence >;>8, which is the escape / control sequence, gets encoded in the barcode. So when I read the barcode with a scanner, I get: >;>800xxxxxx....
What am I missing here?
Reposting this as an answer. You are using Automatic mode (the A at the end of the ^BC command). Automatic mode disables escape sequences since it applies its own shift/latch logic. Use mode N (None) to allow manually encoding the data.
I am creating a GS1 DataBar code in ZPL and I can't find a way to encode FNC1 character to terminate variable length GS1 Application identifiers (GS1 AI). To be honest, it is not a necessity. GS1 DataBar is mostly used for fresh foods and other groceries, and so far I noticed only one variable length GS1 AI (10 - batch/lot) to be used regularly. Though I haven't done any research, so maybe I am wrong. Nevertheless, it came to my mind if it is possible in ZPL to insert FNC1 character. In other programming languages it is possible to include it, but I had no luck with ZPL. It seems, that GS1 DataBar does not work well with hex commands. When I used hex Group separator [GS] _1D it didn't even rendered the code. Other FNC1 characters like _1 from GS1 DM or >8 from GS1-128 do not work, as expected.
I found this answer on Zebra support, but it did not rendered on Labelary ZPL viewer, so I am not sure if it works. I tried including the # character directly and with hex character, but with no success.
My ZPL code:
^XA
^FO100,100^BRN,6,4,,,6
^FD010858000000000931030001251722022210ABC123^FS
^XZ
What I wonder is how to include for example serial number AI(21) after batch AI(10) at the end of the code.
I am printing a code 128 barcode in ZPL, which must be 78mm. The following numeric barcode works as expected:
^XA^FO141,330^BY3,3,^BCR,243,Y,N,N,A^FD12001752107481808006410360011596^FS^XZ
But changing one number to 'X' near the end of the barcode, means the barcode is now printed as 91mm:
^XA^FO141,330^BY3,3,^BCR,243,Y,N,N,A^FD1200175210748180800641036001X596^FS^XZ
Changing the barcode module with from 3 to 2 with ^BY2 makes the barcode 60mm which is not acceptable.
Any suggestions?
Code 128 has different Subtypes. One of them can encode two numbers in one barcode-character. Your Zebra optimizes your barcode because you use the
^BCo,h,f,g,e,m
Command with Parameter m = mode set to
A = Automatic Mode
This analyzes the data sent and automatically
determines the best packing method. The full
ASCII character set can be used in the ^FD
statement — the printer determines when to shift
subsets. A string of four or more numeric digits
causes an automatic shift to Subset C.
Switching modes and printing alphanumeric makes your barcode longer.
I am trying to come to terms with how a barcode is decoded and generated by a scanner.
A note from the client says the following generated bar code consists of extra characters:
Generated Code: |2389299920014}
Extra Characters: Apparently the first two and last three characters are not part of the bar code.
Question
Are the extra characters attached by the bar code reader (therefore dependent on the scanner) or are they an intrinsic part of the barcode?
Here is a sample image of a barcode:
http://imageshack.us/a/img824/1862/dm6x.jpg
Thanks
[SOLVED] My apologies. This was just another one of those cases of 'shooting your mouth off' without doing proper research.
Solution The code is EAN13. The prefix and suffix are probably scanner dependent. The 13 digits in between are as follows (first digit from the left) Check Sum (Next 9 digits) Company Id + Item Id (Last 3 Digits ) GS1 prefix
It's hard to answer without understanding what format you are trying to encode, what the intended contents are, and what the purported contents are.
Some formats add extra information as part of the encoding process, but it does not become part of the content. When correctly encoded and decoded, the output should match the input exactly.
Barcodes encode what they encode and there is no data that is somehow part of the barcode but not somehow encoded in it.
EAN-13 has no scanner-dependent considerations, no. The encoding and decoding of a given number is the same everywhere. EAN-13 encodes 13 digits, so I am not sure what the 13 digits "in between" mean.
You mention GS1, which is something else. A family of barcodes in fact. You'd have to say what specifically you are using. The GS1 encodings are likewise not ambiguous or scanner-dependent. You know what you want to encode, you encode it exactly, it's read exactly.
I am trying to print a Code 128 barcode on a label using the following the piece of ZPL with a Zebra ZP 450 printer:
^BY3^BCN,112,N^FO090,660^FD>;>89102100^FS
I'm expecting the barcode to scan as "9102100". However, when I scan the printed barcode, it reads as "910210" -- cutting off the final digit.
If I change the last digit, it is still cut off. But if I add more digits onto the end, e.g. "9102100357", the barcode correctly reads as "9102100357".
Why am I "losing" a digit in this particular case?
The >; inside of your ^FD block is telling the code 128 barcode to go into a subset (subset C in this case) which forces the data in the barcode to be numeric pairs (00 - 99). Any data that is not supplied in numeric pairs is ignored. If you put a letter in there, it will ignore that pair. In your case 9102100 has an odd number of numbers, so it ignores the last one. If for example, you add another 0, it will put all the letters in the barcode.
The ;> which puts the barcode in Subset C is not the default. Subset B or :> is the default which will allow any character to be encoded in the barcode. So you can replace the ;> with :>, or just remove the ;> entirely, and it will print out properly.
Check out the ^BC documentation in the ZPL programming manual for more information about Code 128 subsets and data validation
See pg 92 of the ZPL Programming Guide.
This issue may have been fixed in the firmware update, see below:
Example: This is an example with the mode parameter set to D*:
^XA
^PON
^LH0,0
^BY2,2.5,145
^FO218,343
^BCB,,Y,N,N,D
^FD(91)0005886>8(10)0000410549>8(99)05^FS
^XZ
D* — When trying to print the last Application Identifier with an odd number of characters, a problem
existed when printing EAN128 bar codes using Mode D. The problem was fixed in firmware version
V60.13.0.6."