Make your own free website on
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.

Prev     Beginning