TimescalePlaying around with various methods to determine a workable more advanced method to control the HP 5N printer, I have come to realize how naive we were back in the 90's. So I figured I might be able to use the syslog server functionality of the printer to actually get the data I need to figure out the state of the printer and this is partially true, but seemingly nobody ever thought it a good idea to actually log jobs! I can find no way to "set" the log level.
So now I have a nice centralized log on my Raspberry Pi on whether or not the covers are open or not! This DOES report paper jams and is there for useful to stop the script from turning off the printer when something goes awry, but it tells us nothing about starting or finishing a job. Why?Anyway, I stated in the description of this project that CUPS does not count pages.. This is apparently not true. I can't find any evidence in any log of numbers of pages, but when running "lpstat -p" in a loop, it got me this :
I definitely see some pages and percentages going on there. If I could catch that data and distil the highest number, adding some margins, I could come pretty close to the correct amount of time needed to print the batch and power off the printer after cool down.
I did play around with printing multiple blank pages, both as one document and as one page duplicated a number of times, and as I suspected, the spooler queue is useless to determine anything other than "A job has been added".
At this point in time, I think the most effective way forward is to do something like this.
- Check for job
- Job detected, power on printer and start scanning lpstat -p for page count
- determine power on time from page count
- continue checking syslog for errors
- if error occurs, stop script from turning off printer.
In this scenario, a print would always be ready with the printer neatly turned off unless it ran out of paper or had a jam.
So we found out where the "hack" lies. Good times.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
That sounds like the CUPS driver is reading the reverse status data strream on the port 9100/TCP connection. You might want to use wireshark to view what status info is sent back, whether CUPS is reporting only some in syslog, and whether you can get it to report more.
Are you sure? yes | no
That might be entirely the case. The line "Printing page N, XX%" is not logged anywhere. That could just as well come from the 5N.
I have Wireshark set up on my RPi4 desktop system! I'll try tomorrow!
Unfortunately this would indicate a solution that is very brand or even device specific. It seems that TEA4CUPS is the way to go, but I'm intrigued.
Are you sure? yes | no
If you find that CUPS isn't reporting all status information you could write a daemon that you interpose between the 5N and CUPS. It would listen on port X/TCP and pass all print data to the 5N at port 9100/TCP, and read all status data from the printer at port 9100/TCP, syslog the missing status reports, and pass the rest up to CUPS on port X/TCP. CUPS would be told that this virtual printer talks at port X/TCP instead of the normal 9100/TCP.
Are you sure? yes | no