I have A zebra RZ600 printer and I'm having trouble writing the EPC memory of the new DogBone inlay with the monza 4D chip.
My problem is that impinj has changed the bit function to comply with the Gen2V2 specification as described here.
I've tried to use Bartender 10.1V and Zebradesiner pro V2.5, both are latest and both don't have a solution for this issue.
Side note, I'm printing tags for sporting events so usually I'm writing incrementing hex values to the EPC and print the decimal value on the tag.
Thanks,
Idan.
How i solved it:
print to file the zpl code of the printing job.
change the ^FD1000^FS to ^FD1400^FS (1400 is for 8 bytes EPC or 3000 to 3400 for 24 bytes. it depends on the size of the new EPC data length).
write a script to change the printing detail and the data to write and duplicate it to X number of tags (crate one big file with a zpl code for each tag)
send the file to the printer manualy with bartender
I have a a Sparkfun Max 7456 breakout board that I am trying to rewrite the character table to an ASCII format. I have been following the Arduino + MAX7456 OSD thread but cannot seem to load the .mcm file to the breakout board. I have tried hyper terminal and tera term. Tera term allows me to "transfer" the mcm file but I do not get any type of confirmation in the terminal window. When I try simple sample code like "Hello World.ino" I get no response and the default character set is still displayed. Hyper terminal tells me there is a COM port conflict with the Arduino IDE. I know the steps are available in the above mentioned thread but the picture/ code resources have mostly been removed. I don't know if I'm missing something in the code or if I am not using the terminal program correctly. I have the following connections between the breakout board and the Uno and have been trying Arduino code provided at the start of the thread;
Breakout/ Uno;
CS-->D10
SDIN--> D11
SCK--> D12
SDOUT--> D13
+5V
GND
I have tried using wires that are <5cm and >=10cm and I am using NTSC. Can anybody determine what I am doing wrong or point me in the right direction please. Thanks in advance,
I figured out my issue. Using Google translate I was able to get code from;
http://f5mna.free.fr/Arduiexpert.htm
Previously, I was only making the connections listed in the code when the full list is;
D13--> SCLK
D12--> SDOUT
D11--> SDIN
D10--> CS
+5VDC must be applied to the +5V pin on the board as well as a 1k resistor in series with LOS and a 10k with RESET.
As for using tera term. First shutdown the Arduino IDE and open the connection in the terminal program. The code provided in the above link will indicate it is ready for file transfer and will prompt you with a transfer complete message.
All in all, simple solutions but I was a newcomer to a very old thread. Hope this helps anyone else having the same issues in the future.
I buy customer display that customer display has PL-2303HXD chip. The customer display connect to COM1 to my PC.I can send any number using test software come with that customer display. but I can't display any value using cmd in windows.
In the manual ask to try
C: \> MODE COM1 2400, N, 8,1
C: \> TYPE CON> COM1
in cmd but that not work for me. please tell how can i test customer display using cmd in windows.
Instructions for application:
Use the standard RS232 serial port (baud rate= 2400, parity =none, data bits = 8, stop
bit = 1).
Use international ESC / POS Common set of commands, do not need to install any drivers. Both under DOS or WINDOWS platform, just follow the format of the commandset to send data to the serial port to display the content, without handshake.
First of all, we have an application developed in .Net and used on a Win XP platform for years with very little problems.
We recently switched to Win 7 64bit and we are having issues with labels not printing.
When the user selects a job it may have several products it needs to print per order line.
What is happening, is sometimes labels aren't being printed for an specific order line.
For instance, let's say we have job X with 8 order lines to print.
The application sends the labels to a preview window using crystal reports and then immediately sends it to the printer without any human intervention.
line 4 with quantity 1, doesn't print
line 5 with quantity 1, doesn't print
line 6 with quantity 1, doesn't print
line 7 with quantity 3, doesn't print
line 1 with quantity 1, doesn't print
line 2 with quantity 2, prints
line 3 with quantity 28, prints
line 8 with quantity 1, doesn't print
If this same job is printed on a Win XP PC it doesn't have any problems and all the lines and appropriate quantities are printed.
We are using Zebra setup utilities 1.1.9.1060.
we have a
ZM400 with firmware v53.17.11Z
ZM400 with firmware v53.17.9Z
ZM400 with firmware v53.17.5Z
ZM4Plus with firmware v60.14.3Z
These printers are connected to the PC over the network via a TCPIP address.
Also, we are using Windows driver Z4M 203DPI printer version 2.6.77 (Build 3827)
Let me know any other information you may need.
Thank you,
Tim Caldwell.
i need to tell a printer driver to issue a form feed.
i'm printing directly to a printer using the:
OpenPrinter
StartDocPrinter
StartPagePrinter
WritePrinter
EndPagePrinter
EndDocPrinter
ClosePrinter
set of API calls.
A lot of the inspiration came from KB138594 - HOWTO: Send Raw Data to a Printer by Using the Win32 API. An important point to note in that KB article is that they (and my copied code) start the document in RAW mode:
// Fill in the structure with info about this "document."
docInfo.pDocName = "My Document";
docInfo.pOutputFile = NULL;
docInfo.pDatatype = "RAW";
StartDocPrinter(hPrinter, 1, docInfo);
Note: RAW mode (as opposed to TEXT mode) means we are issuing raw bytes to the printer driver. We promise to talk in the language it understands.
We can then use WritePrinter to write everything we want:
WritePrinter(hPrinter, "Hello, world!"); //note, extra parameters removed for clarity
WritePrinter(hPrinter, 0x0c); //form-feed
The problem here is the 0x0c form-feed character. Because we've opened the printer in RAW mode, we are promising we will send the printer driver bytes it can process. The drivers of most printers take 0x0C to mean you want to issue a form-feed.
The problem is that other printers (PDF printer, Microsoft XPS Printers) expect RAW print jobs to be in their own printer language. If you use the above to print to an XPS or PDF printer: nothing happens (i.e. no save dialog, nothing printed).
i asked for a solution to this question a while ago, and a response was that you have to change the document mode from RAW:
docInfo.pDatatype = "RAW";
to TEXT:
docInfo.pDataType = "TEXT";
Well this probably is because you send
"RAW" data directly to the printer,
and RAW can be any PDL. But the XPS
driver will probably only understands
XPS, and it will probably just ignore
your "unknown: Hello, world!0xFF" PDL. The
XPS driver will probably, if any, only
accept XPS data when you write
directly to it.
If you want to render text on the XPS
driver, you should use GDI. You might
be able to send plain text to the
driver if you specify "TEXT" as the
datatype. The print processor attached
to the driver will then "convert" the
plaintext for you by rendering the job
via GDI to the driver.
So that worked, i changed my code to declare the print document as TEXT:
// Fill in the structure with info about this "document."
docInfo.pDocName = "My Document";
docInfo.pOutputFile = NULL;
docInfo.pDatatype = "TEXT";
StartDocPrinter(hPrinter, 1, docInfo);
WritePrinter(hPrinter, "Hello, world!");
WritePrinter(hPrinter, 0x0c); //form-feed
And then the Save As dialog for XPS and PDF printers appear, and it saves correctly. And i thought all was fixed.
Except months later, when i tried to print to a <quote>real</quote> printer: the form-feed doesn't happen - presumably because i am no longer printing in "raw printer commands" mode.
So what i need is the Windows-ish way of issuing a form feed. i need the API call that will tell printer driver that i want the printer to perform a form-feed.
My question: How to tell a printer to issue a Form-Feed during printing?
Background on Data Types
The print processor tells the spooler to alter a job according to the document data type. It works in conjunction with the printer driver to send the spooled print jobs from the hard drive to the printer.
Software vendors occasionally develop their own print processors to support custom data types. Normally, the print processor does not require any settings or intervention from administrators.
Data types
The Windows printing process normally supports five data types. The two most commonly used data types, enhanced metafile (EMF) and ready to print (RAW), affect performance in different ways on both the client computer and the print server computer.
RAW is the default data type for clients other than Windows-based programs. The RAW data type tells the spooler not to alter the print job at all prior to printing. With this data type, the entire process of preparing the print job is done on the client computer.
EMF, or enhanced metafile, is the default datatype with most Windows-based programs. With EMF, the printed document is altered into a metafile format that is more portable than RAW files and usually can be printed on any printer. EMF files tend to be smaller than RAW files that contain the same print job. Regarding performance, only the first portion of a print job is altered, or rendered on the client computer, but most of the impact is on the print server computer, which also helps the application on the client computer to return control to the user faster.
The following table (taken from MSDN) shows the five different data types supported by the default Windows print processor:
Data type: RAW
Directions to spooler: Print the document with no changes.
Use: This is the data type for all clients not based on Windows.
Data type: RAW [FF appended]
Directions to spooler: Append a form-feed character (0x0C), but make no other changes. (A PCL printer omits the document's last page if there is no trailing form-feed.)
Use: Required for some applications. Windows does not assign it, but it can be set as the default in the Print Processor dialog box.
Data type: RAW [FF auto]
Directions to spooler: Check for a trailing form-feed and add one if it is not already there, but make no other changes.
Use: Required for some applications. Windows does not assign it, but it can be set as the default in the Print Processor dialog box.
Data type: NT EMF 1.00x
Directions to spooler: Treat the document as an enhanced metafile (EMF) rather than the RAW data that the printer driver puts out.
Use: EMF documents are created by Windows.
Data type: TEXT
Directions to spooler: Treat the entire job as ANSI text and add print specifications using the print device's factory defaults.
Use: This is useful when the print job is simple text and the target print device cannot interpret simple text.
You can see the print processors available for a printer, and the data types that each processor supports, through the properties of a printer in the control panel:
See also
Send ESC commands to a printer in C#
Feed paper on POS Printer C#
Print raw data to a thermal-printer using .NET
Yeah, that doesn't work. You are intentionally bypassing the printer driver, the chunk of code that presents a universal interface to any printer. Which leaves you to deal with the peculiarities of each specific printer model.
There are some common interfaces, the one you used in your code is the one that dot matrix printers of old used. PCL is common on Hewlett Packard laser printers. Postscript is common on high-end printers. The latter two have their own incantations to get a form feed.
Then there's the ocean of cheap laser and ink jet printers. They often don't have a well defined interface at all. Instead of having a processor inside the printer that translates printer commands to dots on paper, they let the printer driver do all the hard work. You'll never get one of those going, the interface is proprietary and undocumented.
The printer driver is your friend here. PrintDocument the class to use it. Getting a form feed is easy, just set e.HasMorePages = true and exit the PrintPage event handler. You already saw the StreamPrinter class I linked.
I'm unfamiliar with the TEXT document type, but I presume it's just a lowest common denominator "dumb printer" representation. If so, it might recognize a form-feed character, except you've been using the wrong character - it's not 0x12 or 0xFF, it's 0x0c. See http://en.wikipedia.org/wiki/Ascii
Since my last answer was no help, lets try the obvious. Have you tried doing EndPagePrinter followed by StartPagePrinter whenever you need a page break?
If that still doesn't work you may need to do it the hard way, using GDI. The stack looks just slightly different from the one you're using:
CreateDC
CreateFont
SelectObject
StartDoc
StartPage
TextOut
EndPage
EndDoc
DeleteDC
You'll be required to manage a font and place the text on the page yourself at each line position.