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
> >
> > ----------------