Howtek

logo Howtek_131_I left GenRad to work for Howtek as a firmware engineer.

Howtek produced high quality PMT based drum scanners for the graphic arts market and later on CCD based medical films scanners.

I started at Howtek in the firmware group and spent most of my time in the company as the firmware lead for scanner development. Towards the end of my time at Howtek I developed a free standing Dicom-3 scanning and small scale database application to support the company’s entry into the medical imaging market.

The embedded development involved a mix of C, C++ and x86 assembler language programming. It also involved substantial image drumscanner-nameprocessing, stepper motor control and multi-threaded and interrupt based hardware interface and data pump management coding. I architected and developed the software framework that ran on top of the Kadak embedded kernel on the SM7500 drum scanner and all later products.

  • D4000 Drum Scanner

    When I started at Howtek, their one product was the D4000 drum scanner. This was a large, high quality, PMT based flying spot scanner selling for around $40, 000. The competing products were two to three times as expensive and the image quality provided by the Howtek device was competitive. The displayimagefirmware implementation was hosted on a 386sx PC motherboard with proprietary ISA bus cards providing SCSI, data acquisition and motor control boards (based on 80186 processors with dual ported SRAM communication). The firmware implementation was a service loop design with no interrupt support.

    I added IRQ based DMA support for data transfers. I coded the support for monochrome output with hand tuned assembler language code with proper channel weighting. I spent much of my time fixing bugs and addressing performance bottlenecks in the system.

  • SM7500 Drum Scanner

    With the success of the D4000, we decided to pursue a higher end device. The SM7500 supported two drum sizes. The larger drum allowed scanning of larger originals, but limited the resolution to half that supported with the smaller drum (same angular resolution but double the circumference). I lead the images (1)firmware aarchitecture design for this machine. The service loop design of the D4000 had proven to be problematic for maintainability and performance. In the SM7500 we chose the Kadak Inc. AMX real time kernel as the basis for the firmware. I added an extended messaging layer on top of this code to support variable sized messages between tasks and manage local and remote transparency as we intended to continue with the multiprocessor approach from the older design.

    The original design was expected to add modular support for Ethernet communications and direct transfers to SCSI based storage media. The previous product was entirely host transfer based with a SCSI-2 connection for control and data transfer. These alternative options were never released in the product as demand for the high end scanner was insufficient to justify the additional development and testing effort, but much of the research into IP implementation and file system support was completed.

    I was solely responsible for the code in the ‘main control processor’ that coordinated the activities of the other components in the system. I designed the messaging architecture and implemented the board support package for the real time kernel startup process. I was firmware lead for the overall development process. The resulting scanner was an engineering success. We met our performance and reliability goals and the system was well received. The cost and timing of our release was less successful as we entered the market with an expensive, high end product as the low end flatbed scanners were moving up in quality and performance to take a chunk out of overall sales volumes.

  • SM2500 Series Flatbed Scanners

    As the lower end flatbed scanners were taking the market by storm, we decided to design a product in the high end of the flatbed space. In order to control costs we moved from a multiple board, multiple processor design to a single 80386ex embedded processor on one large board containing all of the electronics. imagesThe software architecture that I created for the SM7500 had been structured to accommodate this sort of coalescence and the work involved in bringing all of the subsystem code into one CPU was straightforward.

    The physical hardware was housed in a large but conventional flatbed scanner chassis. Imaging was handled with a 8000 element CCD sensor. Motor control was changed dramatically as the previous systems had used hand coded assembler language with a dedicated 80188 CPU to control stepping. In the new system the I implemented the motor control functions using a timer-counter on the 386ex CPU with a fast, high priority interrupt handler to feed new winding patterns to the motor control pipeline. The windings register was two stage pipelined to ensure accurate step timing. When the timer triggered the bit pattern in the CPU accessible backing register would be written to the ‘live’ latch that controlled the stepper motor drive transistors. A high priority IRQ would be delivered to the CPU and the interrupt service routine would load the next windings pattern into the backing register and (if needed) reprogram the timer/counter for the next step interval. Reprogramming was only necessary if we were ramping the step timing to accelerate the scanner carriage for a long distance transfer.

    In addition to the graphic arts oriented ‘DX’ model with a cold cathode fluorescent illuminator the pro-g model was our first attempt to address medical film scanning. The development team implemented an innovative high intensity red LED illuminator using commodity LEDs and a DAC per LED to tune the output and achieve a ‘flat’ field of illumination.

    When Howtek gutted their development team after finding it difficult to get quick entry into the x-ray film scanning business I realized that we no longer had enough people to develop new products. A long span of time doing little but mandatory bug fixes on existing designs didn’t appeal to me and I left Howtek for Puma Technology.

One thought on “Howtek”

  1. Interesting. I always wonder about why the scanners used only SCSI. The design of the devices was simple, and modular enough that even 20 years later there are many still in operation. The HR8000 was the exception.
    I stopped by the current location of the company (icadmed) looking for technical information on the scanners and one of the employees told me that all the info was gone, dropped in a dumpster. Sad, very sad.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.