Update: I have continued to chase this problem and have found that the only solution is to force Windows to do a direct print to the printer, no spooling. So, if the printer runs out of paper, it will not be able to print and thus our application that sends jobs to the Windows spooler, will stop. Of course, this shuts down printing for all 70 of the other printers we have in-house. To mitigate this, I have been working with OpenNMS and SNMP traps to capture out of media events which then notify the on-duty supervisor and IT administrator that the printer is out of paper. This automation has greatly improved our reaction time to these events.
I have posted this to get it out on the internet so people can find it and not have to go through all the crap I did to get here:
Over the holiday season this year, we made the mistake of leaving our broadcast clients for one of the lines at the KTP plant active. Over the holiday Ford moved product on their line which caused our client to process the data. Hundreds and hundreds of jobs were processed which meant that probably a thousand printouts were done. Most of our printers at the time were low on label stock and ran out. I recall taking a look at the printer server to see how many jobs were queued up but discovered that none of the print queues had any jobs nor did any of the queues show they were in an error state. I knew otherwise. I was annoyed. This leads me to problem number two.
Problem two: When I actually got on-site to take a look at the piles and piles of labels at the printers, I began to reload the stock. I made the silly assumption that all the printers were done printing. Nope! After loading the labels, the printers began to print once again, only this time, it began to print jobs out of sequence. No bueno! Very bad. We’re a sequencing center, the jobs must come out in order. We have error proofing in place to prevent out-of-order sequencing but in normal operations the jobs always come out in order and deviations are cause for concern. I sorted what I could and then reprinted the jobs that were messed up. This took me a few hours when it was supposed to be a, ‘take a quick look to see if things are ok’ job.
I took a look at the settings on the print server and on the printer itself to see if there was anything obviously different between these new printers and our old printers that we have at our IP assembly plant. Since we don’t have this problem with our old printers on our old line. I didn’t find anything obvious so I swept it under the rug and forgot about it.
Over the next few months we’ve added more commodities to our sequencing center here at our original plant. I’ve encountered the out-of-sequencing complaint several times now and it has caused a rift between myself and the night shift coordinator that manages that commodity. The expectation from this guy is that it should work exactly right, every time, and deviations are unacceptable. While I agree with that stance, no amount of digging has, up til now, uncovered a shred of a clue as to why these problems occur.
To reiterate the problem, if the printing operation is interrupted due to running out of paper, the printer server will not record the device as being in an error state and when it is loaded again, will print some jobs out of sequence.
I have become totally fixated on solving this problem. Having zero documentation to work from, needless to say, it has been a bear.
I made a discovery though about a setting that has no explanation that is only accessible through specialty software made for these printers. There are two methods to get to it, through the Intermec equipment management system called SmartSystems and through another printer-only program called PrintSet 5. The setting follows the same path in both programs: Network Services, Net 1, Queue=”On/Off/Multiple” The default value is On. Not knowing or finding any actual explanation as to what this setting does, I took the route of just changing it and seeing what happens.
Here is how our system is setup. We have a Windows 2012 R2 server which is primarily a printer server. We run a proprietary application which looks at a flag in a table on our SQL server that tells it to IDLE, PRINT, or REPRINT a report. Each commodity has two reports, a Part and a Rack report. When a new broadcast comes in, it adds to the report queue table with the PRINT flag and the report manager then grabs the data and packages it up into a single print job and sends it to the print queue, it then changes the table value to IDLE. It’s a very simple and logical operation. The print queues are individual printers, mostly label printers, and all Intermec PM43 printers.
When I change this queue setting to off and then rip off the labels so that it runs out after 5 prints and reprint 9 jobs, it will print 4 jobs and half print the 5th and then the printer itself will flash that it’s out of paper. At the print server the printer will queue up and count down 5 jobs then stop and wait. It will take one more job after about a minute, leaving 3 in the queue on the print server, then the print server will report an error. I reload the labels and it prints out the 5th and 6th jobs immediately, then pauses to clear the error at the queue, then takes the rest of the jobs. Nothing is out of sequence.
When the queue is set to on, which is the default and I follow the same procedure, it prints 4 labels, half of the 5th and then the printer displays the out of paper light but at the print server the queue continues to count down to zero, slowly. About one every minute. It never reports an error on the server. When I load the label stock it prints out what it had queued up and it prints it in order.
I have not been able to replicate the out-of-sequence printing problem but I can replicate the out of paper error reporting problem. I strongly believe that this Queue setting is the key it and know for certain that it is the cause of the non-reporting problem that I have encountered before.
I have posted this to get it out on the internet so people can find it and not have to go through all the crap I did to get here.