Filter
Top Products
Chapter 5: Programming commands90
A776 (B780) Programming Guide A776-PG00001 C 12/09
Preferred implementation
For a new application the GS (1D) sequences are recommended to avoid possible misinterpretation of a DLE (0x10)
sequence as a clear printer (0x10 0, ASCII DLE NUL) command.
An application using these GS (1D) sequences, does not need to distinguish for the printer between the new real time
commands and the clear printer command. This implementation is ideal for an existing A756 application that already
uses the clear printer command or for a new application being developed.
Alternate implementation
The alternate implementation uses the DLE (0x10) sequences as implemented on other printers. An application using
these DLE (0x10) sequences and the original A756 clear printer command (0x10) must distinguish for the printer
between the new real time commands and the clear printer command by adding a NUL (0x00) to the clear printer
command.
An application using these DLE (0x10) sequences must also send the second byte of the sequence within 100
milliseconds of the rst, to prevent the rst byte being mistaken for a clear printer command.
Rules for using real-time commands
Three situations must be understood when using real time commands.
First, the printer executes the real time command within a few msec of detecting it in the input buer 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 buer.
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 nally executing that other command from the buer; 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 buer
Applications should not let the buer ll 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 buer behind any
other data there, and ush them out in the order in which they were received. When the printer is busy due simply to
buer full (that is, it can’t print data as fast as it can receive it), then data continues to be processed out of the buer at
approximately print speed and the real time commands will eventually get ushed out.
When the printer is busy due to an error condition, then data stops being processed to the buer until the condition
clears one way or another. In either case, but more quickly in the case of an error condition, the buer can ll with real
time commands.
When the DLE (0×10) sequences are being used, the last byte stored when the buer lls up could be the DLE (0×10)
code, with no room for the subsequent EOT or ENQ. When this lone DLE (0x10) byte is nally processed out of the
buer it will be interpreted as a clear printer command.
Similarly, when the GS (1D) sequences are being used, the last byte stored when the buer lls 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 nally processed out of the
buer it will use the next byte, whatever it is, as the second byte in its GS (1D) sequence.
Continued . . .