Print Job Restarts While Printing Labels - How to avoid or catch when it does?

[Darkhelmetdad]

Well you start at a number, and print 50, then deduct 50 from that number and print again, so for each print, you can calculate the starting number.

Update: I'm back to the drawing board now. Redesigned it to create records in batches of 50 and send that job before making the next 50. Each batch was done and sent as a job in sequence example: loop from 500 to 1, inner loop that prints after each 50 records generated. And the result is that the spooler printed jobs out of order after the 1st batch. It printed 500 to 451 properly, but then skipped then next 50 and went to printing 399 to 348.

In a second test, I paused the 2nd batch with a msg box until the first was done, and when printing resumed, it skipped the first 30 numbers after 451 and started printing at #420, 419 etc.... This also made me realize, that doing it in batches can allow for other print jobs to be inserted from other users. Can't have this happening either.

[Micron]

doing it in batches can allow for other print jobs to be inserted from other users

Maybe that is the root cause of the original problem and the printer shouldn't be shared at all, or at least not when you're printing the labels? If you have to share, is there a way to advise others that you're about to print and have them hold off?

[Darkhelmetdad]

Maybe that is the root cause of the original problem and the printer shouldn't be shared at all, or at least not when you're printing the labels? If you have to share, is there a way to advise others that you're about to print and have them hold off?

I was the only one printing today. They were all my jobs and they were being printed out of order, so I don't think un-sharing it will matter much.
I'm experimenting now with not using the spooler and just printing direct to the printer. It's a heck of a lot slower, but it might be my best bet for now.

And not sharing it means only one person can print labels, and that won't work either.

[Micron]

Tell your boss he could buy another printer with the money you'll save on wasted labels.

[Darkhelmetdad]

Lol. Good one. That will just be more printers that restart print jobs and duplicate things.

They are $3K+ each. Plus the winders (another $1000 each), replacement heads, $700 each.....
Labels are only about .35 cents. The time spent fixing tagging errors because of duplicates and out of sequence numbers is far more expensive than the material.

So far, I think the direct print option might be the solution. It's far slower than the spooler, and you're stuck not sending another print job until it's done, but the first run went smoothly.

[Darkhelmetdad]

Going to test this for a few days, but a possible solution seems to be to use the "Print Directly to Printer" setting.

It looks as though if printing stops for any reason, Access stops sending more print info and waits, and resumes when printer starts up again. This however locks up Access - all open instances of it - until the print job has finished being sent. For other types of labels (ones in which we print a roll of identical blank ones), I've duplicated the Zebra printer and set that one to use the spooler. I then assign the required printer to the report that is being used. This way when we print the static ones, we can send the whole job to the spooler and free up Access again. If we get more of these ones printed, it doesn't matter. They get used up either way.