In some circumstances, the default printing parameter settings for SENTINEL will lead to lost print jobs. This problem is mostly related to the use of direct printing – the print job is sent directly to the printer, without using Windows print spooler mechanism. Some printer problems, such as a printer in off-line mode, will cause the print job to ‘hang’ for extended periods of time (usually 30 seconds or more). Thus, without the buffering provided by Windows print spooler, successive print jobs have no where to go and will be lost. The problem is exacerbated with high volume and rapid printing to multiple printers.
Situation and Symptoms
- TEKLYNX embedded print driver used for direct printing (i.e. no Windows spooling)
- Print jobs sent SENTINEL via input other than drop file (TCP/IP, Web Services, Database Watch, Serial Port Watch, etc.)
- SENTINEL encounters an problem with a printer during a print job causing it to ‘hang’
- New print jobs are sent to the ‘hanging’ printer before printer issue is resolved
Windows Print Spooler Can Prevent SENTINEL Watch Hang
SENTINEL does not buffer incoming print requests.Generally this is not a problem. When SENTINEL process a print job, it only takes about one second or less to print a label.Thus buffering is not needed as long as print jobs come into a SENTINEL watch at least a second apart from each other.
When using Windows print spooler (used automatically with Windows print drivers or by configuring TEKLYNX drivers to use Windows print spooler), print jobs sent to a printer with a problem (i.e. printer off-line) usually accumulate in Windows print spooler. As long as the SENTINEL watch can keep sending print jobs into the Windows spooler, it will keep processing new print jobs at the one-second-per-job rate. Once the printer is back on-line, it can process all the print jobs waiting in the Windows print spooler. SENTINEL is blissfully unaware there was a problem.
Lost Print Jobs During SENTINEL Watch Hang
However, when using the direct print method WITHOUT Windows spooler, the SENTINEL watch will NOT move on to the next print job until the printer confirms the print job is accepted. By default, if there are communication problem with the printer (ie. media out, lost of communication, paper jam, etc.), SENTINEL will wait about 30 seconds before aborting the job. After aborting the job the first time, SENTINEL will retry the job again. Only after the second failure, SENTINEL will abort the job and proceed to the next job. Thus during all this time, SENTINEL ‘hangs’. No new print jobs will get processed.
Since SENTINEL does not buffer incoming print requests, it will not accept any new print jobs during the hang time. Some input types, TCP/IP and Web Services for example, have no buffering mechanism. Print jobs sent during the SENTINEL watch hang WILL be lost.
Approach #1 – Don’t Let SENTINEL Watch Hang
You can do this in two ways:
- Use Windows spooler to keep print jobs running (even if printer is off-line)…here is how to setup Windows spooler with TEKLYNX embedded drivers.
- Change SENTINEL settings to reduce / eliminate print job timeouts and retries…here is where to find those settings.
Approach #2 – Buffer Incoming Print Jobs
These two inputs will, by their nature, buffer incoming print jobs while SENTINEL watch hangs:
- Drop file – If print jobs are sent to SENTINEL via drop file, Windows will hold the files in the drop file folder until a SENTINEL watch picks it up. Thus those print jobs will NOT be lost. Windows is essentially buffering them for SENTINEL while the SENTINEL watch hangs.
- Database Watch – If the SENTINEL is configured for Database Watch input, the database can act as a buffer. New print requests will just keep adding records to the table as the SENTINEL watch hangs. Once the SENTINEL watch clears from the hang, it picks up where it left off on the database table. Like with the drop files in the Windows folder, no print jobs are lost.
We have seen a case where multiple SENTINEL watches using Database Watch hitting the same database table at the same time did result in some problems. Thus, in that circumstance, the buffering effect of using the Database Watch can have unintended consequences.