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.