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.
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 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 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.
Many printers have a "feed and cut" or "cut paper" command (I'm talking about POS - printers here).
Since using POS.NET is not always possible (horrific driver incompatibilities) and GDI can do so much more, we would like to utilize the paper cutter also when printing using GDI.
Is there a way to do so? Possibly when issuing EndDocument()?
Or maybe even from .NET?
GDI and even the abstract Windows printing model are probably not going to help you here. You're going to have to send the feed and cut command to the printer in the language that it expects to typically receive data.
For example, an Epson TM-T88III thermal receipt printer speaks the ESC/POS language natively, not a sequence of GDI or PCL commands. However, most of these printers do come with printer drivers that make Windows see them as regular GDI printers. The way these drivers typically work is that they rasterize all of the GDI commands into one big bitmap in software, and then dole out the bitmap to the printer for printing via its native-language "print the bit-image" command. This usually has less-than-desirable effects:
It is much less efficient (in sense of time required and data transmitted) to send a lot of bitmap data to the printer than a sequence of binary commands that it knows how to interpret. (Would you rather send an image of text to print, or just the actual text and a font size specification? Analogies with HTML/CSS vs. an image of text.)
These printers typically have low resolutions and are monochrome (that is, all black or all white, no grayscale or color). Their pre-loaded fonts are designed to work well under these limitations for crisp, clear rendering. By rasterizing to a bitmap, we lose this careful design as pixels are snapped and rounded off of the grid, resulting in jagged text rendering on the actual printout. If you're trying to draw something that's really sensitive to this kind of rounding, like a barcode, you're SOL, unless you're painstakingly keeping the DPI of the printer device context in mind while working with GDI.
For example, here is a snippet of code from an extensive example on my usually-irrelevant blog. You can see near the end how I fill the BinaryWriter with the necessary sequence of bytes that equals the "feed paper and cut" command on our Epson thermal receipt printer (AsciiControlChars is just a static class with constants):
using (var ms = new MemoryStream())
using (var bw = new BinaryWriter(ms))
{
// Reset the printer bws (NV images are not cleared)
bw.Write(AsciiControlChars.Escape);
bw.Write('#');
// Render the logo
RenderLogo(bw);
// Feed 3 vertical motion units and cut the paper with a 1 point cut
bw.Write(AsciiControlChars.GroupSeparator);
bw.Write('V');
bw.Write((byte)66);
bw.Write((byte)3);
bw.Flush();
return ms.ToArray();
}
You can then just send the bytes directly to the printer as a RAW document, either using the code at the end of that article, which works against various Win32 printer functions, or Microsoft's RawPrinterHelper class.
You'll need to look up the commands specific for your printer. Chances are that its not too different from the one that you see here: POS languages are beginning to standardize, but that's also like saying SQL is a standard--mutually intelligible by humans but not really interoperable without some adjustments.
If you really still want to use GDI, you can print the GDI document in the usual way to the printer (again, assuming that a GDI printer driver exists, which it probably does), and then issue a second, small, RAW document to the printer that contains the native feed and cut command. (Alternatively, some of the GDI printer drivers let you specify "always cut after printing a document" right in the Printers control panel--but good luck accessing that driver feature in a well-documented fashion programmatically!)
Hope this helps to paint a picture of GDI's relationship to POS printers.
When using the lp -o orientation-requested=6 in CUPS to print a postscript file, the first page is reversed 180 degrees and then the next page is back to 0 orientation. Third page has the 180 degree rotation and fourth page back to 0 and so on. I need each page in the file to be reversed 180 degrees. Any suggestions on what to try would be most appreciated.
If your PostScript file does not conform strictly to the PostScript DSC (document structuring convention), and the file is being sent to a PostScript printer, then whatever extras that CUPS may add to the pages may be getting overridden by ill-behaved per-page stuff in your document. Unfortunately there's no particularly good fix for overcoming arbitrary ill-behaved PostScript code. (The rotate-every-other-page or rotate-every-page-an-extra-180 behavior supports this via.
If it's your own application that's generating the PostScript file, you might benefit from comparing what you pipe into the spooler against what CUPS actually sends to the printer (you could capture it with netcat).