0

I'm trying to read the number of pages and the number of duplex pages (or the number of sheets and number of impressions, which is equivalent) from a large number of printers via SNMP. The idea is to see whether users are printing double-sided or not. I'm stuck on the LaserJet 4000.

The HP-LaserJet-Common MIB suggests that OID 1.3.6.1.4.1.11.2.3.9.4.2.1.4.1.2.22, duplex-page-count, is the answer: http://www.oidview.com/mibs/11/HP-LASERJET-COMMON-MIB.html

On other printers (say, the LaserJet 8150), that OID produces sensible results (it never exceeds the total pages from prtMarkerLifeCount, and it is always 0 on printers that don't have a duplexer.)

However, on the 4000, I regularly get non-zero readings from printers that don't have a duplexer. Here's a sample I've observed:

+------------------------------------------------------------+--------+--------+
| media_paths                                                | duplex | pages  |
+------------------------------------------------------------+--------+--------+
| Simplex Duplex-Long edge binding Duplex-Short edge binding |  30844 |  70393 | 
| Simplex Duplex-Long edge binding Duplex-Short edge binding |  13534 |  99197 | 
| Simplex Duplex-Long edge binding Duplex-Short edge binding |  32774 | 200131 | 
| Simplex Duplex-Long edge binding Duplex-Short edge binding |  58058 | 201286 | 
| Simplex Duplex-Long edge binding Duplex-Short edge binding |  56008 | 405618 | 
| Simplex Duplex-Long edge binding Duplex-Short edge binding |  31420 | 136312 | 
| Simplex                                                    |     56 |  84774 | 
| Simplex                                                    |    622 | 113390 | 
| Simplex                                                    |    930 | 176126 | 
| Simplex                                                    |     46 |  45193 | 
| Simplex                                                    |      2 |  24600 | 
| Simplex                                                    |    474 | 154349 | 
| Simplex                                                    |     40 |  56630 | 
| Simplex                                                    |  16582 | 173121 | 

Note that while the printers with duplex units installed (in other words, media_paths as derived from OID 1.3.6.1.2.1.43.13.4.1.10.1 lists some duplex paths) have lots more duplex pages, the simplex-only printers all have some duplex pages.

I'm curious: is 1.3.6.1.4.1.11.2.3.9.4.2.1.4.1.2.22 simply the wrong OID for duplex pages on the LJ 4000?

I can imagine that it might also track manually-printed duplex jobs, but I really can't imagine that someone printed 16,582 pages of those, as on the last printer. I could also believe that some of these printers had duplex units that were later removed, but of the 58 I've inspected, all but one have non-zero duplex counters. Contrast this to the LJ 8150, where not one of the simplex-only printers has a non-zero duplex counter.

ServerFaulters, I'd love to know if there's any way to get a duplex count (or a physical sheet count) out of the 4000.

2 Answers 2

1

You might try: http://www.wtcs.org/snmp4tpc/MIBS.htm#HP for a LJ4000 specific mib.

Note that the mib author explains how a duplex count is made (around line 4389):

"Total number of sheets of media that have been duplex printed. A sheet is counted if it travels through the duplex page path, regardless of whether or not marks are made on the page...."

Physically, the duplex unit plugs in along the same path the a page might take under some circumstances. Possibly if someone is printing to a heavy or cardboard stock, and opens the back to give a flat paper path, the duplex counter is incremented as well, since a duplex job would follow that path.

Certainly worth testing, since this indicates that the printer is counting physical events, rather than counting the users print job instruction. Also note that 10 printing events need to take place before a counter is incremented...

GL,

Rob

0

LJ4000's are getting quite old, and I've had many have bad crashes, it's possible, albeit fairly unlikely that they've all corrupted those counters in a crash.

You must log in to answer this question.