Wincor Nixdorf TH320, Programmer'S Manual

Page: 155 / 157

TH320/TH420 Programmers Guide
147
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 first, to prevent the first 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 buffer
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 (0×10) sequences are being used, the last byte stored when the buffer fills up could be
the DLE (0×10) 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.
***