search

KPB-US / badgeulator

employee identification badge printing system
1 stars 1 forks source link

Print action appears to print the previous viewed badge rather than the current badge #131

Open bjh45964 opened 1 week ago

bjh45964 commented 1 week ago

While printing badges for leadership, it appeared that several times, the badge printed wasn't the current badge, but the last badge viewed. It's possible that what actually happened was a double print (2 jobs sent at some point), since Jen was just loading one badge at a time for printing.

The net result was that we ended up printing the wrong image on a badge (when we were printing onto badges already assigned in Lenel).

When printing ID badges (non-Access Control related), this doesn't matter, but when printing onto an Access Control card, the card is unique so it can throw things off or necessitate reassigning a bunch of cards.

bjh45964 commented 1 week ago

For the time being, I told Jen to ALWAYS have 3-5 cards in the hopper, so there wouldn't be any "unknown" jobs queued.

Would it be possible to show a "queue" for print jobs, at a minimum just showing how many print jobs are pending?

slmclane commented 1 week ago

Spoke with Ben, a partial that shows over that navbar that indicates that there are pending print jobs will suffice.

Created a partial that outputs the results of cups commands. lpstat -p will show print jobs on admweb4. If there are no active jobs, lpstat won't return anything. lpq gives command not found on admweb4.

slmclane commented 5 days ago

Ran a print job on production with an empty badge tray. The partial appeared with the number of print jobs, but it went away after refreshing the page even though nothing printed. CUPS indicates that the job was completed.

Found a stack overflow post that goes into the behavior of CUPS jobs where the printer uses a socket connection:

https://stackoverflow.com/questions/24488953/cups-returns-complete-on-jobs-which-are-still-printing#answer-53689501

But if you see socket:// then CUPS is configured to use the AppSocket method (sometimes also called 'HP Jet Direct' or 'IP Direct Printing') to forward jobs. This is a "fire and forget" protocol. Basically it is the same as if you did run netcat print-device 9100 < myprintfile to shovel the printable data to port 9100 of the printer. The CUPS socket backend handling this spooling to the printer will not get any other acknoledgement from the printer than what TCP/IP provides confirming that the last packet was transfered. Hence it has to close down its process and report to the CUPS daemon successful-ok, even if the printer is still busy spitting out lots paper and will maybe never complete the full job because it runs into a paper jam...

We may be able to get more accurate job statuses if we change the printer's connection method.