Updated May 23 2003
Troubleshooting PCL and PJL
This is basic troubleshooting and does not include in-depth debugging
of your code. It includes how to get code to look at. You
have to know how the code works already :-)
When you get a call where someone says "the printer is not doing what I
want it to", we can look at the code being sent to the printer to see
what the user is telling the printer to do. You almost always find
that they are sending the wrong commands to the printer or the coding is
bad. I have seen where a user was inserting PCL commands directly
before the first PCL reset and then wondering why no changes where being
made, of course it was the copiers fault ;-).
If you have read the previous pages in this short introduction you will
already know about printing to file. This is very handy when
printing from a windows environment. You can do this in other
environments as well. With many spoolers you can continue to
accept print jobs but disable printing. This keeps the spool file
in the queue, you just have to know where the queue is and which is the
spooled data file and which is the control file. Also in some
environments, you can not disable printing. (Hang on, I'm building
up a case) There is also perception of the user, we want them to
feel we are actually using the code that would have gone to the printer.
Even though the spool file is what goes to the printer, not all
users understand the process.
So what would happen if we could run a little application on our laptop
that acted as a network printer? We could give our laptop the same
IP address as the printer, disconnecting the printer of course, and have
the user send the print job the way they would normally. Only now
the job goes to our laptop and we have the exact code that would have
gone to the printer. Of course there are many different protocols
that we can use to print to the printer but by far the most common is
LPR/LPD on port 515. Almost every operating system and certainly
all current operating systems supports this protocol.
Here is an application (121k) you
can run on your laptop under Microsoft Windows 9x/??/?? that acts as a
LPD (Line Printer Daemon) on port 515. Create a new directory and
unzip the file into this new directory. I recommend a new
directory because the control and data files recieved will be written in
the directory the application is in and having an empty directory will
make things easier to find. Of course you can do what ever you
want. Give your laptop the same IP address as your printer and
disconnect the printer from the network(turn it off or remove the
cable). When ready double click on the application.
When the application starts it will open a window, that you can not
interact with, displaying the actions taken on the port. When you
send a print job some basic information like the IP of where the job
came from and the sizes of the control and data files will be displayed
in the window. The captured files are then written to the
directory running the application as explained above. The .bin
file is the file we want to work with, the data file. The .ctl
file contains some control infomation that we aren't interested in (well
you might be).
******Standard we aren't responsible disclaimer and thanks to Rocco for
making it available*******
Now we can open the spool file in a hex editor. You could use a
text editor but the control characters are hard to read ;-). You
can pick up many errors in the code just by viewing it. There is
also a program you can run the spool through that converts PCL to text.
I use PageTech's PCLCodes
(173k), it is a freeware application that makes the PCL codes human
readable and even points out PCL errors. There will be some errors
generated with tray selection as Canon's PCL codes for tray selection
are different than that of HP.
Another handy tool is a PCL viewer. I have not been able to find
any freeware ones but there are many purchasable ones often with trial
versions. You can check the PCL page
for links to some or just search google for "pcl viewer". The
viewer should display on your screen what the output should look like.
So if your output on the copier looks bad, view in the PCL viewer.
If it looks bad there, the coding is probably bad.