Trouble-Shooting i5/OS Printer Problems in a Warehouse Environment

Published: April 22, 2009

Hey, Joe:

We have four IBM 6400 printers that produce pick tickets and labels. The printers are connected via SNA to a Perle 594e controller attached to our i5/OS box. Today, all the printers are freaking out. They start printing a pick ticket and then print garbage. Then they disconnect and I have to restart their printer devices. I have 1,000 tickets to print for tomorrow's production. What's happening?

--Jim

I contacted Jim and he gave me a few additional pieces of information that weren't included in his original email. There had been a power brownout during the afternoon before the problem started. There had also been some ceiling work occurring above the printer room where the IBM 6400s were located.

So there were plenty of places to check around. In my experience, this type of issue was usually caused by one of three things.

1. A change to the program the produces the pick ticket spooled files. High-speed and barcode printers sometimes behave badly when they receive bad or malformed print streams.
2. A problem with the printers themselves that occurred due to a power outage or the printers just breaking down.
3. A communications issue where there was either a problem with the Perle controller or with one of the connections the Perle controller was using.

Here's how I helped Jim trouble shoot the problem and solve it.

Regarding the first issue, Jim contacted his programming department and they confirmed that there had been no changes to the pick ticket program. Furthermore, there were five other warehouses that used that same program for pick tickets and if there was a problem with the print stream, it should also have shown up at the other warehouses printers. It didn't. So we ruled out that it was a programming issue.

It was also possible that the printers had been damaged during the brownout. However, the problem was showing up on all four of the 6400s. It was odd to think that all four printers were damaged by an electrical surge, but you never know. To test this theory, we moved the same pick ticket spooled files that were crashing these IBM 6400s to a printer queue servicing another 6400 in a different location. That printer printed the pick tickets just fine without crashing, so we ruled out the idea that the printers were damaged.

The next step was to examine our Perle 594e controller. Through cabling, the Perle controller services printers in the room where the IBM 6400 printers were located, as well as in another part of the distribution center where they print barcode labels on Zebra printers. The Zebra labels were coming out fine, which undermined our case for the Perle going bad. Just to be safe, we restarted the Perle controller to let it re-establish all its connections. No luck. The Zebra labels continued to come out fine while pick ticket printing continued to be a disaster.

At this point, we had isolated the problem to the location that we were trying to print the pick tickets to, rather than to the pick tickets or the printers themselves. Now, the only way to make sure that the location was hurting printing was to move a printer. We decided to move one of the IBM 6400 printers away from the printer room over to the computer room where the Perle controller was located. Once there, we connected the moved printer directly to the Perle controller. Then we tried printing the same pick tickets on the same printer in a different location.

It worked. The pick tickets came out perfectly without any garbage or crashed printer devices. To be sure and to produce our pick tickets faster, we moved a second printer to the computer room. We also hooked the second printer directly up to the Perle 594e controller. That printer started behaving again.

This confirmed that there was a communications problem between the Perle controller and the printer room, probably caused by the ceiling work or the brownout. Jim's group hired a cabling company to come out the next day and find and fix the problem.

As for producing the pick tickets for the next day's run, since they already had two IBM 6400 printers directly connected to the Perle controller, they printed the rest of the day's run on those printers. The distribution center personnel were able to pick product as usual the next morning.

The morale is that it isn't difficult to troubleshoot high-speed printer issues, if you know the drill. You can generally localize a printer problem by performing the following tests in succession.

1. Try printing the same output on a different printer in another location. If the problem follows, there could be an issue with the spooled file output or with the program producing the spooled file.
2. Try printing the output to a different printer in the same location, if available. If the problem doesn't follow, the issue could be with the problem printer or the connection that the printer is plugged into.
3. If the problem is occurring on multiple printers in the same location, chances are good that the issue is occurring somewhere along the network connections that are feeding those printers. Check your connections and any equipment, such as a Perle controller, that connect your printers to your iSeries, System i, or Power i machine.

This isn't an exhaustive list, by any means, but it does illustrate a basic methodology for detecting printer problems in a warehouse environment.

--Joe

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot