DocuColor 242 provides incorrect results for SNMP toner level query

[Kimzi]

Hey!

As the Fiery usually do not show the correct information it is recommended to actually go to the machine and check the status there, the same with billing meters, can also be wrong.

This is a common problem, though they might have a fix so I agree with Fabio, check with efi :)

Thanks!

[Fabio]

maybe its better, you can start on their forums : http://fieryforums.efi.com/

[joshvazquez]

Hi Cheryl,

Thanks for your response. There is no relevant article on the knowedge base. The only articles about SNMP are how to enable it and what is affected when it is disabled. I contacted support before posting here but was told that they cannot guarantee that 3rd-party SNMP tools will work. This doesn't make sense because SNMP is an open standard and you are supposed to use 3rd-party tools to monitor devices. If you can't, then this means that the Xerox is noncompliant with the SNMP standard. The whole reason SNMP exists is so that you don't have to use a different piece of software for each manufacturer you have equipment from. I still consider this a bug.

Fabio:

Should I be contacting EFI for Fiery support?

[Fabio]

hi, i dont think this is supported, because the fiery is between the xerox controller :(

[CherylO-Xerox]

Hello Joshvazquez,.

If you have not already resolved this issue, we suggest you search our online knowledgebase for this product: DocuColor 242.

Alternatively, you can visit our Contact Us page for other support options.

[joshvazquez]

Hi, I am using a DocuColor 242 with built-in Fiery controller. I am trying to monitor consumable levels using SNMP and the standard OIDs specified in RFC 3805.

When I query OID 1.3.6.1.2.1.43.11.1.1.9.1 for toner current level, I get the results in the wrong order. The values are in the right order relative to each other, but offset. That is, for example, the value for black toner level (9.1.1) appears where cyan toner level should be (9.1.4), the value for 9.1.2 appears at 9.1.5, the value for 9.1.3 appears at 9.1.6, etc. If I try again a few minutes later, the results are shifted upwards by 1. The value at the top (9.1.1) gets put on the bottom (9.1.32) and the others are shifted up to fill the empty spot. The shift occurs at specific time intervals, not every time a query is made.

This appears to be a bug with the SNMP implementation on the DocuColor or Fiery. Can anyone help?

Here is some output from snmpwalk at two different times:

SNMPv2-SMI::mib-2.43.11.1.1.9.1.1 = INTEGER: 57510
SNMPv2-SMI::mib-2.43.11.1.1.9.1.2 = INTEGER: 69660
SNMPv2-SMI::mib-2.43.11.1.1.9.1.3 = INTEGER: 174000
SNMPv2-SMI::mib-2.43.11.1.1.9.1.4 = INTEGER: 1300
SNMPv2-SMI::mib-2.43.11.1.1.9.1.5 = INTEGER: 6500
SNMPv2-SMI::mib-2.43.11.1.1.9.1.6 = INTEGER: 0
SNMPv2-SMI::mib-2.43.11.1.1.9.1.7 = INTEGER: 7800
SNMPv2-SMI::mib-2.43.11.1.1.9.1.8 = INTEGER: 4550
SNMPv2-SMI::mib-2.43.11.1.1.9.1.9 = INTEGER: 4550
SNMPv2-SMI::mib-2.43.11.1.1.9.1.12 = INTEGER: 1950
SNMPv2-SMI::mib-2.43.11.1.1.9.1.30 = INTEGER: 33000
SNMPv2-SMI::mib-2.43.11.1.1.9.1.31 = INTEGER: 103400
SNMPv2-SMI::mib-2.43.11.1.1.9.1.32 = INTEGER: 69660

SNMPv2-SMI::mib-2.43.11.1.1.9.1.1 = INTEGER: 69660
SNMPv2-SMI::mib-2.43.11.1.1.9.1.2 = INTEGER: 174000
SNMPv2-SMI::mib-2.43.11.1.1.9.1.3 = INTEGER: 1300
SNMPv2-SMI::mib-2.43.11.1.1.9.1.4 = INTEGER: 6500
SNMPv2-SMI::mib-2.43.11.1.1.9.1.5 = INTEGER: 0
SNMPv2-SMI::mib-2.43.11.1.1.9.1.6 = INTEGER: 7800
SNMPv2-SMI::mib-2.43.11.1.1.9.1.7 = INTEGER: 4550
SNMPv2-SMI::mib-2.43.11.1.1.9.1.8 = INTEGER: 4550
SNMPv2-SMI::mib-2.43.11.1.1.9.1.9 = INTEGER: 1950
SNMPv2-SMI::mib-2.43.11.1.1.9.1.12 = INTEGER: 33000
SNMPv2-SMI::mib-2.43.11.1.1.9.1.30 = INTEGER: 103400
SNMPv2-SMI::mib-2.43.11.1.1.9.1.31 = INTEGER: 69660
SNMPv2-SMI::mib-2.43.11.1.1.9.1.32 = INTEGER: 57510

As you can see, the values cycled upwards.