2 Replies Latest reply on Mar 29, 2017 11:16 AM by Mina Mohsen

    Paper Feed and Queueing with Bluetooth Printing

    Adam Hill

      I am using the IMZ320.


      First off, a simple question that is puzzling me. (Seemingly) without any setup from me and just sending simple text strings to the printer, it feeds out about 6-7 inches of blank paper then prints at the end.


      Surely this is not normal.


      I have tried resetting the printer to factory defaults and running through the  Zebra Setup Utilties -> Configure Printer Setting setup without any luck. I am using the Open Communications feature in the Utilities in Windows to test, via sending ZPL. I also tried to print via Bluetooth in iOS. Same result. All the commands do what I expect., it just feeds out half a foot of paper before it does.


      Next. If there is no paper in the printer on the IMZ320, and I try to print via the SDK with Blueetooth, should it hold on to the print command and print it once there is paper in the printer? I noticed there are ZPL commands to print multiple and reprint the last thing printed, but when I ran the iOS sample app and tried that scenario, it did not start printing once there was paper in the printer.



        • Re: Paper Feed and Queueing with Bluetooth Printing
          Robin West

          Hi Adam,

          To answer your question about the feeding 6" before printing is a simple setup issue.  You need to set a label length if you are printing in ZPL.  Most of the time it's part of the ZPL you send to the printer for the print job as it can change depending on what you're printing.  The command is ^LL.  EDIT: You may sometimes also have to tell the printer that it's using continuous receipt paper.  The command for that is ^MNN.  So to send a short line of text you can send:

          ^XA^MNN^LL70^FO20,20^A0N,30,30^FDHello World^FS^XZ

          If you don't set the ^LL command, it uses the default of 6".


          For your other question, yes, the printer is fully capable of essentially buffering several print jobs while the printer is not in a state where it can print.  We do highly recommend checking the state before sending a print job so you can give your users feedback on why it's not printing and because eventually the buffer will fill up.  There are several ways to do this, but the easiest is to send and parse the response from the ~HS command or use the SDK's built in getCurrentStatus() functionality.  This command can be sent at any time if the printer is printing or not and will work with almost our whole product line.

          Hope this helps,