Printer parking break

A so-called feature nearly foils plans to speed up wide-format inkjet printers.

Dan Dull, Novo Engineering -- EDN, November 11, 2011

About 15 years ago, I was working for a wide-format inkjet printer company in the San Diego area. The printers we designed could print on rolls of paper that were 5-feet wide and several hundred feet long. Needless to say, an enormous amount of data needed to be sent to these printers to keep the printheads moving and the paper advancing. One of the key product requirements was throughput, specified in square feet per hour. Ideally, the printhead firing rate governed the throughput. The rest of the system needed to make sure the printheads were always squirting ink onto the paper. If the printheads we not squirting, time was being wasted. Our customers tended to get upset when their expensive printer paused and hesitated while printing posters because they charge their customers by the square foot. The longer it takes to print the poster, the less money they make.

This Tales From The Cube is a finalist in the Tales From The Cube: Tell Us Your Tale Contest, sponsored by Tektronix. Read all finalist entries here and then cast your vote for a winner!

My primary jobs were to design the controller board for these printers, design the FPGA that was on the controller board and write the low-level firmware that interfaced to the hardware. Each new product we developed was roughly twice as fast as the previous product, so I constantly had to find new ways to process the image data faster. I started evaluating new microprocessors because the one we were currently using was occasionally making the printer hesitate after each pass of the printheads and would definitely not be sufficient for the next-generation product.

After doing some research and analysis, I found a microprocessor that I felt could handle our processing needs for at least several more future products. I designed a controller board using this part, designed the FPGA logic, and wrote the device drivers and some test code. Everything seemed to be going well. All of the major functional blocks appeared to be working correctly.

The firmware team started working on the project, and once they had written enough firmware to make the printer function, it was apparent that this microprocessor appeared significantly slower than the old one. It should have been at least 10 times faster based on clock rate alone, but it also has caches and a DMA controller to speed things up even more. The board had copious amounts of high-speed memory and the FPGA had logic to offload some of the data processing tasks from the main microprocessor. Something was horribly wrong, and because I designed the system, I was the only one who could fix it.

The user’s manual for the microprocessor consisted of two books with more than 1000 pages each. I grabbed both books, found a quiet place, and started reading. This was before PDF files were common so searching was a very manual process. Unfortunately, the index did not have an entry for “Why is this thing so slow?”


As I read more about this debug feature, I discovered that the microprocessor’s performance is affected by this feature. If you want more detail about what is happening internally, the core slows down. Hmmm. I checked to see what the default setting was and was pleased to discover that maximum detail, slowest core was the reset value. I modified the firmware to turn this feature completely off and the microprocessor started running at full speed. The printer ran at full speed with no hesitation at all.

After discussing my findings with my coworkers, this feature became known as the parking brake.

---

Dan Dull currently works as an electrical engineer for Novo Engineering, a product development company in Vista, CA.