Facsimile and static presentation processing – Static presentation processing – Communication
Reexamination Certificate
1997-05-09
2003-09-02
Moore, David (Department: 2624)
Facsimile and static presentation processing
Static presentation processing
Communication
C358S001140
Reexamination Certificate
active
06614545
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to imaging systems with printers and optional support devices therefor, and more particularly relates to printers, such as laser printers, having options (e.g. paper handling devices) which contain electronic intelligence for carrying out local option functions commanded by the printer.
2. Description of Related Art
Imaging, or printing, systems typically include a base printer, which places marks (i.e., prints) on a print receiving media (e.g., paper) and media handling options, or devices, that perform various functions such as, for example, providing for multiple paper input sources, multiple paper output destinations, duplexing (i.e., 2-sided printing on the media), stacking and collating. Such printer systems include a base printer having a printer controller, or engine controller, including a microprocessor and associated electronic units. Control of the printer and paper handling facets of such a simple print system are handled by the printer controller. As printer systems add a small number of optional devices, such as additional input sources, the control of the additional devices is provided by the printer controller. For example, the printer option might have electronics to control portions of its own mechanism in which case the printer controller controls the mechanism of the optional device directly through discrete electrical signals or via a unidirectional serial transmission, i.e., communications from the engine controller to the device only. The printer controller controls the optional device directly with dedicated electrical signal lines used to turn a device motor on, turn the motor off, activate a device clutch, etc.
As printer systems become more complex, it is impractical for the printer's engine controller to directly control the entire printer system's electromechanical mechanism. Thus, printer systems have migrated to an architecture in which the printer acts as a “master” of “smart” or intelligent optional devices. Each intelligent optional device typically contains a microprocessor and associated electronics and microcode, to control its own electro-mechanical mechanism. The printer controller, in turn, controls or manages the function of the optional devices as black boxes via a communications interface.
The presence of options with intelligence, of course, raises other kinds of problems. For example, optional devices with intelligence are usually controlled by a low function microcontroller with a built in UART to perform the serial communications task with the printer. These low level microcontrollers usually only operate at a low communications or baud rate. When the printer has to communicate with several optional devices and issue several commands to each device, a communications bus bandwidth problem is presented, i.e., communications to the devices cannot be accomplished in sufficient time to support the printer's and/or device's operation.
Another problem with such a serial interface is that the printer often must send the same command (or instruction) to every optional device in the printer system. A good example of this is when the printer needs to instruct all the devices to “reset” themselves to their default conditions. The simplistic approach for accomplishing this is for the printer to address every device, one at a time, sending the devices the same command until every device in the printer system has received the printer's instruction.
Another distinct problem in a system utilizing a serial communications bus to interconnect master and optional devices relates to the detection and reporting of transmission errors.
With respect to errors in transmission detected by the printer controller (master) in a master/optional device relationship, typical solutions specify that the master resend a command if the master has determined that a transmission error occurred on the initial transmission. However, there are limitations in such solutions.
Such solutions lack effective or efficient means for terminating a multi-byte command that is in progress when the master detects the transmission error, so that both the master and optional devices reset their command processing successfully. Solutions for doing so are often complicated because the syntax (number of command bytes, number of response bytes) for the command may depend on the command op code (or its equivalent), and/or length fields that define the length of the command or response at the time the command/response is sent. Errors that occur in the command op code, command length field, or response length field are particularly difficult for prior art solutions to deal with.
Also, such solutions do not provide a simple means for allowing the master to report the transmission error immediately to a optional device in the middle of a command/response that is in progress. Generally, the master will attempt to finish a command/response that is in progress even though the transmission error may have altered the command syntax that is being assumed by the optional device. Since the master attempts to complete the command, the device will receive a complete command that may contain erroneous data, or may actually be a different command than was intended.
With respect to errors detected by an optional device, one of two approaches is typically used to allow an optional device to report a detected transmission error to the master controller.
The first solution is to reserve a special response byte value, such as 255, solely for reporting a transmission error. A device is then not permitted to ever use the value 255 as a response byte unless it is attempting to report a transmission error. For example, a device could never report, in a single byte, that it had a capacity of 255 sheets. This sort of scheme is cumbersome, and is particularly difficult if the device must report measured data, which may return any range of values.
The second solution is to specify that a device stops responding to the master if the device detects a transmission error. After timing-out when waiting for a response that was never sent, the printer controller (master) then resends the command that was not completed. Generally, if there is no response to the retry, the master must declare that the optional device has experienced a fatal error. The limitation of this scheme is that the master cannot differentiate an “ailing” communications link from a general device malfunction that prevents the device from responding or prevents it from executing its control code reliably. Hence, the device cannot be serviced efficiently because the error cannot be accurately reported with this solution.
Another problem that exists with a multiple paper handling options printer system is the means by which addresses are allocated for each option.
One traditional scheme for setting the device's communication address is sometimes referred to as “Hard Coded Device Software”. In this scheme, at design time the engineers of the printer system decide upon a unique address for each and every device making up the printer system. Then, each device “hard codes” its assigned address into its device software; thus, allowing such a device to communicate with the printer when addressed. The major disadvantage to this method is the fact that only one of any particular device can be configured as part of the printer system. Another disadvantage is that when it is attempted to connect and use the device in some other printer system, it may require a microcode modification to change its hard coded device address because the hard coded value may already exist for some other device in the other printer system. Thus, this device addressing method is inflexible.
Another traditional way in which the device's communication address may be set is often referred to as “Customer Settable Dip Switches”. Each device has a set of dip switches on its electronics card. The setting of the dip switches is used to set the device's communications addres
Langer David Brian
Parish Steven Wayne
Sharp Edward Carlton
Aust Ronald K.
Brady John A.
Lexmark International Inc
Moore David
Tran Douglas Q.
LandOfFree
Communication scheme for imaging systems including printers... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communication scheme for imaging systems including printers..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communication scheme for imaging systems including printers... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3112839