I have an old Zebra 170Xi that I would like to use to print labels. Note: it is an plain Xi, not Xi4, XiIII, XiIII plus, or even XiII, so it is old.
I know it "works" because at least printing test stuff from the menu does write labels as expected. I have not been able to print anything programmatically.
I've tried the equivalent of a ZPL hello world to the COM port with some redirection on the command line, but nothing came out.
Can someone give a pointer to at least bootstrap sending commands to the printer?
Perhaps you'd like to post your "Hello World"
This one should work:
^XA
^LH30,30
^FO20,10^AD^FDHELLO WORLD^FS
^XZ
Make sure there are no clever drivers - run the port as Text/Generic.
And use a text-editor to create the file above; simply copy it to the printer-port.
Oooh - that may be the problem. If you're using CMD then ^ is an escape character, so
echo ^XA
needs to be
echo ^^XA
Yeah - tough old brutes the 170Xi - got my Zebra stripes on them back in '95...
Related
In our space we use an ACUCOBOL-GT written program which pushes variables such as PHY NAME to a written format. The program then replaces said PHY NAME with the actual name of the pharmacy and then cups pushes the data onto the label, producing an readable output. We use zebra printers with EPL written label formats to print out these pharmacy medication labels.
Recently I wrote a format using ZPL to produce the same label as Im able to customize the data better than with the old EPL.
The only issue Im running into is that now with the ZPL the data prints onto the label between quotation marks.
So instead of it being eg Montagu Pharmacy it prints out as "Montagu Pharmacy ".
an example of the old EPL code is as follow : PHY NAME A010,025,0,4,1,1,N,
and the output of said code is as follow : A010,025,0,4,1,1,N,"MONTAGU PHARMACY "
on the output before printing it shows the quotes as well but as soon as you send it to the printer it removes the quotes and prints without them.
Here is an example of the ZPL code : PHY NAME ^FO100,025,0^A0N,18,30^FD
and here is the output of said code : PHY NAME ^FO100,025,0^A0N,18,30^FD"Montagu Pharmacy "
on the output before printing it shows the quotes and when it prints out onto the label it prints the text along with the quotes.
I understand that the ACUCOBOL-GT program creates the data with the quotations but the EPL never printed them out but the ZPL does.
Is there anything Im doing wrong or that I can do to remove the quotes so that it can print out normally as before.
I would really appreciate any assistance.
Kind regards
Hans Steyn
This is because in EPL the "DATA" to be printed is surrounded by quotes("), while in ZPL it is not, so quotes are printed. You need to remove the quotes as follows:
PHY NAME ^FO100,025,0^A0N,18,30^FDMontagu Pharmacy
References:
EPL (A command)
https://www.servopack.de/support/zebra/EPL2_Manual.pdf
page 41
ZPL (^FD command)
https://www.zebra.com/content/dam/zebra/manuals/printers/common/programming/zpl-zbi2-pm-en.pdf
page 172
EDIT 1
As per your comment, AFAIK there is no way to remove the quotes after the command reaches the printer. So the only way is to have your supplier's software send the command to some custom tool/software you have that will strip the quotes then relay the message to the printer.
[supplier software] -> [custom software] -> [Printer]
I don't know their software, but they could generate a text file that your custom tool would load and remove the quotes for example with a regex like this, that even allows for escaped quotes in the middle of the name if there are any (arrows):
This being said, it is quite surprising that removing quotes requires massive development, especially because they already seem able to generate both EPL and ZPL.
I'm having a couple of issues with the most simple code I ever wrote in Ruby.
Let's get straight to the example:
# encode: utf-8
`chcp 65001`
puts "Write something with accents such as àòèùì, or €"
asd = gets
puts asd
If I run this code I get two issues, and both of them are totally incomprehensible to me at the moment.
The first one is that if I enter something such as à, the program will write a new line and not give anything as output. If I press enter again, then it'll output a couple of unreadable characters.
See the pic here as example:
Second issue: if I type € the terminal will just crash, even before pressing enter. Of course I can't attach a screenshot for this one.
Note that the terminal does not crash if I type € while note executing this program. It only does it if I type it while executing it.
I tried to change the default terminal encoding from CP850 to UTF-8, but that didn't change anything. So now I'm back to CP850, since UTF-8 support in the terminal is beta. And the chcp 65001 successfully changes the encoding to UTF-8 anyway.
How would you proceed?
EDIT 1:
It appears to me that the chcp 65001 is successfully chaning the terminal's encoding. In these screenshots, the first one being taken before executing the program and the second being taken after, you'll see that the "Tabella codici corrente", aka "Current code table", has actually changed from CP850 to UTF-8.
EDIT 2:
This simplified MWE will still give the same result:
puts "Write something with accents such as àòèùì, or €"
asd = gets
puts asd
Can't print the label correctly. There is some extra spaces in the ZPL text field.
There are some spaces between the text fields in line 2 and line 4.
Please kindly help.
^XA^LL496
^PW711
^FT16,50^A0N,20,19^FDL-01,02,03^FS
^FT16,100^A0N,20,19^FDU-01,02,03^FS
^FT16,150^A0N,23,24^FDUSER ID:admin^FS
^FT16,200^A0N,23,24^FDPromise Date:02/15/16^FS
^FT16,250^A0N,23,24^FDDate of Request: 11/14/19 01:48PM^FS
^PQ1,0,1,Y^XZ
Result:
L-01,02,03
U- 01,02,03 <-- Extra space
USER ID:admin
Promise Date:02/15/16 <- Extra space here
Date of Request: 11/14/19 01:48PM
My Zebra printer : Zebra Z4Mplus 203DPI
I have found this message from internet :
http://support.efficientbi.com/knowledge-base/extra-spaces-in-label-text-appear-when-sending-zpl-commands-direct-to-windows-generic-printer-driver-zebra-problem/
"When testing sending ZPL print commands direct to a Zebra printer using Generic Windows print driver, it we noticed that sometimes extra spaces would appear in the sample label. After some research, it was determined that it appears the Generic Windows print driver will cause these extra spaces to be inserted when the ZPL code is sent WITHOUT CRLF breaks."
I am using the "Generic Windows print driver" for my Zebra printing.
Here is the link that I used :
JavaScript: Send raw text to printer - no server requests/method calls, able to work offline, purely clientside
The output format totally mess up in the Zebra printing. On the other hand, the Labelary looks good to me though.
I am using the Java Vaadin framework and call the javaScript to print the ZPL command to use the "Generic Windows print driver". It worked but the format did not look to me. Extra spaces everywhere and some text did not show up at all but it looks OK in Labelary though.
I tried to print the label in client machines with Zebra printer for my Java Vaadin server side application and I finally able to make it printing but don't know why the format looks totally unpredictable.
My label size is : 3.5 inches X 2 inches label.
I can print the whole field now but still got extra space on the output.
^XA^LL496
^PW711
^FT16,209^A0N,20,19^FH^FDL-01,02,03^FS
^FT16,169^A0N,20,19^FH^FDU-01,02,03^FS
^FT16,249^A0N,23,24^FH^FDUSER ID:admin^FS
^FT16,289^A0N,23,24^FH^FDPromise Date: 02/15/16^FS
^FT16,329^A0N,23,24^FH^FDRequest: 11/14/19 01:48 PM^FS
^FT16,369^A0N,23,24^FH^FDMatl: ST30^FS
^FT7,101^A0N,113,112^FH^FDX^FS
^BY4,2.5,59^FT131,87^B3N,N,,Y,N
^FD2246284^FS
^PQ1,0,1,Y^XZ
Here is the image: There are some extra spaces in the print label from Zebra printer.
enter image description here
I know it's an old question.
I had similair problem printing through cups, turned out the default options had margins set in them. Setting them to zero and Long Line Handling to 'Wrap at Right Edge' fixed my problem:
Finally I am able to get rid of this extra spaces by adding \ +\n string at he end of each java script statement.
We need two \\ characters, the first \ character as the escape character to make it working.
Finally I am able to get rid of this extra spaces by adding \ +\n string at he end of each java script statement. We need two \ characters, the first \ character as the escape character to make it working.
I've created my ZPL string and at the very end appended ^PQ+numCopies. Debugger shows the whole string correct with ^PQ3 at the end. But the printer only prints 1 copy.
Printer is a 110Xi4 and the onboard configuration shows it's in ZPL II mode.
Thanks
The ^PQ3 needs to be before the ^XZ, not after it. the ^XZ should be the last thing in the label
There is a specific order in which ZPL commands need to be present in the document source in order for them to be effective (or for the document to print at all), as Ovi points out.
A ZPL document will look like (omit everything from the # to the end of that line):
^XA # start of document. Not optional
#optional one-off config stuff, for example:
^MNM # setting the media sensor for black bar
^PW200 # setting print width
# now include your actual label/document content
^FDText that is going to be printed^FS
^XZ # end of document. Not optional.
If you include the ^PQ3 after ^XZ, the printer does not know what to do with that command. It's probably just discarded.
I will link to other examples and docs when I get some time.
I have a specific method for my bash prompt, let's say it looks like this:
CHAR="༇ "
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
To explain the above, I'm builidng my bash prompt by executing a function stored in a string, which was a decision made as the result of this question. Let's pretend like it works fine, because it does, except when unicode characters get involved
I am trying to find the proper way to escape a unicode character, because right now it messes with the bash line length. An easy way to test if it's broken is to type a long command, execute it, press CTRL-R and type to find it, and then pressing CTRL-A CTRL-E to jump to the beginning / end of the line. If the text gets garbled then it's not working.
I have tried several things to properly escape the unicode character in the function string, but nothing seems to be working.
Special characters like this work:
COLOR_BLUE=$(tput sgr0 && tput setaf 6)
my_function="
prompt="\\[\$COLOR_BLUE\\] \"
echo -e \$prompt"
Which is the main reason I made the prompt a function string. That escape sequence does NOT mess with the line length, it's just the unicode character.
The \[...\] sequence says to ignore this part of the string completely, which is useful when your prompt contains a zero-length sequence, such as a control sequence which changes the text color or the title bar, say. But in this case, you are printing a character, so the length of it is not zero. Perhaps you could work around this by, say, using a no-op escape sequence to fool Bash into calculating the correct line length, but it sounds like that way lies madness.
The correct solution would be for the line length calculations in Bash to correctly grok UTF-8 (or whichever Unicode encoding it is that you are using). Uhm, have you tried without the \[...\] sequence?
Edit: The following implements the solution I propose in the comments below. The cursor position is saved, then two spaces are printed, outside of \[...\], then the cursor position is restored, and the Unicode character is printed on top of the two spaces. This assumes a fixed font width, with double width for the Unicode character.
PS1='\['"`tput sc`"'\] \['"`tput rc`"'༇ \] \$ '
At least in the OSX Terminal, Bash 3.2.17(1)-release, this passes cursory [sic] testing.
In the interest of transparency and legibility, I have ignored the requirement to have the prompt's functionality inside a function, and the color coding; this just changes the prompt to the character, space, dollar prompt, space. Adapt to suit your somewhat more complex needs.
#tripleee wins it, posting the final solution here because it's a pain to post code in comments:
CHAR="༇"
my_function="
prompt=\" \\[`tput sc`\\] \\[`tput rc`\\]\\[\$CHAR\\] \"
echo -e \$prompt"
PS1="\$(${my_function}) \$ "
The trick as pointed out in #tripleee's link is the use of the commands tput sc and tput rc which save and then restore the cursor position. The code is effectively saving the cursor position, printing two spaces for width, restoring the cursor position to before the spaces, then printing the special character so that the width of the line is from the two spaces, not the character.
(Not the answer to your problem, but some pointers and general experience related to your issue.)
I see the behaviour you describe about cmd-line editing (Ctrl-R, ... Cntrl-A Ctrl-E ...) all the time, even without unicode chars.
At one work-site, I spent the time to figure out the diff between the terminals interpretation of the TERM setting VS the TERM definition used by the OS (well, stty I suppose).
NOW, when I have this problem, I escape out of my current attempt to edit the line, bring the line up again, and then immediately go to the 'vi' mode, which opens the vi editor. (press just the 'v' char, right?). All the ease of use of a full-fledged session of vi; why go with less ;-)?
Looking again at your problem description, when you say
my_function="
prompt=\" \[\$CHAR\]\"
echo -e \$prompt"
That is just a string definition, right? and I'm assuming your simplifying the problem definition by assuming this is the output of your my_function. It seems very likely in the steps of creating the function definition, calling the function AND using the values returned are a lot of opportunities for shell-quoting to not work the way you want it to.
If you edit your question to include the my_function definition, and its complete use (reducing your function to just what is causing the problem), it may be easier for others to help with this too. Finally, do you use set -vx regularly? It can help show how/wnen/what of variable expansions, you may find something there.
Failing all of those, look at Orielly termcap & terminfo. You may need to look at the man page for your local systems stty and related cmds AND you may do well to look for user groups specific to you Linux system (I'm assuming you use a Linux variant).
I hope this helps.