Canon Pixma MX340 Teardown Index

I've taken apart my retired Canon Pixma MX340 multi-function inkjet. Its task-specific plastic components are heading to landfill and its electronics core twist-tied to a sheet of cardboard for potential future reuse. I found a lot of interesting details as I went though this teardown and learned lessons that I hope to apply to future projects. I wrote down a lot of my observations here, so much that it has become pretty unwieldy to find specific information. Text search helps, but I also found myself frequently clicking "Next Post" and "Previous Post" to find a specific piece of information.

This post will be my first effort to help streamline finding references: all my MX340 posts listed in chronological order with as few words as practical (sometimes just a title excerpt) to remind my future self of their relative context. There are probably other ways to organize this information, but I am ignorant of the library science involved so this first effort is merely chronological.

Introduction

Tearing down inkjet printers as a learning exercise. General thoughts followed by an overview for this Canon MX340.

Phase 1: Functionality-Preserving Disassembly

• Examine power supply and removal of back and side panels.
• Automatic document feeder (ADF).

  • Lid is home to rollers but lacks its own motor. A preview of Canon's part reduction engineering.
  • Control panel freed.
  • Motors and sensors.
  • Hinge was designed for easy removal, but I didn't figure it out until after I had already ruined it.

• Scanner layer.

  • Closing damper mechanism.
  • Image sensor and flatbed glass.

• Inkjet printing engine.

  • Starting with the print head parking area.
  • Followed by a look at its paper feed path.
  • Then the paper feed motor and gears (including first look at encoder disc).
  • Paper output tray door has its own opening mechanism.
  • Print carriage motor (including first look at encoder strip) is adjacent to a WiFi module and phone line audio speaker.

• Declare phase 1 complete.

Phase 2: Probe certain electronic subsystems as system runs

• Start simple with cover switch and power supply.
• ADF

  • Photo-interrupter sensors pinout.
  • Stepper motor under oscilloscope.

• Scanner startup homing sequence and spoofing that sequence.
• Scanner stepper motor pinout and oscilloscope.
• Scanner contact imaging sensor (CIS) was challenging fun to decipher!

  • Illumination RGB LED under oscilloscope.
  • Research into Canon CIS products.
  • Finding the easily explained subset of pins (mostly RGB LED) on CIS connector.
  • CIS candidate image data line under oscilloscope.
  • Guessing the remaining pins on CIS connector.
  • Properly reusing this CIS will be hard, but I have some partial reuse ideas.

• Print carriage and paper feed DC motors

  • Motor control under oscilloscope.
  • Paper feed encoder disc sensor under oscilloscope.

• Control panel got a thorough examination.

  • To guide my exploration of how it works, I first reviewed of what it needs to do.
  • Then find the power and ground pins on its connector to main board.
  • Repeat exercise for connector to LCD screen.
  • Use that LCD pinout to inform probing the control panel IC.
  • Tracing circuitry required a big photo stitch of the control panel.
  • Power button and LED are wired directly to main board.
  • WiFi LED has its own power source, different from rest of control panel LEDs.
  • Pinout of control panel connector to main board.
  • Pinout of control panel IC including button matrix.
  • Oscilloscope examination of control panel communication.

    • Reporting button presses.
    • Updating LCD screen.
    • Control IC "Chip Enable".
    • Oscilloscope trace appears to be asynchronous serial.

  • Logic probe examination of control panel communication.

    • Custom probe wires helped confirm: asynchronous serial 250000 baud 8E1.
    • Design list of six scenarios for logic analysis.
    • Decoding idle and four example button presses.
    • Picked out pattern for (but not yet decoding) LCD update data.
    • Logic analysis of control panel activity for machine states:

      • Plugging in.
      • Powering up.
      • Standing by.
      • LCD blanking and recovery.

    • How to decode LCD update data?

      • Custom Saleae HLA can't do it.
      • Don't overthink it, Calculator and Excel can do a lot.
      • Decoding LCD update data with Excel.

  • Now that I understand my captured scenarios, what's next?

    • Define goals for desired data filter and go searching.

      • Wireshark is not the right tool.
      • Neither is Bus Pirate.
      • SerialTool comes closer but not quite.

    • I guess I'm creating my own tool!

      • Using USB serial adapter and pySerial library.
      • Get the full set of button matrix scan codes.
      • Decode LED control bit flags.
      • Project delayed by faulty USB serial adapter. Once I figured out it was faulty, I ordered a replacement which showed some mild evolution.
      • Challenges in simultaneously listening to two serial ports.
      • Process the commands, ignore bulk transfers.
      • Track known command sequences with a lookup table.
      • Quick-and-dirty data filter tool did its job.

  • Logic probe examination of LCD screen communication.

    • Power and ground already established, leaving five unknown wires.
    • Start in analog mode to probe pin assignment.
    • LCD screen pin assignments.

  • Summary of control panel findings.

• Paper feed motor examination goals.

  • Start by setting data recording objectives, then start hunting for quadrature decoders.

    • Logic analyzer candidates. Saleae no. Sigrok maybe?
    • Arduino support for sigrok is incomplete.
    • ESP32 Pulse Counter (PCNT) peripheral.
    • Go with known quantity of Arduino quadrature decoder library.

  • First pass: periodically output decoded quadrature counts.

    • Powering up.
    • Standing by.
    • Print a page.

  • Second pass: decode raw count into motion.

    • Decode based on sampling rate was unreliable.
    • Switch decode based on microsecond timestamp.
    • Timestamp can be improved, but probably not worth the effort.
    • Stay with integer math by using microseconds per count.
    • Graphing along with position.
    • Simple debounce eliminated majority of noise.
    • Observations on motor acceleration and deceleration.
    • Use dwell time to delineate motions.
    • Decoded output looks promising.
    • Summary of decoded motions.

  • Encoder disc delivers 8640 counts per revolution.
  • Paper feed motor examination summary.

Phase 3: Disassembly Without Concern for Preserving Functionality

• Print carriage as starting point.

  • Range of motion: 32.5cm.
  • Motor and mystery lever.

• Print head maintenance assembly.

  • Range of motion.
  • Topside components.
  • Underside components.

• Ink cartridge bracket.
• Print carriage removed.
• Mystery lever is a gear shifter!
• Distracted by ink graveyard.

  • Disposal flow path.
  • Peristaltic pump.

• Back to gear shifter.

  • Paper tray gears and cams.
  • Freewheel mechanism using capstan effect.

• Mass production priorities different from my project priorities.

  • But I do want easy serviceability.

• Paper feed motor+encoder removed.
• Print carriage disassembly to access encoder sensor.

  • Remove lower rail.
  • Open print carriage.
  • Pinout of encoder sensor.
  • Encoder strip delivers 600 counts per inch.

• ADF gearbox disassembly.
• Cursory review of main circuit board.
• Disembodied electronics nervous system still runs.
• Big group photo of all parts laid out flat.
• Salvage scanner flatbed glass.
• Disembodied electronics mounted on a sheet of cardboard.

And finally, the summary index. (You are here!)

Bonus item: aborted teardown of Canon 210 (black) and 211 (color) ink cartridges.

Follow-Up Project: CircuitPython and MX340 Control Panel

CircuitPython learning project: write code to allow a microcontroller to communicate with control panel following precedence of MX340 main logic board.

• Initial partial UART communication with busio.
• Full communication needed two parity bits, not just one. (250000 8E2)
• Vertical offset problem traced to missing initialization command.
• Am I on the right track? Quick test by reverse bits fed into adafruit_framebuf.
• Right track verified, modified adafruit_framebuf directly for better performance.
• Abandoned effort to make LCD compatible with displayio.
• Data transmission collision avoided with async Lock.

At this point the exploratory project was getting mature enough for conversion to library.

• Use async Event for synchronization.
• Reorganize to suit Python context manager syntax.
• Expose button matrix scan code as key events.
• I can buy FPC connector breakout boards instead of soldering 1.0mm pitch pins.
• Use FPC connector breakout board to wire up remaining buttons and LEDs.

Finale: Tiny Cat & Galactic Squid on MX340 LCD.

---

Whew, that was a lot to write down, but at least it wraps up documenting this lengthy project. Now I can document another lengthy saga that took place at the same time: debugging bug checks on my Dell XPS 8950.