I'm developing a Windows application in WPF, which uses the "link-os" SKD to print a large amount of tickets over a USB connection with a Zebra GC420t. The problem is that during printing, the printer apparently loses the detection of the black mark and begins to print the content in a wrong position relative to the top of the ticket.
Important points:
My software build a ZPL string in runtime and sends it to the printer;
I'm using the "GC420t" driver (non EPL);
Before starting the print job, I send to the printer some print settings:
"~SD15~TA000~JSN^XA^SZ2^PW639^LL799^PON^PR2,2^PMN^MNM^LS0^MTT^MMT,N^MPE^XZ^XA^JUS^XZ"
At the beginning, the printer is correctly calibrated. Sometimes, when the problem reported in this post happens, the printer becomes uncalibrated.
Below, a ZPL sample code, and the link to a video that demonstrates exactly the moment the error happens. Every help is welcome.
Video: Zebra GC420t error while printing
Zpl String:
~DYE:LOGO1,P,P,34149,,89504E470D0A1A0A0000000D49484452...(Intentionally truncated)
^XA^LS0^LT0^XZ
The statement below is repeated for each label:
^XA
^FO70,0^IME:LOGO1.PNG^FS
^FO57,230^GB533,0,2^FS
^FT0,261^A0N,31,31^FB620,1,0,C^FDEVENTO TESTE^FS
^FO57,272^GB533,0,2^FS
^FT0,294^ACN,18,10^FB620,1,0,C^FD^FS
^FT0,316^ACN,18,10^FB620,1,0,C^FD01/09/2019^FS
^FT0,379^AAN,18,10^FB620,1,0,C^FD^FS
^FT0,431^AAN,27,15^FB620,1,0,C^FDR$ 10.00^FS
^FT0,529^AAN,18,10^FB620,1,0,C^FD^FS
^FT0,510^AAN,18,10^FB620,1,0,C^FD^FS
^FT0,492^AAN,18,10^FB620,1,0,C^FDInformau00e7u00f5es sobre o seu evento!^FS
^FT564,475^ABB,11,7^FH^FD008403615029^FS
^FT0,356^ABN,25,14^FB620,1,0,C^FDREFRIGERANTE^FS
^FT67,569^ABN,11,7^FH^FDPDV: TICKET SIMPLES ESC. 29/12/2018 00:50^FS
^FO57,582^GB533,0,2^FS
^FT0,649^ABN,22,12^FB655,1,0,C^FDREFRIGERANTE^FS
^BY3,3,61^FT172,717^BCN,,Y,N^FD>;008403615029^FS
^FT76,472^BQN,2,4^FH^FDLA,008403615029^FS
^XZ
The above statement is repeated for each label.
Thank you all!
Apparently the problem was solved when I set a more precise value for the label size.
I was setting the height of the label to 100mm, when in fact it measures 107mm.
After I made the adjustment, the problem did not happen again.
[EDIT]
Although the procedure described above has considerably reduced the occurrence of errors, even at a lower frequency, it persists. In contact with Zebra's support, we discovered another possible cause: the texts and logos on the back of the ticket are confusing the sensors of the printer (black mark). We're working on the redesign of the label. I will update this thread again soon.
Related
How is this technique implemented?
I noticed that they(like Bartender) don't directly concatenate commands like ZPL (etc.).
And also they don't use bitmap(GDI,GDI+ images) transfer to printer-driver.
Printer-based Serialization In print jobs that include serial numbers, many printers can accept a starting value and the incremental
step size. When you use this printer-based serialization, you can
print a large number of serialized items without having to send any
data after the first label.
Printer-based Barcodes Printers that have built-in barcode functionality make it possible for software programs to request
complex barcodes by using simple text strings (such as “1234”). This
process is much faster than sending bitmap images (or pictures) of
barcodes that consume hundreds or thousands of extra bytes per printed
item. (When you use software other than BarTender, our driver fonts
give you some limited functionality.)
Printer-based barcodes are, as you mention, barcodes that have the symbology / definition stored in the printer firmware. Much like a DLL that you give "12345" and as a result gets a bitmap, an SVG file etc etc.
Many modern label printers know a bunch of common symbologies such as EAN, DM, QR, UPC and similar.
The benefit is obviously that it makes transfer of data much more efficient. Instead of sending a (large) image for every print, the software just sends initial definition (layout, symbology choice and options, ..) + the value needed. Taken to the next level, the printer could receive metadata such as "take this layout, make 500 labels, and in the barcode start at 1, increase 1 every label".
Some disadvantages are
is that the appearance is left to the firmware designer of the printer firmware
There may be less coordination between what's being designed and what's being printed, although typically the driver for the printer should adress this.
The printer firmware may not be updated if the barcode symbology specifications has been updated
The printer firmware may contain only a subset of the barcode definition
In short, simplificy vs freedom of parameters and appearance.
How it is technically implemented (at printer end, from receiving the number to drawing the actual barcode) is probably out of scope for this forum.
Example specification (in newer printer model)
Looking at a random Zebra Printer (ZT600) the built-in barcodes covers nearly every use:
1D symbologies
Code11, Code39, Code93, Code128 (all subsets),
UCC, ISBT, UPC, EAN 8 / 13, UPC/EAN extensions,
Plessey, Postnet, 2of5, Logmars, MSI, Codabar and Planet Code
2D symbologies
codablock, PDF417, Code49, Datamatrix,
QR, TLC39, MicroPDF, RSS14 +composite and Aztec.
When you print an element on a label (barcode or text) you can do that by sending a graphic field or by instructing the printer to pick up the element internally and build the element with the configuration you need.
For example, in case you want to print a text, the ZPL command will include the font you want to use, vertical and horizontal size, position of the text and so on.
In the case of a barcode, the barcode selector contained in the ZPL command, will automatically recall the .BAR file stored in the Z memory, which contains the instructions for the printer to build the barcode, then, in the same command and likewise for the text, you have also provide the size of the barcode (usually it's a ratio between the narrow and the bold line), the position, the human readable line and so on.
The graphic method is used for example when a font which is not stored on the printer memory is used: the printer doesn't recognize the font and so it can't build the text, so the print can happen only after a conversion of the text field into a graphic field. This works well with text fields, but the barcodes can have quality issues as, due to how a thermal printers physicall works, the lines of a barcode can be printed like a sort of saw. Moreover you can't see or edit the data since the code is basically unreadable, that's why it's impossible to send serialized data, unless you use a software.
The element printing is not affected by this type of quality issues and allows you to edit the data.
If you want to see the difference, try to use zebradesigner and print to file a label with a barocode. When you select a barcode, you can choose to print it as a graphic or to use the printer element and you'll see that the .prn files will contains different data.
This is what you get using the printer element (128 barcode containing 123456789012)
https://justpaste.it/66gvp
and this is the same barcode printed as graphic field
https://justpaste.it/27abu
I have a problem that I can't seem to get rid of.
When a customer of mine prints a specific QRP, he gets a "WARNING. This report may extend beyond the printer page margins. Text may be clipped, depending on the printer in use. Do you wish to continue?"
While of course in no way critical, it's a problem due to the sheer number of prints per day this customer has, having to confirm this dialog every time.
I've had this issue before and seemed to be able to fix it by setting the report format to "Custom", but I've recently updated the QRP and the problem is back despite being still set to "Custom". I have also tried A4 (which is the printer's standard page format) and A5, to no avail.
Is there maybe a way to suppress this error in code?
The report itself is way smaller than A4 (it's an A5 format packaging label) so there is no way it would lead to any problems with the print margins, and the prints do come out perfectly fine.
You can use the constant RPT_PrintNoWarn along with SalReportPrint function. The constant is used for suppressing warnings about margin overflow and tiled pages.
It can be combained with constant RPT_PrintNoErrors using pipe symbol.
SalReportPrint ( hWndFrm, strTemplate, strVariables, strInputs, nCopies, RPT_PrintNoWarn|RPT_PrintNoErrors, nFirstPage, nLastPage, nErr )
I created a label program using C# and the Zebra SDK. It works great except when a user desides that they printed the wrong labels and they power off the printer. When the printer comes back on, it goes through a quick calibration (I believe that's what it's doing) and then the light changes to a solid green. When they try to print again, one label prints correctly and then two blank labels "print" and the status light changes to a blinking red light. In order to get the printer back into a working condition, it needs to be recalibrated and I use the ZPL command ~JC.
We were using ZebraDesigner software to print labels and the printer never had issues with being powered off, back on and then printing as normal. I captured the data that is printed from that software and added the ZPL to my code but it doesn't help the printer recover when the printer is powered off. I don't know if the ZebraDesigner software is actually sending multiple sets of commands and I'm only capturing the last set or not.
It was suggested to me on another forum that the printer might still have some of the old ZPL data from the last print job and it would need to be cleared. The last thing I tried was adding the soft reset command ~JR to my code but it didn't help. I also tried to clear anything in the buffer using ~JA with no different results.
Here is is my original ZPL code and it does not include the ZPL that I captured from ZebraDesigner becuase it didn't help. I've gone through the ZPL guide multiple times and I'm just not having any luck figuring out what I'm missing that isn't allowing the printer to recover without being calibrated.
All words in {} are replaced by the actual values when imported into my program.
^XA
^PW330
^FO 0,65
^FB 350,1,0,C,0
^A0N 25, 25
^FD{COMPANYNAME}^FS
^FO 0,90
^FB 350,0,0,C,0
^A0N 28, 28
^FD {PRICE} {COLOR} ^FS
^FO 0,120
^FB 350,1,0,C,0
^A0N 25, 25
^FD {TYPE} ^FS
^FX FO 0,215
^BY2
^FT85, 215
^BCN,60,Y,N,N
^FD>9{BARCODE}^FS
^PQ{QTY}
^XZ
After more testing, I found the command. It's ^MNY
I found it by running through the file generated by Configure Printer Settings in Zebra Setup Utilities. I ran that ZPL with my ZPL and it fixed the issue. I then narrowed down the code until I found the command that allowed the printer to contiue to function after being turned off. I did see this command in the ZPL guide and thought I tried it but maybe I messed something up.
I'm developing a cashier application using Delphi 7 and QuickReport 3.0.9.
The problem is the printing module is limited to the size of the component length in the form, so when the user prints a very long list of item, some of the items will get cut off. The printer is a special printer for cashiers (I don't know the correct name for this printer) that uses a roll of paper, so the printout length should be unlimited.
How do I set the printout length to unlimited? I already emptied the QuickRep1 - Page - Length property but it's still cut off at some point.
Unfortunately you cannot do it with QuickReport v3.0.9.
Support for continuous paper has been introduced with QuickReport v5 update:
Continuous paper. A new property of TPage, Continuous adds support for printing from rolls
When you set the Continuous property to true, the report should not contain any newpage commands.
We have a POS application we have developed that can use any ESC/POS printer via MS POS.Net v1.12. Our application runs fine with Epson printers, but with a Star TSP700 it prints correctly, but it "stutters"/line-by-line (think calling PrintNormal repeatedly rather than using a StringBuilder and dumping it all at once into the queue). Setting the dip switch to what should be ESCPOS emulation does nothing, as I don't think the USB interface supports that according to the docs found on page 98 of https://www.star-m.jp/eng/service/usermanual/tsp700um.pdf. I am building a string and dumping it all at once using Transaction printing in OPOS. The print speed to the customer is unacceptable and replacing 100 printers is also not acceptable. There is another mode we use to connect to the printer aside from OPOS, and that is setting up the printer as a "Generic / Text Only" printer and then I send the escape codes to the printer, but it doesn't print everything out correctly at all - I imagine this is because the printer is expecting Star Line commands.
Phew. Anyone have any input on what to try? Worst case scenario I build in printing via Star commands, so all is not lost, and I'm going to try HexDump mode first to see if I am missing anything, but I would much prefer to not write out a whole library just to handle Star printers if I can avoid it.
ESC + | + N on an Epson printer resets the font to normal after setting it to big, bold, etc. However, this causes the Star to stutter to the point of shaking violently. I was able to remove that escape sequence from my code and have it not affect the output from Epson printers, so now the Star stutters less. Note, it doesn't stop stuttering, it prints 50 lines, flips out for 2 or 3 lines, and repeats. It's really a huge improvement if you are able to see the printer print before and after the fix.