Hey guys,
I'm working in a JS environment trying to find a reliable way of monitoring / controlling the print job progress on a GX420d (V56.17.17Z). So no, unfortunately no sparkly LINK-OS magic here. The printer is tucked in to our network and i'm communicating with it via PHP socket sending raw ZPL/SDG commands. Each interaction opens a socket and closes it afterwards.
The logic in the frontend is as follows:
get the printer identification (~HI), make adjustments
prepare a list of print jobs (1-n formats in ZPL)
loop through all the formats to print and:
on every iteration first get the printer status (~HS) → if problems like "paper out" notify user in frontend (dialog) and wait for confirmation, to restart the loop
if no problems → send format
wait 1 second (currently just pretending it's been printed)
if more formats in list → restart loop
The problems i'm listening on are: "head open", "ribbon out", "paper out", "buffer full" and "paused"
It's obvious now that waiting 1 second (3.3) before checking the printer status again for the next format is not reliable, because there's many different reasons why the actual physical print can be delayed and I would be reading the printer's status "too early". This means that if the printer runs out of paper, i wouldn't be able to tell before sending the next format.
The ultimate goal here is to be able to tell when the previous format has finished printing and only then restarting the loop.
I could be periodically checking for the "formats in receive buffer" and only restart the loop if it reaches 0, but what if (and that's a realistic use-case) another client is sending formats to the printer as well. The counter might never reach 0 then. On top of that I observed that sometimes '"formats in receive buffer" shows 1 even though there's nothing left to print nor any internal problem keeping the printer from printing that last format.
I'd very much appreciate if you guys could share some wisdom and help me find the last piece of the puzzle.
Cheers.
1 Replies
There's no built-in way to know when a specific print job has completed (with or without an error), that would be the job of a print spooler service. In a way, that looks similar (to some extent) to what you're building, so here are some suggestions:
Have you validated that ~HS will give you a response in all the scenarios you're listening on? The documentation ( https://www.zebra.com/content/dam/zebra/manuals/printers/common/program… ) indicates that ~HS will not send back a response if the printer is in one of a number of error states (MEDIA OUT, RIBBON OUT, HEAD OPEN, REWINDER FULL, HEAD OVER-TEMPERATURE). ~HQES is an alternative command you may want to look into.
If you want to coordinate across multiple clients sending to the same server, you may want to implement spooling on your server. You can receive print jobs from the clients in a central service and add them all to a queue, so there's really only one client talking to the printer (your central service). That central service can then process print jobs from all clients in order so none of the clients can be starved.
If you don't want to have a single central service do the printing but still want to coordinate among clients, if you're already using a SQL database in your project, you can use the DB as a distributed lock. Clients would attempt to acquire a lock before printing and release it afterwards. If a client cannot acquire the lock because some other client has it, it has to wait until the lock is free, so there's again only one client talking to the printer at any given time.
Another alternative could be to, instead of sending multiple print jobs, build a single print job that consists of multiple pages and doing everything in one go.
Will any of those help with your use case?
Javier Molina
Technical Architect, Kutir Mobility
Posted on behalf of Zebra Technologies