I like this new wording.
Chuck Adams
Tektronix, Inc.
Color Printing and Imaging Division
> -----Original Message-----
> From: Steve Waldbusser [SMTP:waldbusser at ins.COM]
> Sent: Wednesday, August 25, 1999 5:05 PM
> To: lpyoung at lexmark.COM> Cc: hostmib at andrew.cmu.edu; pmp at pwg.org> Subject: Re: PMP> Re: Requested change to HR MIB
>>> If we did this, the appropriate text would look like that below. Note that
> this
> also deletes the advice on setting hrDeviceStatus based on hrPrinterStatus
> values,
> which would also be problematic.
>> Steve
>> hrPrinterStatus OBJECT-TYPE
> SYNTAX INTEGER {
> other(1),
> unknown(2),
> idle(3),
> printing(4),
> warmup(5)
> }
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The current status of this printer device."
> ::= { hrPrinterEntry 1 }
>>> hrPrinterDetectedErrorState OBJECT-TYPE
> SYNTAX OCTET STRING
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "This object represents any error conditions detected
> by the printer. The error conditions are encoded as
> bits in an octet string, with the following
> definitions:
>> Condition Bit #
>> lowPaper 0
> noPaper 1
> lowToner 2
> noToner 3
> doorOpen 4
> jammed 5
> offline 6
> serviceRequested 7
> inputTrayMissing 8
> outputTrayMissing 9
> markerSupplyMissing 10
> outputNearFull 11
> outputFull 12
> inputTrayEmpty 13
> overduePreventMaint 14
>> Bits are numbered starting with the most significant
> bit of the first byte being bit 0, the least
> significant bit of the first byte being bit 7, the
> most significant bit of the second byte being bit 8,
> and so on. A one bit encodes that the condition was
> detected, while a zero bit encodes that the condition
> was not detected.
>> This object is useful for alerting an operator to
> specific warning or error conditions that may occur,
> especially those requiring human intervention."
> ::= { hrPrinterEntry 2 }
>>>>lpyoung at lexmark.com wrote:
>> > Steve,
> > Another solution would be to delete the hrDeviceStatus column from
> > the description of hrPrinterDetectedErrorState. This column caused
> > alot of confusion in our interoperability testing and I am not sure
> > the clarifying text will solve the problem. It is also becoming
> > more common than not that a printer will keep running even with
> > "no paper". What was "typically appropriate" a year or so ago is
> > changing rapidly in the printer world.
> > Lloyd
> >
> > waldbusser%ins.com at interlock.lexmark.com on 08/23/99 03:53:03 PM
> >
> > To: hostmib%andrew.cmu.edu at interlock.lexmark.com> > cc: (bcc: Lloyd Young/Lex/Lexmark)
> > Subject: PMP> Re: Requested change to HR MIB
> >
> > This problem was solved a different way.
> >
> > The new text (ini the current draft) clarifies that "The hrDeviceStatus
> column
> > shows the hrDeviceStatus which is typically appropriate when such an
> error
> > condition exists." In other words, there isn't a strict algorithmic
> > translation between errorState bits and deviceStatus. deviceStatus
> should be
> > set based on the operational status of the printer. errorState bits
> should be
> > set based on any detected errors. If the noPaper condition is set but
> the
> > printer is still able to run, this would be highly unusual, but OK. The
> > deviceStatus column just suggests the most likely condition.
> >
> > Adding warning or down to all rows is less useful and actually provides
> less
> > flexibility than implementors might need.
> >
> > Steve
> >
> > > From: lpyoung at lexmark.com> > >
> > > Please change the description of hrPrinterDetectedErrorState:
> > >
> > > Original Text
> > > Condition Bit # hrDeviceStatus
> > >
> > > lowPaper 0 warning(3)
> > > noPaper 1 down(5)
> > > lowToner 2 warning(3)
> > > noToner 3 down(5)
> > > doorOpen 4 down(5)
> > > jammed 5 down(5)
> > > offline 6 down(5)
> > > serviceRequested 7 warning(3)
> > > inputTrayMissing 8 warning(3)
> > > outputTrayMissing 9 warning(3)
> > > markerSupplyMissing 10 warning(3)
> > > outputNearFull 11 warning(3)
> > > outputFull 12 warning(3)
> > > inputTrayEmpty 13 warning(3)
> > > overduePreventMaint 14 warning(3)
> > >
> > > Revised Text
> > > Condition Bit # hrDeviceStatus
> > >
> > > lowPaper 0 warning(3) or down(5)
> > > noPaper 1 warning(3) or down(5)
> > > lowToner 2 warning(3) or down(5)
> > > noToner 3 warning(3) or down(5)
> > > doorOpen 4 warning(3) or down(5)
> > > jammed 5 warning(3) or down(5)
> > > offline 6 warning(3) or down(5)
> > > serviceRequested 7 warning(3) or down(5)
> > >
> > > inputTrayMissing 8 warning(3) or down(5)
> > > outputTrayMissing 9 warning(3) or down(5)
> > > markerSupplyMissing 10 warning(3) or down(5)
> > > outputNearFull 11 warning(3) or down(5)
> > > outputFull 12 warning(3) or down(5)
> > > inputTrayEmpty 13 warning(3) or down(5)
> > > overduePreventMaint 14 warning(3) or down(5)
> > >
> > > Reason for change:
> > > The original text would seem to require all printers to respond
> > > identically in hrDeviceStatus on the same error condition. Reality
> > > is that different printers respond differently on the same error
> > > condition. What might be a warning in one printer may be a down
> > > condition in another printer. Even within a printer a single error
> > > condition might be a warning one time and a down condition another
> > > time. For example, several printers support the linking of multiple
> > > paper trays together to form one logical paper tray, when one of the
> > > linked trays runs out of paper the printer will start feeding paper
> > > from one of the other linked trays, the printer may report noPaper
> > > but it is a warning condition because paper is being fed from
> > > another tray.
> > >
> > > Lloyd
> > > ------------------------------------------------------------
> > > Lloyd Young
> > > Manager, Alliances and Complementary Project Development
> > > Consumer Printer Division Lexmark International, Inc.
> > > Dept. C88M/Bldg. 005-1 740 New Circle Road NW
> > > email: lpyoung at lexmark.com Lexington, KY 40550-0001
> > > Phone: (606) 232-5150 Fax: (630) 982-4032
> > >
> > > ----------------