Patent Application
20070279653
The accompanying figures, in which like reference numerals refer to identical or functionally-similar elements throughout the separate views and which are incorporated in and form a part of the specification, further illustrate the embodiments and, together with the detailed description, serve to explain the embodiments disclosed herein.
The particular values and configurations discussed in these non-limiting examples can be varied and are cited merely to illustrate at least one embodiment and are not intended to limit the scope thereof.
The embodiments described herein can be implemented in the context of a host operating system and one or more modules. Such modules may constitute hardware modules, such as, for example, electronic components of a computer system. Such modules may also constitute software modules. In the computer programming arts, a software “module” can be typically implemented as a collection of routines and data structures that performs particular tasks or implements a particular abstract data type.
Software modules generally include instruction media storable within a memory location of a data-processing apparatus and are typically composed of two parts. First, a software module may list the constants, data types, variable, routines and the like that can be accessed by other modules or routines. Second, a software module can be configured as an implementation, which can be private (i.e., accessible perhaps only to the module), and that contains the source code that actually implements the routines or subroutines upon which the module is based. The term “module” as utilized herein can therefore generally refer to software modules or implementations thereof. Such modules can be utilized separately or together to form a program product that can be implemented through signal-bearing media, including transmission media and recordable media. An example of such a module is module 104 depicted in
It is important to note that, although the embodiments are described in the context of a fully functional data-processing apparatus (e.g., a computer system), those skilled in the art will appreciate that the mechanisms of the embodiments are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal-bearing media utilized to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, recordable-type media such as floppy disks or CD ROMs and transmission-type media such as analogue or digital communications links.
Referring to the drawings and in particular to
Depending upon the design of data-processing apparatus 100, memory 105 may be utilized in place of or in addition to ROM 120 and/or RAM 125. A monitor 135 can also be connected to system bus 160 and can communicate with memory 105, processor 110, ROM 120, RAM 125 and other system components. Monitor 135 generally functions as a display for displaying data and information for a user and for interactively displaying a graphical user interface (GUI) 165. A rendering device or reproduction machine 140 is also connected to system bus 160 and can generate a customized maintenance manual containing the contents required for the HFSIs 145 (e.g., a Photoreceptor (PR) belt 150 and a PR module 155) to be served as will be described in greater detail herein. The rendering device or reproduction machine 140 can be implemented as provided as a rendering device, such as, for example, a laser jet printer, a photocopy machine, a fax machine, a scanner, and so forth, depending upon design considerations.
Note that the term “GUI” generally refers to a type of environment that represents programs, files, options and so forth by means of graphically displayed icons, menus, and dialog boxes on a computer monitor screen. A user can interact with the GUI to select and activate such options by pointing and clicking with a user input device such as, for example, a pointing device such as a mouse, and/or with a keyboard. A particular item can function in the same manner to the user in all applications because the GUI provides standard software routines (e.g., module 104) to handle these elements and reports the user's actions.
Referring to
As described next at block 210, a test can be performed to determine if a rendering operation (e.g. printing) should be performed. The user can display or print the customized maintenance manual, depending upon the outcome of the test illustrated at block 210. If the user desires to print the manual, then as indicated at block 215, the user can print the manual using a local or remote reproduction machine. If, however, the user does not desire to print the manual, the user can view the manual using a GUI (e.g., GUI 165 of
After displaying or printing the manual, as described at block 225, the operator performs the necessary maintenance activities arranged in the most productive order as specified by customized manual. Thereafter as described at block 230, the manual can be discarded after the current maintenance operations are complete, and a new customized manual generated for the next maintenance session as indicated thereafter at block 235. The ‘Maintenance Manual’ GUI allows the operator to reset the HFSIs specified in the procedure, either collectively or individually as described next at block 240, as well as running any necessary diagnostic setup routines based on the activities performed as illustrated thereafter at block 245. The process can then end, as indicated at block 250.
Referring to
A plurality of radio buttons 310, 312, 314, 316, and 318 can also be displayed within GUI window 300. Note that in GUI environments, a “radio button” can be graphically displayed for permitting a user to select one of several options, typically within a dialog box of some sort. A radio button appears as a small circle that, when selected by a user, has a smaller, filled circle within it. Radio buttons act in a manner that is analogous to the station selector buttons on a car radio. Selecting one button on a set can deselect the previously selected buttons, so that one and only of the options in the set can be selected at any particular time.
Utilizing a GUI window 300, a user can select from among a number of options associated with generation of a maintenance manual. By selecting button 310, for example, a user can display and/or print the completed manual. By selecting button 312, a user can automatically generate and display/print manual for HFSIs that are currently due. By selecting button 314 a user can, automatically generate and display/print manual for HFSIs that are currently due, and those that will become due within a specified interval. Additionally, by selecting button 316, a user can allow for the selection and/or de-selection of specific HFSI or other procedures to include the in the generated manual. Finally, by selecting button 316, a user can include or exclude daily maintenance activities (e.g. cleaning) for which there are no specific HFSIs. Note that by “clicking” icon 320, a user can activate the display of another GUI window, such as, for example, GUI window 400, which is described below in more detail.
Referring to
Referring to
Typical maintenance manuals can document each of these procedures individually, with each including (references to) instructions for initially undocking the photoreceptor module, and re-docking the module at the end of the procedure. The set of actions to be performed, the most optimal sequence can be documented for this specific case without repeated activities are undock PR module, perform HFSI action A, replace PR belt, perform HFSI action B, re-dock PR module, etc. By utilizing knowledge of the ideal sequencing of maintenance procedures, operators can always be presented with an optimized sequence of steps that minimizes both repeated actions and overall maintenance time.
Once the manual is generated, and the necessary maintenance actions have been completed, the ‘Maintenance Manual’ GUI allows the operator to reset the HFSIs specified in the procedure, either collectively or individually, as well as running any necessary diagnostic setup routines based on the activities performed.
By implementing the method and system disclosed herein, a reproduction machine can be utilized to generate a customized maintenance manual containing only the content required for the HFSIs to be serviced. This customized manual can be viewed on a GUI, or can be printed on a local or remote reproduction machine for reference. If printed, the manual can be discarded after the current maintenance operations are completed, and a new customized manual generated for the next maintenance session. The disclosed embodiments allow for GUI-based actions required as a part of maintenance procedures (such as resetting HFSIs) to be performed directly from the generated customized manual.
The primary focus of such embodiments is the reduction of non-productive time spent on daily maintenance activities. This can be accomplished by providing an operator with a customized list of only those activities that must be performed, along with detailed instructions for performing each activity. Time is therefore saved because the operator does not need to continuously navigate between the HFSI status list displayed at the reproduction machine GUI and a general hardcopy maintenance manual. Time is also saved by optimizing the sequence of operations to be performed based on the specific procedures required in each maintenance session. The overall quality of the maintenance performed may also be improved, by providing the operator with easy access to the detailed maintenance procedures, reducing the chance that they will attempt to perform the procedures “from memory” rather than taking the time to search out a frequently-performed procedure in the manual. Improving the quality of daily maintenance procedures can reduce subsequent system downtime for reliability or image quality problems, and potentially avoid unscheduled service calls.
A key feature of the embodiments involves an existing machine state to produce an optimized use-once service recipe. This can make a big difference if a user needs to perform two maintenance operations, as the steps could be melded together in most efficient sequence. Such embodiments are most useful for inexperienced users (hence compatible with trend toward more customer-performed maintenance) and applicable to any type of maintenance (e.g., auto, aircraft, etc).
A primary advantage involves maximizing the overall available productive time of a machine, resulting in more billable clicks. This represents one advantage to the provider of the machine. An advantage to the end user or customer is a higher net productivity, which provides a greater return on their printing and rendering assets. Additional advantages may include reduced service calls due to better overall machine maintenance. The contribution of reduced daily maintenance time to overall system productivity is also another advantage.
It will be appreciated that variations of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.
