General Troubleshooting - Xerox ColorQube 8570 Service Manual

General Troubleshooting

This section provides troubleshooting procedures for printer problems not associated with a
fault message or code. For troubleshooting problems associated with a fault code or message,
and information on how to use the troubleshooting procedure tables, see Chapter 2, Fault Mes-
sages and Codes.
Troubleshooting procedures attempt to isolate a problem to a specific component or subas-
sembly, in some cases including the wiring harness. If you go through a troubleshooting proce-
dure and still are unable to solve the problem, re-read the Theory of Operations for the problem
area and ensure that you understand how that section of the printer is supposed to function.
Service Diagnostics provides several tools useful for troubleshooting non-specific problems.
Three of these are especially useful:
• Sub-system Status Reports
• Component Checks
• Diagnostic Fault History
The following overview describes the function and proper application of the each tool.
Sub-system Status
The Report Status reports on the condition of each sub-system. Report Status lists the current
sub-system status as reported by that sub-system's firmware. Status listings are not stored. If
the printer reaches Ready, the list is cleared.
Some applications of status are:
• Provides an initial condition from boot to begin troubleshooting.
• Captures static or dynamic events.
• Confirms diagnostic test results and subsequent repairs.
Component Checks
The Exercise Menu, can be accessed from the Service Diagnostics Menu (Service Diagnos-
tics Menu -> Exercise Menu) is an extensive suite of component-level tests that exercise indi-
vidual electromechanical, thermal, and optical components. Use these tests as the primary tool
for testing printer components.
Xerox Internal Use Only - Revised, 3rd Revision
ColorQube 8570/8870 Service Manual
Diagnostic Fault History
The Diagnostic Fault History utility records a list of engine-generated error events, warnings
are not captured, that occur during diagnostic testing. Use this utility to record error events that
occur while executing tests in Diagnostic Mode. The Diagnostic Fault History utility captures
asynchronous (transient) events only. For static (continuous) or pre-existing events, rely on the
Status utility.
When executed from the Function menu, the Diagnostic Fault History displays on the Control
Panel and updates as each error event is detected. Fault History events are recorded only
when no pre-existing errors are present. The second and subsequent occurrences of the same
event are not recorded. The maximum number of events recorded is 25. Once the list is full,
additional new events are lost until the log is cleared by either a system reboot or by selecting
Fault History Master Clear from the Fault History menu. New events occurring after the list is
cleared are recorded.
For display, the list combines a line number, a code, and potentially a test precondition indi-
cated by the letter P (for events requiring a power cycle), a U for unknown event sequence, an
M for more entries, or a string of asterisks ***** to indicate the last error recorded.
Example:
Fault History Display
1 [150]
2 [42]P
3 [198]P
4 T2]M
Press CANCEL to exit
The example shows a single screen displaying four events. Lines 2 and 3 include the precondi-
tion indicator P directing a reboot before component testing continues. Line 4 includes an
abbreviated Misfeed at Tray 2 code, and the continuation notation M indicating more events
appear on subsequent pages. Pressing OK calls up the next page. Pressing Cancel exits the
utility and displays the Fault History menu.
Events typically appear in the order detected. However, occasionally the event's sequence is
indeterminate. As is the case with simultaneous events. In these cases, a U is appended to the
event to indicate an unknown sequence. While event sequence can be important in determin-
ing cause, the event itself provides a starting point for investigation.
For those events listed with a P, testing of a specific component may not require the indicated
power cycle. For example, if the log lists a motor failure, it's reasonable to go directly to the
appropriate motor test to confirm the failure without first power cycling the system. For events
involving components, such as the Drum, Transfix Roller, or Ink Sticks, power cycling is recom-
mended before additional testing is performed.
October 2012
6-25
General Troubleshooting
General Troubleshooting