A printing apparatus with a cash drawer control function, and a control method therefor

The present invention relates to a printing apparatus having a cash drawer control function and to a control method therefor. More particularly, the invention relates to a printing apparatus capable of controlling a cash drawer irrespective of the status of the printing apparatus. The present invention is therefore particularly effective when used with systems for processing monetary transactions, such as point-of-sale (POS) terminals and electronic cash registers (ECR).

Conventional POS and ECR systems typically have the cash drawer in which money is held below the printing apparatus. The cash drawer is normally locked in a closed condition and opens in response to a cash drawer open/close signal issued from the printing apparatus. So-called terminal printing apparatuses that are connected through some interface to a host device to execute a printing process according to control commands received from the host device, comprise means for outputting the cash drawer open/close signal for a specified time from a specified output port. To reduce the standby time to completion of the control commands of the host device, the control commands are temporarily stored in a command buffer, and then read and executed in first-in-first-out order.

While the command buffer size varies according to the model and application of the printing apparatus, the command buffer is often also used as a print data buffer, and can therefore generally store a large number of control commands. Therefore, when many control commands are stored in the command buffer, a significant time interval may pass from the time at which the host device sends a cash drawer open command until the cash drawer is actually opened. More specifically, once a receipt printing or other printing process has been started, monetary transactions such as storing cash received or making customer change must wait until the printing process is completed. As a result, the user must wait for an extended period of time, and numerous problems therefore remain for printing apparatuses used in systems for processing monetary transactions, such as point-of-sale (POS) terminals and electronic cash registers (ECR).

Faster processing is demanded in printing apparatuses for the POS/ECR market in recent years. Because transaction processing in particular requires manual intervention, it is necessary to open the cash drawer immediately as soon as an open request is issued.

Therefore, an object of the present invention is to provide a printing apparatus whereby the above problems can be solved, the load on the host device is reduced and operation is user-friendly.

This object is achieved with a printing apparatus as claimed in claim 1 and a method as claimed in claim 10. Preferred embodiments of the invention are subject-matter of the dependent claims.

As a result of the configuration of the invention, it is possible to independently control an externally connected device as requested by the host device even when command data for the printing process are stored in the data storage means.

It is possible to control the external device parallel to the printing process, to control the external device with priority over the printing process, or to control the external device after the end of the printing process when a printing process is being executed by the printer control means.

The process sequence is preferably set with consideration to the power supply capacity, the processing capacity of the printing apparatus and other considerations. More specifically, if there is sufficient power supply capacity, simultaneously executing control of both the printing apparatus and an external device is preferable with respect to processing speed. On the other hand, temporarily interrupting the printing process and controlling the external device is preferable in applications in which controlling the external device is of higher priority. However, if interrupting the printing process will degrade the print quality, it is preferable to let the external device wait for a break point in the printing process that will not result in degraded print quality, such as at a line end.

In an embodiment of the invention, the command data received in one-byte units from the host device can be detected and processed as they are received. It is therefore not necessary to store a specific number of bytes of command data, and the time required for the detection process can be divided into small pieces. Therefore, if either the data receiving means or the command detection means interrupts printing process control by the printer control means to at least either receive data from the host device or detect the predetermined command data, the benefits of distributing the detection process can be obtained.

Preferred embodiments of the invention will be described below with reference to the drawings, in which: <dl id="dl0001"><dt>Fig. 1</dt><dd>is a circuit block diagram of a control circuit embodying the present invention,</dd><dt>Fig. 2</dt><dd>is a functional block diagram of a control circuit illustrating a preferred embodiment of the present invention,</dd><dt>Fig. 3</dt><dd>is a flow chart illustrating one aspect of a control method according to the present invention, and</dd><dt>Fig. 4</dt><dd>is a flow chart illustrating another aspect of a control method according to the present invention.</dd></dl>

Fig. 1 is a block diagram of the control circuit of a printing apparatus according to an embodiment of the invention. Connected to CPU 50 which controls the entire printing apparatus are: cover sensor 54 for detecting whether the cover of the printing apparatus is open; panel switch 49 for manual paper feed control; interface 51 for connection to host computer 61; ROM 52 for storing the control program 52a, character print patterns and other data; and RAM 53 used as a receive buffer 64, a print buffer 66 etc..

Print data and command data input through interface 51 are stored in receive buffer 64 of RAM 53. CPU 50 then interprets these data, reads, in case of print data (e.g. a character code), the corresponding character print pattern from ROM 52, and controls, in case of a print, format or positioning command, print controller 43 to accomplish the printing process. More specifically, CPU 50 controls, via print controller 43, ink jet head or other print head 40, and motor group 41 for driving print head 40 and a recording medium; and drives plungers of plunger group 42 to hold cut-sheet forms or switch a recording medium transport path as necessary when the printing apparatus is designed to print to plural media.

Pulse output commands for requesting supply of a control or drive pulse to a cash drawer or other external device connected to the printing apparatus are also input through interface 51. In response to a pulse output command CPU 50 outputs a pulse from port 56 or port 57 through drawer drive circuit 55. Which port is used for pulse output is specified by a parameter of the pulse output command as will be described below. According to the present invention the pulse output command is a real-time command. A real-time command is immediately executed even if previously entered commands are still waiting for execution in receive buffer 64.

An example of a real-time command code is: DLE DC4 n m t. Each of the command code components DLE, DC4 and the values n, m and t is one byte expressed in hexadecimal notation as 10_H, 14_H, and the hexadecimal value corresponding to n, m and t. DLE and DC4 identify a real-time command. Parameter n determines the type of real-time command, i.e., which operation is to be executed. When n = 1, the command is interpreted to be a pulse output command. In case of a pulse output command, the number of an output port from which the pulse is to be output is defined by parameter m while t defines the pulse length (the ON time).

Fig. 2 is a functional block diagram illustrating an embodiment of the present invention, and shows the relationship between its various functional means. Host computer 61 transfers command data and print data to the printing apparatus. Data receiving means 62 receives the data from host computer 61 through interface 51, and is implemented in the present embodiment by means of an interrupt process started by interface 51. The received data are interpreted immediately upon being received by first command interpreter 63 implemented as part of the interrupt process for data receiving means 62.

First command interpreter 63 checks whether the received data represent a real-time command and, if so, causes the specified process to be executed according to the command parameters. All data having been interpreted by first command interpreter 63 are stored temporarily in receive buffer 64. Second command interpreter 65 reads the stored data in a first-in-first-out sequence in single data units, e.g., one byte at a time, interprets the data and discriminates print data from command data used to set various printing apparatus control parameters. The interpretation of the data stored in receive buffer 64 by second command interpreter 65 is executed in response to a request from control means 69. When the printing apparatus is in an idle state, for example, after a printing job is completed, control means 69 repeats checking whether receive buffer 64 is empty in a normal idling routine. If there are data in receive buffer 64, control means 69 causes second command interpreter to perform the interpretation described above.

It should be noted that while, in the present embodiment, the data from data receiving means 62 is stored in receive buffer 64 after having been processed by first command interpreter 63, the present invention shall not be so limited. It is also possible, for example, to store the data from data receiving means 62 in receive buffer 64 while passing these data to first command interpreter 63 in parallel.

Command data are processed by control means 69. More specifically, particular settings are made according to the command data, or particular operations are performed. If the received data is print data, a character print pattern is stored in print buffer 66 according to the data code. When printing is executed by control means 69, the print pattern is read from print buffer 66 to control print unit 70 and print. Print unit 70 comprises primarily print controller 43, print head 40, motor group 41 and plunger group 42 shown in Fig. 1.

When first command interpreter 63 confirms that the received data is a pulse output command, information indicating that a pulse output request was received is stored in storage means 67 of RAM 53. This can be accomplished, for example, by setting a particular flag. In the following this information will be referred to as "request flag". The pulse length is also stored in storage means 68. The output port number, another parameter of the command, may be separately stored in another storage means (area of RAM 53) or a respective request flag is provided for each port number.

Control means 69 monitors the request flag by polling storage means 67. When the request flag (or one of the request flags) is set, control means 69 outputs, by means of pulse generator 71, a pulse of a length according to the information in storage means 68 to the port whose number has been stored in RAM 53 (or which is associated with the request flag that is found to be set).

When the cover of the printing apparatus is open or paper is being transferred in response to paper transport switch 49 having been actuated, control means 69 comes in a so-called off-line state where it waits for the off-line state to be cancelled. More specifically, reading and executing commands from receive buffer 64 stops to assure operator safety when the printing apparatus cover is open to supply paper, for example. Because receive buffer 64 may overflow if data continue to be stored in receive buffer 64 in this state, the printing apparatus notifies the host device that data sent thereafter are not guaranteed to be received.

When control means 69 is in the off-line state, control means 69 only monitors data input from data receiving means 62, and cannot activate the second command interpreter 65. The first command interpreter 63 continues to operate irrespective of the off-line status while control means 69 monitors data input. In the present embodiment, a current pulse for driving a solenoid built into the cash drawer is output in response to the pulse output command; furthermore, pulse generator 71 and print unit 70 share the same power supply. Because the power supply does not have sufficient capacity to simultaneously drive both the solenoid via pulse generator 71 and print unit 70, control means 69 can only drive one of the devices, i.e., either printing is performed or pulse generation.

Fig. 3 shows the control sequence of the receive interrupt process of the interface by which the data receiving means 62 and real-time command interpreter 63 are implemented. Data sent from the host computer through interface 51 are received in data units of a particular size, which is defined as one byte by way of example only in the present embodiment. The process shown in Fig. 3 is therefore executed each time one data byte is received. The real-time command contains five bytes (DLE, DC4, n, m and t) as explained above, and is therefore analyzed using a counter RTC for counting the number of bytes received (in the following "RTC" will also be used as representing the count value of the RTC counter). Note that, although not shown in the drawings, counter RTC is initially reset to RTC = 0 such as during initilization of the printing apparatus upon power being switched on.

The process starts at step 130 when a byte C has been received and a receive interrupt generated by interface 51.

Byte C is read through the interface at step 131, and it is determined whether the condition RTC = 4 is met in step 132. If RTC = 4, i.e., if the sequence DLE, DC4, 1 and m of a real-time command has already been received, C is processed as parameter t. The RTC counter is then cleared in step 133.

If the value of C is from 1 to 8 (step 134), it is stored as pulse length (or representation of the pulse length) at a specific address in RAM 53 in step 135 (as will be understood the specific address corresponds to storage means 68 in Fig. 2). Note that all received data are initially stored in receive buffer 64, even real-time commands (step 151).

If the value C is outside the range from 1 to 8 (step 134), the counter remains cleared and the byte is stored to receive buffer 64 (step 151). Such values are illegal parameters and therefore prohibit the complete command from being processed. The byte is nevertheless stored to receive buffer 64 because it may be part of print data.

If RTC ≠ 4 in step 132, it is determined whether RTC = 3 in step 137 (RTC is set to 3 if DLE, DC4 and 1 have been received). If so, the RTC counter is cleared in step 137, and it is determined whether C is 0 or 1 (step 138). If C is 0 or 1, RTC is set to 4 (step 139), and the pulse output port number corresponding to the value of C is stored at a specified address in RAM 53 (step 140). The received byte is also stored to the receive buffer (step 151). If the value of C is not 0 or 1 (step 138), the counter remains cleared and the byte is stored to the receive buffer (step 151) for the same reason described above.

If RTC ≠ 3 in step 136, it is determined whether RTC = 2 in step 141 (RTC is set to 2 if DLE and DC4 have been received). If so, the RTC counter is cleared in step 142, and it is determined whether C is 1 (step 143). If C is 1, RTC is set to 3 (step 144), and the received byte is stored to the receive buffer (step 151). If the value of C is not 1 (step 143), the counter remains cleared and the byte is stored to the receive buffer (step 151).

Note that parameter n is used to identify the type of real-time command. As mentioned before, n = 1 represents a pulse output command. A value of n other than 1 may represent a different real-time command for execution of some other process with priority over normal commands. Because other real-time processes are not defined in the present embodiment, no real-time processing is performed if n ≠ 1.

If RTC ≠ 2 in step 141, it is determined whether RTC = 1 in step 145 (RTC is set to 1 if DLE has been received). If so, the RTC counter is cleared in step 146, and it is determined whether C is 14_H (the DC4 code) (step 147). If C is 14_H, RTC is set to 2 (step 148), and the byte is stored to the receive buffer (step 151). If the value of C is not 14h (step 147), the counter remains cleared and the byte is stored to the receive buffer (step 151).

If RTC ≠ 1 in step 145, it is determined whether C is 10_H (the DLE code) (step 149). If C is 10_H, RTC is set to 1 (step 150); if not, the byte is stored to the receive buffer (step 151) and the receive interrupt process is terminated (step 152). If in step 149 the value of C is not 10_H, the counter remains cleared and the byte is written to the receive buffer (step 151).

The pulse output control sequence is described next with reference to the flow chart in Fig. 4.

Control means 69 monitors the request flag stored in storage means 67, and reads the pulse length from storage means 68 (step 101) when a request flag is detected to be set (step 100 returns YES).

The port number for pulse output is read from a corresponding storage means (or determined from the request flag) (step 102), and the pulse is output (step 103 or step 104).

A timer for counting the ON time (pulse length) is activated (step 105), the process waits for the ON time (step 106), pulse output to the port is then stopped (step 107), an OFF time counter is started (step 108), and the process waits for the OFF time (step 109). When the OFF time has passed, the output request flag for the port for which an output request was issued is cleared (step 110), and the process loops back to step 100 to determine whether the next output request was received. If there is no output request, the process continues to look for the next output request.

It should be noted that the OFF time in the present embodiment is set to the same time as the ON time specified by command. It is also possible, however, to set the OFF time by means of a command parameter using a process similar to that described above. Note that the OFF time is set and pulse output requests are effectively prohibited during this OFF time period to limit the drive duty of the control object. More specifically, if an OFF time is not defined and commands are transferred continuously, the ON state duty of the control pulse may be excessively large.

In the present embodiment, the pulse output process shown in Fig. 4 is executed during the standby loop of the printing apparatus control program executed by CPU 50. This loop is not executed during the printing process, and the pulse output process is therefore not executed. In this case, the pulse output process is executed when one printing process is completed and the control program returns to the standby loop before starting the next process.

However, if it is necessary to execute the pulse output process irrespective of the printing process, the process can be executed by means of an internal interrupt, timer interrupt, or other known interrupt process.

If there is sufficient power supply capacity, the printing process and pulse output process can be executed in parallel. More specifically, the ON time wait period (step 106) and the OFF time wait period (step 109) in Fig. 4 can be used to easily achieve parallel printing and pulse output processes by means of time-shared printing control. Furthermore, the printing process functions can be handled by print controller 43 using a micro-controller, for example, and the pulse output process can be executed in parallel by CPU 50.