On Thu, Aug 16, 2012 at 8:03 PM, Howard White <[email protected]> wrote: > On 08/16/2012 06:53 PM, John F. Eldredge wrote: >> Howard White <[email protected]> wrote: >> >>> Thanks to all that came to our August meeting. >>> >>> We recently changed the way a customer generates labels on a Zebra >>> printer. We moved away from the proprietary ZPL arrangement because >>> we >>> wanted to pull data directly from our database rather than having to >>> rebuild a ZPL label format. No we didn't write a program to generate >>> the ZPL. We have an process that builds PDF files that we then print >>> in >>> all manner of places, now including labels. This arrangement is great >>> >>> when the prints (of any kind) are unique one to the next. >>> >>> Our problem is with the customer that prints 100 or 300 of the same >>> label. (yeah, I know, there is a point at which having the labels >>> printed by a print shop is cheaper.) Because we are now driving this >>> print from our server, one at a time, the print process takes forever. >>> >>> If the printer is paused, the prints queue up such that when the >>> printer >>> is resumed, a stack print out quickly. >>> >>> Any thoughts on how to tune a network printer's "inter-record gap?" >> >> At this point, I am somewhat confused. You are complaining that it takes >> a long time to generate and print 300 labels, but you are also complaining >> that, if the printer is paused, the print jobs queue up, and then come out >> in rapid succession once the printer is put back on line. So, you are >> asking how to make the generation of the labels take even longer, so that >> there won't be a queue of print jobs waiting? Your goals contradict each >> other. >> > So it goes when one tries to explain an involved situation. Thank you for > stating your confusion because it may spur others to clarity. > > If we set up the print job and let it run, the printer in question (a Zebra > ZM400 btw) methodically prints a label, pauses, prints another label, pauses > and so on. What got our hopes up was somewhere in these sequences, the > printer was paused and a queue of work coming from the server built up. The > printer then printed labels at continuous rate until, presumably, the queue > was exhausted. We'd like the printer to print in the continuous fashion all > the time.
Based upon the situation described, it sounds like the printer stops listening for print jobs while it is engaged in the task of printing. So once it gets a print job, it signals to the print server that it is busy, concentrates on formatting the job, starting up the print cycle, printing, shutting down the print cycle, then once again signalling to the print server that it is ready for more print jobs. When the print queue has a bunch of jobs available, the printer accepts all of them at once, then once again shuts off the flow, powers up, prints, powers down, and listens. A way to solve this might be to look into whether you can introduce an artificial delay between the time that you submit the first job and the time that it is submitted to the printer (i.e. let the jobs spool up before submitting them to the printer). Maybe it's something as simple as a dummy printer driver that you print to, where a cron job moves jobs over to the real queue once a minute or something like that. -Tilghman -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
