OfficeJet D145 - Duplexing PCL 2

[apbell]

I am printing to an OfficeJet D145. The source of the print job is from a database system that does not interact directly with the Windows drivers so I have to embed programmatically the PCL codes for the various font selections, orientation, lines per inch, etc. Everything works great except for turning the duplexer on. It just seems to ignore the Ec&l1S command. Printing from Word or any program that uses the window drivers can do it, but I can;t get my PCL to work. This worked fine with the old LaserJet IID, just not with this newer D145. Is there some secret here I am missing?

Thanks

 

[jlasman]

Assuming that the D145 is a PCL3 printer, you can only duplex through a windows driver. It cannot be done using normal PCL commands as with duplexing LaserJets.

The same is true for other DeskJets that have a duplexor.




Jim Asman
jlasman@telus.net

 

[DansDadUK]

If a Windows driver can do it, then you should be able to emulate what that driver does.

I don't know much about DeskJet devices, and can't coment on Jim's assertion that the PCL 'set duplex' sequence is ignored, so I guess what the driver probably uses is a PCL SET DUPLEX command.

You could verify this by directing the output from the Windows driver to a file (i.e. 'print to file'), then examine that file (unless you have a PCL analyser, or hex editor, WordPad will at least show you the printable characters, with <escape> characters usually shown as 'unfilled squares').

If PJL is being used, it will be near the front (and will effectively be in force for the whole job).

 

[apbell]

Thanks for for the idea, but I have already redirected the output to a file and examined it. It does start with PJL to switch to PCL3GUI and then seems to embed the duplexing command, but further examination indicates that it contains a third, and largely undocumented HP language called PML which is used to set "machine control driver" parameters. There are many of these which begin generally with the sequence "Escape*o{n}W{binary} where the first n represents the number of binary bytes of data which follow the "W". I can find no documentation for these PML commands, so I started examining the C code for the Linux driver for OfficeJets. It is a daunting task and still unresolved.

 

[DansDadUK]

As far as I'm aware, the <esc>*b<n>nW<data> sequence is a Driver Configuration sequence which "Specifies the Lightness, Saturation and Scaling Algorithm to be applied to the document. Also allows for the selection and downloading of Colour Maps."

So nothing to do with simplex/duplex.

I'm not familiar with the PCL3GUI personality, so I've no idea what this expects, or how it is different from PCL5.

I think there is some documentation on PML on the

http://www.hpdevelopersolutions.com

website; you can view this once you join (affiliate menbership is free).

 

[DansDadUK]

Oops: I mis-typed the sequence - as per your post, it is <esc>*o<n>W<data> - but the interpration is still as per my earlier reply.

 

[apbell]

Thanks DansDad, but my cheat sheet indicates that <Esc>*o{n}W is "Driver Function Configuration - General Functions", and that the <Esc>*t{n} set controls those, (eg <Esc>*t{n}J is rendering Algorithm, <Esc>*t{n}K is Scaling Algorithm). I wonder if these change somewhat with personality... I tried removing all the <Esc>*o sequences from my PCL and could find no apparant change in output, so I tend to agree with you that they are not the culprit. I starting looking into the <Esc>&b{n}W set too, my docs are very limited on this set of commands, pretty much just "Peripheral Configuration" which sounded more promising.

 

[DansDadUK]

<Esc>*t0J         Render Algorithm: Continuous Tone
                  other values go up to 19 
<Esc>*t0K         Scale Algorithm: Source/Light Background
<Esc>*t1K         Scale Algorithm: Source/Dark Background
<Esc>&b8W<data>   Configuration (I/O) for AppleTalk

 

[DansDadUK]

I don't think that any of the above sequences are anything to do with duplexing - they are for colour and I/O management.

It is much more likely that PML (if it is used it will be embedded as something like DMSET or DMINFO within a PJL statement.

I don't quite understand your earlier comment It does start with PJL to switch to PCL3GUI and then seems to embed the duplexing command.
Could you clarify this, and perhaps post a representation of the sequences prior to the ENTER LANGUAGE = PCL3GUI?

 

[apbell]

Sorry I wasn't more clear... It start with a UEL and then PJL commands setting Job Name, Language (PCL3GUI), Driver version (R18), an *o5W command, (0B810000x), an &b16WPML (followed by 20040006010401030102010401) an &b28WPML (followed by 2040000401010208100f010153230302430373236313033335A - the last 12 characters of this seem to be date and time followed by the letter "Z")

It continues on for another 20 or so commands, most of whick are *o5W and *o7W commands and various other "normal" PCL commands like the duplex on command (&l2S) and orientation and media source (&l-2H), print quality, etc.

 

[jlasman]

YOU CAN'T DO IT.

For duplexing to work, the page on the back side has to be printed in reverse orientation. No problem on a page printer like a PCL 5 LaserJet, but quite problematic on a PCL 3 inkjet.

A windows driver on the other hand can flip the bits around as is necessary. I went through this drill a couple of years ago.


Jim Asman
jlasman@telus.net

 

[DansDadUK]

Sorry Jim - i didn't mean to doubt your word.

All I meant was that if a Windows driver can do it, you should be able to do the same.

But, as you have pointed out, being able to do this appears to require a LOT more knowledge (of printer MIBS and of how DeskJets operate compared with LaserJets, which it may not be very easy to obtain (if at all)), and a lot more data manipulation.

 

[jlasman]

It seems that the PCL3GUI driver rasterizes the PCL page, and the data sent to the printer is one giant bitmap. In this context, it may very well be the same mechanism as found in the "windows only" printers where there is no internal PCL interpreter.

Jim Asman
jlasman@telus.net