Speed up Canon SELPHY printer / add support for second printer

[maehw]

Hi @ClemensElflein ,

I guess that you currently don't have time for self-o-mat. However, there may be a chance that you find time to provide background information or assistance. I am willing to develop changes myself if I find the time.

The professional, costly printer mentioned in the wiki Mitsubishi Electric CP-D70DW may for sure work better and more reliably than the Canon SELPHYs. IIRC I was not very happy with the prints taking very long and the printer queue getting longer and longer. The later the evening, the longer you have to wait for the prints.. it may take minutes.

1. Do you have an idea how one could collect metrics for average and worst case print times from the print queue (to confirm my observations)?
2. Does somebody share the same experience? Can you guess why? Is this due to the printer (firmware)?
3. Do you have any idea for countermeasures like down-sizing images taken by the camera because the resolution of the printer will be a different one... and (the printer? the printer driver?) needs to down-size them anyway?
4. Would adding a second printer help so that the print jobs can be distributed? One print job going to printer A, the next print job going to printer B, then A again and so forth -- so that self-o-mat could print in parallel. How would you estimate the time to make those changes (source code modules to touch, etc)?

PS: Is there any chance to migrate old content from the website https://www.self-o-mat.de/ as it's no longer available at all (SSL certificate expired, 503 error on top; this also breaks links from the GitHub wiki)?

Cheers
Mäh

[ClemensElflein]

Hi, I haven't encountered the timing issue you describe. Canon Selphy printers were slow in general, but not slower the longer the software was running.

As for getting those stats, it's probably easiest to have a second program running in parallel querying the CUPS queue. If you want to integrate it into the self-o-mat software, spawning a second thread would be the way to go I think. The benefit of that would be that the second thread could be suspended by a semaphore until a picture is taken and then start querying CUPS in some interval (each second for example) to collect stats. Once all jobs are done, the thread could suspend again.

As far as I remember, the software downsizes the images anyways. I'm not sure what happens inside the printer driver.

Driving parallel printers should be fairly simple to implement, but if the print time itself is not the bottle neck, but the driver's preparation time is, then adding a second printer probably won't make the difference, right?

So just to clarify: What you experienced was longer processing times for the images as the evening progressed, i.e. the printer was idle for a long time?

Yes, getting self-o-mat.de up again is on my todolist for a long time, I'm not sure why I took it down. As far as I remember there is some security issue with the hosting I was using. Migrating to github pages would be the better way I think. The github wiki has most of the info available anyways, right? self-o-mat.de was mostly the shop if I remember correctly?

random question: does this have to do with 38c3 by any chance?

Also: Pi5 might speed things up? Or (depending on your setup) x86 machine?

[maehw]

Thanks for your quick reply, Clemens!

I gave the photobooth to my friends the last times so my own use is somehow long ago. I just remember having had issues with the printing queue and that it took long, long time to get the photos. Periodically checking the print queue when we know that photos are being printed sounds like a good idea before thinking about other ideas!

Also a good idea to benchmark the Pi4 against the Pi5 against an x86 thin client... just need to find time for stuff like that. 😄

IIRC I did not migrate all contents.. and some resources (like the template) were cross-linked. I also think that there were multiple pages - the shop but also some FAQ with interesting contents!

Not related to 38C3 at all (except that it's December now), especially because my booth would be heavy and bulky equipment to bring there.. and the photo/video rules. Are you going? Would love to meet you, have a chat and spend you some Mates/coffees/drinks of your choice.

[ClemensElflein]

If you need anything specific I can pull it for you!

I see, I just saw your post on the hub earlier today that's why I knew you'll be there. Yes I will also attend (first time actually) and thought I might be able to provide the printer for the event then. True about the picture rules, they seem to be pretty strict about that.

[ClemensElflein]

I noticed I haven't replied to the meetup question, coffee sounds good you can reach me via 7882 at the event. See you then!

[maehw]

Thanks, @ClemensElflein . Happy to meet you at congress!

Another dumb question from my side, as I am more of a professional embedded systems developer (as in: on hardware, bare metal or RTOSes) and not under Linux: I get the basic idea of querying the print job queue or printer status.

But: How would you do it? I want to develop something which can be a candidate to be merged into self-o-mat software and not "run into the wrong direction". You mentioned starting another thread from the self-o-mat software, so no external tooling like a Python script (which seems the best approach so that it integrates with the existing software which others might be interested in to get print speed statistics or help troubleshooting).

1. Include the <cups/cups.h> header, call a CUPS API function like cupsGetJobs2,
2. call lpstat as a process and parse its results from stdout (or a temporary file),
3. checking the contents of /var/spool/cups/ directory (need to build up an understanding of the job control files and what's going on there; might break in the future?),
4. query CUPS' web interface for the data,
5. you-name-it; maybe it's something obvious to you but I did not come up with...

[ClemensElflein]

Suggestion 1 is what I would do, since we already use libcups to talk to CUPS, so doing this in the same way does make sense. The function you linked should be pretty perfect for the use-case. It even gives start and end time for each job. So when you also track "image taken time", we have the duration which self-o-mat needed to process before sending to CUPS and then the actual CUPS time (I assume driver processing + print).