When installing a printer, the first step should be to make sure that the printer is actually working independently of the software. The following section outlines some simple diagnostics that you can use to check printer connectivity.
The most flexible and highest throughput printer interface is via a network (TCP/IP) connection. Most high performance printers have a built in network interface, or you can attach them to a printer server box which provides a network interface. Network print boxes can be obtained from Hewlett Packard ( http://www.hp.com), Lantronixs ( http://www.lantronix.com), and Rose Electronics ( http://www.rosel.com).
The network interface usually supports multiple network printing protocols.
The most common are the LPD (RFC1179), Socket API, APPsocket, SMB,
and Novell Netware interfaces.
LPRng directly supports the LPD (RFC1179) and Socket API interfaces,
and you can use the
smbclient program from the
Samba Software Package for the SMB interface.
There are no plans to support the Novell Netware interace,
given the wide range of alternatives.
The most powerful network connection is via the the Socket API. The most common Socket API, and a de facto standard, is the one used by Hewlett Packard on their JetDirect cards, which allows a TCP/IP connection to port 9100. This is a TCP/IP port on the printer that provides a direct connection to the print engine, similar to a serial or parallel port. This connection is usually full duplex and provides error messages and status information during printing.
The Socket API is extremely simple.
You can use the
netcat
utility by Hobbit <Hobbit@avian.org>
to test that this interface is available and working.
If ellipse.ps is a test file, then:
The simplest and easiest way to print a file to a network printer appears
nc printer.ip.addr 9100 < file
Example:
nc 10.0.0.25 9100 < ellipse.ps
The second most common network print protocol is the RFC1179 TCP/IP protcol. This is described in detail in later sections of this document, but basically consists of a simple set of command and responses.
During the job transfer no error information is returned, or other status information. This must be obtained by reconnecting to the printer and sending a print status request. This is a major weakness of the RFC1179 protocol.
When the LPRng software package has been installed, it is easy to check printing by using a command of the form:
lpr -Plp@ipaddr -Dnetwork file
Example:
lpr -Plp@10.0.0.25 -Dnetwork ellipse.ps
The -Plp@ipaddr option will cause the lpr program to make a direct
connection to port 515 and send the print file using the RFC1179
protocol.
The -Dnetwork debugging option will cause detailed network status to be
displayed during this process.
In addition to the lpr program,
the Perl cheap_lpr program can be used.
This and other test programs are in the LPRng Distribution UTILS directory.
The APPsocket interface is supported by Tektronix and some other printer vendors. It is similar to the Socket API, with a couple of minor differences.
CR/LF
is sent to UDP port 9101, the printer will return a packet to the sender
containing print status information.
This information indicates the printers current status (busy, idle, printing)
and any error conditions.The LPRng IFHP filter program has support for the APPsocket interface. Also, there are Perl or other programs which can communicate with the printer. See Tektronix P450 and Family for details.
A ``network print server'' is usually a box (external model) or card in a printer (internal model) which has a network connection to a TCP network and software to implement a LPD print server. If it is an external model, The parallel or serial port of the printer is connected to the box, and the print server may support multiple printers. If it is an internal model, the server is usually nothing more than a Network Interface Controller and a ROM containing software that the microprocessor in the printer uses.
The print server may support multiple printing protocols, such as RFC1179 (TCP/IP printing using the LPD print protocol), Novell Printer Protocols, SMB print protocols, and Appletalk protocols. One of the observed problems with Network Print servers is that while they can usually support one protocol and one user at a time quite well, when you try to use multiple protocols and/or multiple users try to transfer print jobs to the printer, the printer may behave in a very odd manner. Usually this results in a printer failing to finish a job currently being printed, and unable to accept new jobs.
Several of the newer models of print servers have Simple Network Management Protocol (SNMP) agents built into them, and can provide detailed information about their internal functions. By using a SNMP manager such as SunNetmanage or HP-Openview, you can monitor your network printers activities.
I recommend that you use only a single protocol to send jobs to the printer. If you can, I also recommend that you use a print spooler and have only a single host system send a job to the printer.
My best advice on connecting to network printers is not to use the the built-in LPD server, but to use the direct TCP/IP connection to the print engine. Usually this is done to particular TCP/IP port on the printer. For the HP JetDirect and other HP products, this is usually TCP port 9100.
Once you have the direct connection, you can now use various filters to preprocess the print job, insert PJL and PCL commands, or convert text to PostScript or PCL for better print quality.
In most UNIX systems the printer port has the name
/dev/lpt,
/dev/prn,
or something similar.
On most systems the
dmesg utility will print a list of IO devices found
during system configuration.
Use the following commands to get the information and scan
for the device.
You should also make sure that the printer device is
available.
dmesg >/tmp/a
grep lp /tmp/a
ls /dev/lp*
Gordon Haverland
<haverlan@agric.gov.ab.ca> supplied this little script,
that will assist with this:
#!/bin/sh
#set -v -x # uncomment for debugging
PATH=/bin:/usr/bin
printer=
for $printer in /dev/lp* ;
do
echo PRINTER TEST to $printer 1>&2
for i in 1 2 3 4 5 6 7 8 9;
do
echo PRINTER $printer $i > $printer;
done
echo -e \\r\\f > $printer
done
exit 0;
If your printer is connected to the device name you provided, then you should get a page of something out. If the output suffers from the ``staircase'' effect, you will see the numbers ``marching'' across the page, otherwise the numbers will all be in a single column.
If your printer is attached by a serial line, then you may need to set the serial line characteristictics before sending the job to the printer. Here are a set of guidelines to following when attaching a serial port printer to a serial line.
1. Check to make sure that the line is not enabled for login.
Logins are usually managed by the
getty (BSD)
or
ttymon (Solaris, SystemV).
Check your system documentation and make sure that these daemons are not
managing the serial line.
2. Check the permissions and ownership of the serial line. For the most easy testing, set the permissions to 0666 (everybody can open for reading and writing). After you have made sure that you can send jobs to the printer, you might want to change the ownership of the serial line to the LPD server and change the permissions to 0600.
3. Make sure that you can print a test file on the printer via the serial port. This may require setting the line characteristictics and then sending a file to the printer. You should try to use 8 bit, no parity, with hardware flow control and no special character interpretation, and definitely no LF to CR/LF translation. The problem is that different versions of UNIX systems have different sets of stty(1) commands to do this. The following simple test script can help in this.
#!/bin/sh
# 9600, no echo, no CR
FLAGS= 9600 -raw -parenb cs8 crtscts
DEV= /dev/tty01
(stty $FLAGS; stty 1>&2; cat $1 ) <$DEV >$DEV
This shows using stty to set the flags, then to print the current settings, and then using cat a file to the output. If you attach a dumb terminal to the serial port, you can even use this script to ensure that input from the device is echoed to the output with the correct speed, parity, etc.
Experience has shown that serially connected printers are the least reliable and lowest speed. Where possible, it is stongly recommended that they be attached to a network print box which will provide a Socket API interace and handle the low level network to serial port protocol conversions.