Duplex printers
2009-08-11 21:32I'm annoyed by how slow our office printer is at printing on both sides of the paper. It occurs to me that it ought to be possible to make it much faster (a similar speed to single-sided printing) without too much extra complexity.
At the moment it handles one sheet at a time, in the sequence feed / print / reverse / print / eject. The feed and eject phases can be overlapped but there's otherwise little opportunity for pipelining.
If the duplex mechanism includes a paper path that goes from the print mechanism's exit to its entrance while turning over the sheet, then the path through the printer can be one-way (except inside the duplexer) and the duplexer can operate at the same time as the printer. The whole thing can then handle two sheets at once. The sequence goes like this:
- feed sheet 1
- print page 2 on sheet 1
- sheet 1 into duplexer / feed sheet 2
- sheet 1 through duplexer / print page 4 on sheet 2
- sheet 1 into printer / sheet 2 into duplexer
- print page 1 on sheet 1 / sheet 2 through duplexer
- sheet 1 exits / sheet 2 into printer
- print page 3 on sheet 2
- sheet 2 exits / feed sheet 3
- ...
I have assumed a C-shaped or S-shaped paper path, where the printer prints on the top of the sheet which turns over before dropping into the hopper, so that you end up with the stack of paper face down in the correct order. Our printer's duplex mode presumably prints pages in even/odd order (i.e. page 2 then page 1 on sheet 1, page 4 then page 3 on sheet 2, etc.) so the output stack still ends up in the right order. My duplexer's 2/4/1/3 page ordering puts greater demands on the RIPper's memory but that shouldn't be a big deal these days. (On the other hand, why does our printer appear to wait while RIPping? Shouldn't that be instant nowadays?)
So I wonder if anyone makes a printer with a duplexer that works this way. It should be fairly obvious from the duplex / duplex / exit / exit rhythm.
no subject
Date: 2009-08-11 21:16 (UTC)no subject
Date: 2009-08-11 21:23 (UTC)Our big photocopier/printers have about 6 sheets in flight at once (although some of those will be in the output stapler/sorter) as anyone trying to recover from a paper jam will find.
no subject
Date: 2009-08-11 21:38 (UTC)no subject
Date: 2009-08-11 22:12 (UTC)no subject
Date: 2009-08-12 07:18 (UTC)To print on both sides, either 1) your paper goes through the printing unit in two directions, 2) your sheets of paper need to perform half a barrel roll, or 3) they need to reverse direction. 1) immediately goes against the idea of pipelining, and leads to complications in the ordering of various steps (illuminate drum, toner on drum, transfer to paper, fuse, in the case of laser printers). 2) is possible, but not practical in workgroup printers for reasons of space. So we're left with reversing direction, which is always going to have a time penalty compared with dimple transport.
HP has workgroup colour laser printers that do nearly what you describe: they feed page 1, print one side, duplex 1 while feeding 2, print one side of 2, duplex 2 while re-feeding 1, print the other side of 1, exit 1 while re-feeding 2, print the other side of 2, exit 2 & start afresh. You can tell by the fact that you see two half-printed sheets peeping out of the exit & being sucked in again, then two land in the output hopper. The limitation is in the reversing being done in the output path: if you had a separate path for that and fast paper-route switching, you could lengthen the above sequence. I've also seen printers accumulate a stack of half-printed sheets in a spare input/holding tray, then do all the other sides in one go.
no subject
Date: 2009-08-12 09:45 (UTC)no subject
Date: 2009-08-12 09:46 (UTC)no subject
Date: 2009-08-12 10:32 (UTC)no subject
Date: 2009-08-12 11:34 (UTC)I'm reminded of the ticket machines you get in some Japanese railway stations, where you can insert your ticket in any orientation but it always comes out in the correct orientation. (Of course a railway ticket is a lot smaller than A4.)
Good
Date: 2011-06-07 18:10 (UTC)Re: Good
Date: 2011-06-08 05:25 (UTC)