A795 User Guide: Programming Supplement
Chapter 4: Programming commands
83
Rules for using real time commands
Three situations must be understood when using real time
commands.
First, the printer executes the real time command upon
receiving it and will transmit status regardless of the
condition of the DSR signal.
Second, the printer transmits status whenever it recognizes
a real time status transmission command sequence, even if
that sequence happens to occur naturally within the data
of another command, such as graphics data.
In this case the sequence will also be handled correctly as
the graphics data it is intended to be when the graphics
command is executed from the buffer.
Third, care must be taken not to insert a real time
command into the data sequence of another command that
consists of two or more bytes.
In this case the printer will use the real time command
sequence bytes instead of the other command’s parameter
bytes when finally executing that other command from the
buffer; the other command will NOT be executed
correctly.
These three situations generally preclude use of standard
DOS drivers for the serial communication ports when
using real time commands.
Moving data through the buffer
Applications should not let the buffer fill up with real
time commands when the printer is busy at the RS-232C
interface. A busy condition at the RS-232C interface can
be determined by bit 3 of the response to 1D 05, or 1D 04
1, or 10 04 1. The reason for a particular busy condition
can be determined by other responses to 1D 04 n or
10 04 n.
Although the printer responds to real time commands
when it is busy, it will place them into the buffer behind
any other data there, and flush them out in the order in
which they were received. When the printer is busy due
simply to buffer full (that is, it can’t print data as fast as
it can receive it), then data continues to be processed out
of the buffer at approximately print speed and the real time
commands will eventually get flushed out.
When the printer is busy due to an error condition, then
data stops being processed to the buffer until the condition
clears one way or another. In either case, but more quickly
in the case of an error condition, the buffer can fill with
real time commands.
When the DLE (0x10) sequences are being used, the last
byte stored when the buffer fills up could be the DLE
(0x10) code, with no room for the subsequent EOT or
ENQ. When this lone DLE (0x10) byte is finally processed
out of the buffer it will be interpreted as a clear printer
command.
Similarly, when the GS (1D) sequences are being used, the
last byte stored when the buffer fills up could be the GS
(1D) code, with no room for the subsequent EOT or ETX
or ENQ. When this lone GS (1D) byte is finally processed
out of the buffer it will use the next byte, whatever it is, as
the second byte in its GS (1D) sequence.
To guard against this situation, the application must
determine the cause of a busy condition and take
appropriate action or pace the real time commands to
avoid filling the buffer. There is a minimum of 256 bytes
available in the printer’s buffer when it goes busy.
Busy line and fault conditions
If the printer is in error condition (cover is open, paper is
exhausted…), the printer will still accept data, respond to
the batch mode status commands (1B 76 and 1B 75 0),
handle the cash drawer commands, and not go busy until it
actually tries to execute a print command. Then it will stay
busy and stop processing data out of the receive buffer
until the condition clears. It will respond to the real time
commands as described below.
