I had been focused on seeing how the paper feed mechanism worked in my retired Canon Pixma MX340 multi-function inkjet, but I got distracted upon finding a large ink graveyard. Instead of ending up as ink on a page as users would prefer, a fraction of that expensive liquid was destined to be unused and instead dropped off into this absorbent diaper attached to the base.

All this ink was shot out of the cartridges while the print head was sitting in its parked position. It might have been priming the print head, maybe there was a clog that needed clearing. Whatever the reason, it was sprayed into the apparently-porous center of the ink-splattered print head maintenance assembly.

That ink was then picked up by these two tubes, one corresponding to color ink cartridge and the other for black ink.

Those tubes connect to this joint, where it’s clear the initial length of black ink tube is a different opaque material compared to remaining translucent tubes. They all feel about the same to the touch, soft and pliable despite their age. They also have the same outer diameter of about 3.8mm or possibly 0.15 inch. I suppose the difference in material is important for some reason I don’t understand. Other wise I would have expected a continuous length of tube instead of having this joint. It added parts count, assembly complexity, and risk of leaks in exchange for that unknown advantage.

Along with the just-freed paper feed assembly, I also freed the ink maintenance assembly. Flipping it over to rest on a sheet of tissue paper to absorb stray ink, I could now see the entire routing path for both ink tubes.

The color ink tube path ended at its disposal outlet towards the front of the paper tray assembly, and the black ink tube traveled around the back to its separate disposal outlet. Both tubes traveled past a circular assembly inside the paper tray gearbox, but on opposite sides of the circle in opposite directions. This bears all the signs of a peristaltic pump making it the first thing I want to investigate when I open up that gearbox.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Inside my old retired Canon Pixma MX340 multi-function inkjet is a gearbox that choreograph a sequence of motions to feed a single sheet of paper from a stack in the paper tray. I want to see that mechanical wizardry firsthand so I removed the screws holding the paper tray assembly to the base. Once freed, I lifted the assembly and the movement felt like I was peeling something sticky. That was unexpected… what happened?

I had found the hidden ink graveyard underneath, and an explanation for the tubes that caught my interest earlier. A thick layer of absorbent material has been installed across the base of this machine. Ink jetted in the parking position during priming or other maintenance tasks are pumped through those tubes and deposited into this diaper. The sticky sensation I felt came from semi solid globs of ink sticking to the bottom of the white plastic assembly.

My cheapskate brain can’t help but think “There must be over $100 worth of ink here, wasted!” I understand it’s not realistic to expect 100% of ink to end on a page, and some consumption for maintenance is unavoidable. But when ink cartridges are the profit center, it’s easy to be suspicious if all of this was actually necessary because they certainly have a perverse financial incentive to be wasteful.

There were two distinct ink disposal areas. A smaller one for the color ink cartridge, and a larger thicker one for black ink. I’ve used up a larger fraction of color ink absorption capacity due to my usage pattern: I have a black-and-white laser printer so I only used this inkjet when I needed color. Usually photo printing. Thankfully I was nowhere close to maximum capacity. It would have been a very messy discovery! Absorption capacity limit is why even “high volume” inkjet printers fed from bottles of ink have a finite service period before they require their diapers to be changed. I wonder if this MX340 has its own “stop using me” countdown for the same concern.

Now that I see the final destination for ink that would never end up on a page, I could trace the path taken by the ink disposal system.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Once I removed the horizontal X-axis (print carriage) actuator assembly from my Canon MX340 multi-function inkjet, I could see several mechanisms that were previously hidden. My attention first went to the lever that was pushed by the print carriage at a specific position. Now I can push on it with my thumb and turn the friction-coated paper feed shaft manually to see things move. Conclusion: this lever starts the process for feeding a sheet of paper from the stack in the paper tray into the print engine.

The other end of the lever sits within this T-shaped slot inside the gearbox. Normally it sits in this center position, which I will call “Neutral” because no rotational power is transmitted to the paper tray mechanism.

Once pressed, the T-slot can shift to one of two positions depending on which direction the paper feed motor is turning. I will call this position “Reverse” because the paper feed motor is moving opposite of the direction when printing.

In this mode, power is transmitted to the big rubber-coated roller in the paper tray, rotating it in the direction to feed paper. This is quite bizarre to me because, as already stated, this happens when the adjacent friction-coated paper feed shaft is rotating backwards, a recipe for a paper jam! I thought maybe the roller motion was just a side effect, but later gearbox teardown would confirm this is deliberate: a gear is specifically engaged in “Reverse” for this purpose, and it doesn’t move anything else. Whatever purpose this counter-intuitive motion serves, it is an intentional part of the system.

Shifting into “Forward” gear, I see a sequence of events consistent with feeding a sheet of paper from the paper tray.

Here is a closeup of the paper handling mechanism at the base of the paper tray.

1. This is the bottom of the paper tray. A spring-loaded and cam-operated mechanism pushes it forward and upwards so the top sheet of paper in the paper tray makes contact with the rest of the mechanism.
2. I think this pair of claws usually keeps the stack of paper separated from the feed rollers. During this paper feed sequence, the claws retract.
3. This mechanism has a smaller roller that receives no power, but its position can change to mesh with the big powered roller, or retracted so there’s a gap.
4. The big roller also receives rotational power in “Forward” via a different gear path, so now it turns in sync with the friction-coated paper feed shaft and there would be no paper jam.

A mechanical gear-and-cam system choreographs the timing and sequence for these actions. I look forward to seeing the details later in the teardown.

There’s nothing beyond motor rotation holding the “Forward” or “Reverse” positions. So as soon as the lever is released (by moving the print carriage out of the special engagement position) a slight bit of paper feed motor movement in the opposite direction will cause the mechanism to snap back into “Neutral”. This is a good candidate explanation for the small movement of 1800 encoder counts I saw repeatedly: the printer wants to make sure the paper feed mechanism is in “Neutral” before it does something else.

It should be fun to see how all this is implemented, so I freed the paper feed assembly to get at its gearbox… and immediately got distracted when I discovered an ink graveyard.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I had hoped to access the horizontal linear encoder sensor within the print carriage of my retired Canon Pixma MX340 multi-function inkjet, but after removing the ink cartridge mounting bracket, I found no easy path to that sensor from the front. I still want to probe it in an operational state, so I’ll remove the entire print carriage actuator assembly as one intact piece and possibly try again later.

The actuator assembly’s main structure is a sheet of stamped sheet metal, covering the entire width of the assembly and folded into the back and upper rail for the print carriage. As expected of a key structural component, there were many attachment points.

Two self-tapping plastic screws attach directly to the injection-molded base, one left and one right. The left side (close to the motor) featured a spring-loaded mechanism. Its right side counterpart lacked this feature.

Five machine screws attach the frame to three metal brackets. Two screws to each of the large brackets on the left and right, which are in turn secured to the plastic base with more self-tapping plastic screws. I removed these two large brackets from the plastic base but decided to leave them attached to the horizontal axis actuator metal frame for several reasons: (1) in the immediate term, the serve as handles or a convenient stand allowing me to sit this actuator assembly on its back without pinching any wires or getting in the way of anything that moves. (2) in the medium term, removing them won’t make accessing the linear encoder sensor any easier, and (3) in the long term, if I reuse this actuator assembly in something else, I will likely need these brackets too.

The final machine screw attached the wide metal frame to a tall metal finger rising up out of a hole in the white plastic paper tray assembly. Located width-wise between the paper printing area and the ink cartridge parking area. I’m curious if this tall finger was always planned from the start or added later in the design process when they needed more rigidity. It looks like it might be the latter.

Here’s the horizontal axis removed from the plastic base. My hand is holding on to the left side bracket that I had left attached. There was a paper feed optical interrupter sensor mounted to the back of this assembly, but that could be detached and visible dangling above the large paper roller in the center of the picture above. I stuck a folded-up piece of paper in the sensor to leave it in its normal blocked state.

Electrically, there is a pair of wires to the DC motor, and three sets of flexible cable for the print head assembly. The majority of those wires are for ink cartridge communication, leaving just a few for the horizontal quadrature encoder sensor. Should I still hold out hope I could figure out those wires later?

I set the assembly down on its back on those still-attached brackets, and powered up the system. It gave me a “check ink cartridge” error which is understandable by their absence, and the startup sequence is noticeably different. But it still ran the print carriage back and forth, so I’m cautiously optimistic I haven’t broken anything relating to that horizontal encoder.

I thought about continuing focus on this assembly until I could reach that horizontal encoder, but I set it aside because I found it more interesting to look at what was uncovered by its removal.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Playing around with the print head maintenance mechanism on my old retired Canon Pixma MX340 multi-function inkjet, I got some ink on my fingers. I see this as a preview of what I expect upon further disassembly, and decided to procrastinate that dirty job. Instead, I turned my attention to a less messy part of the mechanism: the print carriage bracket for holding the two color ink cartridges.

It started out simple and straightforward: there were two small Philips-head screws in the bottom corners of the carriage. Remove them, and the outer mounting rail comes off easily. And since it could no longer hold ink cartridges or their integrated print heads, this is the moment when my MX340 stopped being a printer and became just an assembly of interesting mechanisms.

Once that rail was removed, the two spring-loaded lids followed.

These lids turned out to be more complex than I had expected. I knew there was a flexture mechanism in front to latch a cartridge in place, and I expected one spring because the lid pops up when unlatched.

There were actually three springs. The strongest one pushes a piece of white plastic that, when closed, pushes the ink cartridge to keep it in place. I thought that was a generic enough action that a common part could be used across both lids, but they each had their own uniquely shaped part for the job and I couldn’t figure out why that was necessary. The third spring and smallest spring puts a tiny bit of tension on a small fragile (I broke it) black part whose purpose was not obvious to me. My best guess is it helps maintain proper spacing between the cartridge and its corresponding electrical contacts.

I had hoped removing rail and lids would have uncovered additional fasteners for further disassembly, but no luck. I’ve got a flat wall of ink cartridge electrical contacts and not much else. I had hoped to disassemble this carriage far enough to gain access to the linear encoder sensor, but no luck.

Looking around the side, I saw signs of additional fasteners, but they’re facing the opposite direction. I think I have to disassemble the print cartridge linear rail assembly, possibly removing the linear encoder strip and drive belt, before I could remove the carriage and access these fasteners. I will have to revisit this later and, in the hopes of preserving the “probe it while it is running” option for later, I’ll remove the whole horizontal actuator assembly as one intact unit.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I don’t know what’s involved in maintaining an inkjet cartridge, but I’m learning bits and pieces by poking around inside my retired Canon Pixma MX340 multi-function inkjet. I saw where the print head would rest when in its parked position, and thought the rectangular block of material sitting underneath the print head would be something soft and spongy to absorb excess ink. I was surprised when I poked at it with a cotton swab and found it was rigid. Interesting! Now I’m even more curious and want to see the rest of this maintenance assembly.

Looking at how its multiple parts interlocked, I came to the conclusion this one screw holds down everything on front side of this assembly. Removing the screw allowed this piece of plastic to slide aside and be removed.

This assembly hosts the latch that makes the wiper blades work, and it covers one side of the up-and-sideways track for the maintenance assembly allowing me to flip it up.

Now I can see the motion mechanism in its entirety. There are four tracks to guide this assembly as it moves 45-degrees up and then right, and in the foreground of this picture is the retraction spring pulling it down and left.

Each ink cartridges sit over a spring-loaded assembly with a tube in the middle. These springs push the pliable rubber surrounding the not-sponges to form an airtight seal that keeps the ink drying out. The tube going into the black ink assembly on the right is much longer, snaking up to the top of the assembly before coming back down. Tube for the color ink has a shorter more direct path, and also mostly translucent with only a few blotches visible. The black ink tube looks dark. From here I can’t tell if the tube is dark because it is made of a different material, or if it’s dark because its innards are covered with black ink.

If its insides are covered with ink, that would imply a porous material in the print head rest position and these tubes deliver some amount of vacuum. Sucking ink into these tubes for whatever maintenance purpose it might serve. Do these tubes lead to a reservoir? Is there a limit to their ink sucking capacity? I shall seek answers to these questions later. Right now I will hold off disassembling this ink maintenance station. It might be more useful intact as reference while I explore whatever those tubes are connected to. And it would definitely be a huge mess to disconnect ink-filled tubes, so I’ll procrastinate on that and do something else instead.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’m taking apart my old retired Canon MX340 multi-function inkjet and learning how it worked as I go. Its print head maintenance assembly is my current focus. Tracing through its range of motion, I finally have some answers for a question I had wondered about: why does it get so messy?

Given that inkjet printing required mechanisms that, well, jet out ink, it would be unrealistic to expect everything to stay clean and pristine. The print head needs a place to get primed and readied into a known operating state before it starts actually printing the page. A waste of expensive ink that I had grudgingly accepted as unavoidable. I had expected a sponge to absorb ink sitting below each print head, so I expected some ink splatter around maybe a 5mm perimeter around the print head outline. Once I opened the lid, I saw ink has been flung quite a bit further, up to ~40mm away.

After tracing through this assembly’s range of motion I now understand this mess was created by the wiper blades. Held up against the bottom of ink cartridges, they would have wiped off any ink from the surface of the print head. Once the cartridges moved past them, these elastic wiper blades would snap back to their vertical position. Surface tension would keep some ink on the blade, but the rest would launch for a landing elsewhere on this assembly.

There must be a slight angle between a cartridge and its wiper, as ink splatters are not symmetric: there’s visibly more ink flung towards the back of the printer (top of picture) than the front. The left-right asymmetry is more obvious and understandable, given the direction of the wiping motion. When these wiper blades snapped back vertical, that first motion would have moved left to right, with most of the energy on that first motion flinging ink to the right. Less (but not zero) ink would have been shed on the second motion to the left.

Curious about how much energy would have been involved, I took a cotton swab to poke at those wiper blades. (I didn’t want to get ink on my fingertips.) They have roughly the same flexibility as fresh automotive windshield wiper blades. I had expected them to have hardened up from age, more than a decade since their manufacture. Maybe they’ve hardened since new, but they’re still soft enough to do the job.

Since I already had soaked the tip of the cotton swab with ink, I poked at the rest of the ink-splattered components. All of the white plastic were rigid, no surprises there. There is a black rubber surround for each print head, and they are still very soft and pliable to form a good seal. Useful to keep ink from drying inside the print head.

The center, however, was a surprise. I had expected a soft spongy material to soak up ink, but the mystery material was actually quite rigid. Its surface texture implied some level of porosity like a sponge, but it had none of a sponge’s pliability. Very interesting! Maybe I can get more information about how it works by looking underneath.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’ve been playing with the print head carriage mechanism of a Canon Pixma MX340 multi-function inkjet, manually sliding it back and forth. I found no driveshafts conveying motor rotation, but I did find one lever it would push when at a specific position. The carriage also manipulates an ink-splattered assembly that I believe to be responsible for keeping the print heads in good working order.

The carriage pushes the maintenance assembly via its vertical tab on the far right, the only portion high enough to directly touch the carriage.

When the print carriage is absent, a spring pulls this assembly down and to the left. Here it is in the retracted position.

It can slide up and to the right at a ~45 degree angle for approximately 1cm. A small tab (circled in red) held back a section corresponding to the color ink cartridge so it is not raised as high as the rest of the assembly.

Beyond this point, the assembly only sides to the right with no further vertical movement. During this motion, the color ink cartridge subsection is allowed to rise up to join the rest. This right-most position, where the assembly is at its highest, corresponds to the print carriage parked standby position.

The two dark rectangles probably help keep the ink from drying out between print sessions. To the left of each of those two rectangles is a corresponding wiper blade. But if this assembly always moves in sync with the print head, there would be no wiping action.

Wiping is made possible by a spring-loaded latch. Here’s the maintenance assembly again in its highest right-most parked position as shown above, but at a different camera angle. The spring in the center of this picture pulls the assembly down and to the left.

As the print carriage moves left, the assembly is pulled left. It barely got past the 45-degree down-and-left transition before the latch (circled in red) blocked further movement. This blockage keeps this maintenance assembly in place while the print carriage continues moving left, and this difference in motion lets the wipers work.

The top of the latch reaches up towards the print carriage, high enough to be engaged by a tab on the carriage between the two ink cartridge slots. Ink cartridges were removed from this picture for a better view.

Once the wiping action is complete, the carriage moves further left and pushes the latch down.

This allows the maintenance assembly to slide the rest of the way down, retracting the two wipers away from their corresponding print heads.

Now that I have knowledge of how this assembly moves, I’ll take a closer look at its components.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’m looking at the print carriage (“X-axis”) mechanism on my retired Canon Pixma MX340 multi-function inkjet, working to determine what that motor might do in addition to moving print cartridges (and their integrated print heads) back and forth across a sheet of paper. I’ve established it has linear encoder feedback for closed loop control over its entire range (32.5cm) of motion. I know the paper feed (“Y-axis”) motor does a lot more than just feed paper, what else might the print carriage motor do?

One pulley for the print carriage toothed belt is mounted directly to motor output shaft, with no gearbox or other mechanisms, so it’s not driving anything else on this end.

I had thought perhaps there would be a shaft for power transmission connected to the other belt pulley, but that search came up empty. The pulley is mounted on a sliding mount under spring tension so it could absorb mechanical shocks to the carriage system. There were no means to convey rotational power.

Looking for interactions beyond direct power transmission, I noticed a lever not far away.

It pokes through to the front, where it can be engaged by the print carriage.

Manually sliding the print carriage around, I found the lever is pushed by the print carriage when it is 2cm away from the right side edge. I won’t know what this lever does until further disassembly, but based on its position, I expect it is a way for the print carriage (X-axis) motor to shift something in the gearbox turned by the paper feed (Y-axis) motor.

And now that I’m thinking about it… there’s a chance the print carriage “parking brake” pawl does double duty. When the print carriage is in its rightmost parked position, the pawl can fully extend to keep the carriage in its parked position. When the carriage is slightly away from its parked position, the pawl hits the back of the carriage and could not fully extend. When the carriage is in the paper printing area, that pawl could fully extend again. When I take the gearbox apart, I’ll have to keep my eyes open to see if it does anything clever with a partially extended pawl.

But that’s not until later when I take apart that gearbox. More accessible right now is the print head ink maintenance assembly, which is also actuated by the print carriage.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Before I remove the print carriage motor assembly from my retired Canon Pixma MX340 multi-function inkjet, I thought it’d be a good idea to better understand its motion and how it interacts with the rest of the machine. I found a little “parking brake” for the print carriage, and that was a good start to help me dig deeper.

The print carriage moves two ink cartridges together. One for cyan/magenta/yellow color inks marked “C” and another for black ink marked “B”. Each cartridge has an integrated print head that is replaced whenever the cartridge is replaced. The carriage is attached to a loop of toothed belt, turned by a DC motor. Like the paper feed motor, there’s an optical encoder to provide feedback for closed-loop motor control. Except here it is a linear strip instead of a round disc, read by a sensor buried somewhere inside the carriage.

Here are some close-up pictures of the encoder strip and motor belt drive, showing details at either end.

On the left (as viewed from the front of the printer here) side, the encoder strip is held in tension by a small spring. The left side toothed belt pulley is directly mounted on the motor output shaft, a direct-drive system with no intervening gears.

On the right side, the encoder strip is held against spring tension with a small stamped sheet metal hook. The right side toothed belt pulley is held in tension with its own spring on the back side of the assembly.

The belt pulley tension spring is visible towards the lower left corner of this picture. During normal operation, I could see some horizontal motion (roughly 1-3 mm) in this spring assembly whenever the print carriage started moving, and it likely continues moving in less-visible ways afterwards as the print carriage changes direction or speed. In contrast, the encoder strip tension spring never moves, as expected for something serving as reference.

On either end of the encoder strip, a big circle is present beyond the line pattern. I initially thought this served as some kind of “end of the line” marker, an optical replacement for a physical homing switch. (Precedent: its scanner module uses an optical marker.) But I no longer think so due to two observations. The first is the 34cm width of the line pattern, wider than the print carriage’s maximum range of motion of 32.5cm which means the sensor inside the print carriage never has to move beyond the line pattern and would never see the big circles.

Without physical homing switch or special encoder strip markers, how would the system calibrate carriage position upon startup? Watching its startup sequence again, it appears the control board runs the carriage slowly in one direction until it bumps up against the end. Encoder feedback determines when it could move no further, at which point the process is repeated in the other direction. Proof of actual physical contact is visible as smears of grease left by the carriage on either end of its track.

After checking out the far left and far right limits of this mechanism, I started looking at what else it might do (beyond printing) in between those ends.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’ve wrapped up my second pass exploring the paper feed motor of my retired Canon Pixma MX340 multi-function inkjet. Capturing data from its quadrature encoder reporting rotation motion had to be done while the system was still in a running state, and I think it’s the last useful data I could extract at my current skill level. Thus this marks the transition point between phase 2 and 3 of my original teardown plan. I will switch focus from electronic probing of phase 2 to mechanical disassembly like in phase 1. The main difference is while I still prefer to keep things in a running state for as long as I can, maintaining functionality is now less critical.

The most obvious target for starting phase 3 is the print carriage assembly, or “the X-axis” in my mind. Sitting on top of all remaining mechanical bits, it carries the two ink cartridges (“C” for colors cyan/magenta/yellow and “B” for black) with their integrated print heads across the printing area as well as a print head maintenance/parking area to the right. After seeing how the paper feed motor was linked to many other mechanisms in addition to feeding paper, I had expected to see similar clever multi-use of the X-axis motor and surprisingly didn’t find additional gears.

Speaking of that paper feed motor, I’ve taken my first step to unraveling its mysteries: it actuates a “parking brake” for the print carriage: A small white plastic pawl that extends (left picture) against the print carriage edge to keep it in its parked position, and retracts (right picture) to allow print carriage movement.

This pawl is connected to a shaft in the paper feed motor gearbox, but not rigidly. So when the pawl reaches one endpoint or another, the underlying shaft continues turning. This will loosen as the system wears, but (1) this geometry can tolerate a lot of wear and still do its job and (2) it has outlasted the service life of this machine so it was evidently good enough.

This pawl was retracted by the first 1800 encoder count rotation when the system powered up, and it was extended with the final 1800 encoder count rotation when the system goes into standby. There are many additional 1800 moves as the printer runs, so I doubt this parking pawl was the sole purpose of 1800 rotations. Certainly a useful related functionality, though.

Once carriage moves beyond its parked position, this pawl will no longer limit carriage movement. It will still move along with its loosely-attached shaft. If it should try to extend, though, it will hit either the flat back of the carriage or empty air depending on position within its full range of motion.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

I’ve had my head in the world of quadrature encoder counts for so long I almost forgot to get data on how they corresponded to the real world. Now with “8640 encoder count per revolution” jotted down, I think it’s a good time to wrap up this chapter of exploration. I started with only the knowledge that this Canon Pixma MX340 multi-function inkjet would turn its paper feed motor even when not actually feeding paper. What is it doing? And while I have to wait for further disassembly for all the answers, I now know more about the control system than I did before.

Given presence of the quadrature encoder, this was a closed-loop control algorithm that adjusted power sent to its DC motor based on position reported by the encoder. Plotting encoder position vs. time reinforced my guess this is primarily a position-based system (“turn 1800 counts”) and less of a velocity-based system (“turn at 1800 counts per second”).

Though there is a velocity control aspect to the system. Plotting motor velocity vs. time added more information: unlike a hobby servo motor, this system doesn’t try to hit the target position at its maximum speed. Some motions are slower than others, but it’s not yet clear to me why some motions are faster than others.

Even though the system appears to be a position-based system with a high resolution encoder wheel, there is a small range of error tolerance. I saw frequent moves of 1800 encoder counts, but sometimes I saw only 1799 or 1798 that the system must have deemed close enough. It aligns with observed deceleration behavior where it seemed to deliberately err on the low side. Consistent with a desire to avoid the overshoot correction headaches of dealing with gear backlash.

Along with this understanding of system behavior, I also have a set of decoded quadrature reports in the companion GitHub repository. This chapter of exploration was interesting on its own, and it would be even better if the captured data becomes useful future reference, but that is yet to be determined.

This marks of my teardown phase 2, onward to phase 3.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Captured CSV and Excel worksheets are included in the companion GitHub repository.

I’ve written down motions I decoded from a Canon Pixma MX340 multi-function inkjet as it went through various states, hoping that information will help me understand its mechanical internals when I take the print engine apart. However, that information was in terms of quadrature encoder counts. I also need to know what they are in terms of physical rotation.

Earlier, I took a close-up picture of the encoder wheel and its many very fine lines. Far too fine and far too many for me to contemplate counting them by eye.

When I had the quadrature encoders connected to my oscilloscope, I determined the sensor runs on 3.3V DC and it is only energized when the print engine is active. Trying to manually push some gears around would risk getting my fingers caught if it started running. But I can’t get any data during idle periods because the sensor receives no power when idle.

Solution: unplug the encoder from the system mainboard, and supply my own 3.3V DC to the sensor. An Arduino Nano has a convenient pin for supplying 3.3V DC.

I turned the gear train manually with my finger to turn the encoder wheel one full rotation, and saw the Arduino declare it had seen 8646 steps. This seemed like a very unlikely number, so I tried again and got 8652. A few experiments turning the gears back and forth determined my finger is far less precise than the encoder. Every time I move the gear and try to move it back to the exact same place, I would end up off by a margin of plus or minus 10 counts.

Given this error margin, I decided I’ll have to take a guess as to encoder wheel resolution. Since this is a rotation encoder, I decided it likely worked in terms of degrees. (Versus, say, radians.) Looking at the range of values I got, 8640 came up as a good candidate as it factors into 360 times 24. 24 encoder counts per degree seems like a useful number, easily dividing into halves, thirds, quarters, etc. as needed.

I can take this number and convert my earlier motion decoder output into degrees. For example, I saw many quick movements of 1800 encoder counts. At 24 encoder counts per degree, that means 1800/24 = 75 degrees. I’m not 100% confident of 8640 counts per revolution on this encoder, but if I’m wrong, 8640 should be close enough for my immediate needs. Good enough to wrap up this chapter of exploration.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Captured CSV and Excel worksheets are included in the companion GitHub repository.

I’ve created a small Arduino sketch that rapidly polls the quadrature rotation encoder of a Canon Pixma MX340 multi-function inkjet and parse that long stream of data into a concise list of movements. I hoped it would help me break down what the print engine is doing. At the moment I won’t be able to translate this data into actual printing functionality, that would come after I correlate these motions to what I’ll discover upon further mechanical teardown.

timestamp,count,min_us_enc
16,1799,28
3785088,2701,36
4262908,-1800,-29
4407660,-1799,-28
7253384,28019,36
11663472,2699,36
11917992,-2699,-38
12176620,-15000,-68
13994420,1800,28
16146804,-1799,-28
16290108,1799,28
16441336,-1799,-28

My tool recognized 12 movements in the system power-up sequence.

• 7 of them are movements of 1800 encoder positions, at a fast speed of ~28 us/enc. 3 in the positive direction, 4 in the negative direction. (In this system, negative is the direction of paper feed during actual printing.) Some of them are closely paired: negative immediately following positive, but some are interspersed with other motions.
• 3 of them are movements of 2700 encoder positions, at a slower speed of ~36 us/enc. 2 in the positive and 1 in the negative direction. The second positive 2700 move is immediately followed by the -2700 move.
• 1 long movement of 28020, at a speed of ~36 us/enc similar to the 2700 movements.
• 1 long movement of -15000 at a slower speed of ~68 us/sec.

Looking at the system stand-by sequence, I see much of the same components in the list of 15 movements. (It’s not pasted here but available on the companion GitHub repository.)

• 9 x 1800 @ 28, 5 positive and 4 negative.
• 2 x 2700 @ 36, 1 positive and 1 negative.
• 1 x 28020 @ 36
• 1 x -15000 @ 68

But there were two unique to the stand-by sequence:

• 1 x 251200 @ 28, a very long roll.
• 1 x -25120 @ 28 that immediately followed.

I had expected the standby sequence to have unique movements related to putting away the ink cartridges, so these two are good candidates. Other than that, I was surprised to see it repeated much of the same movements as the power-up sequence. I had expected to see something unique during power-up related to getting the ink cartridges ready, but apparently not. Perhaps “get ink cartridge ready” doesn’t occur until the actual printing sequence, which is much more complicated.

• -49720 @ 24
• -1310 @ 160
• Rocking back and forth with 4 x 1800 @ 28.
• -22421 @ 19. Both the gear and paper sensors changed state during this movement. Did the 4×1800 engage a mechanical clutch or something? I have to look for that.
• 3000 @ 20
• -12300 @ 20. (The gear sensor changed state again somewhere in here.)
• 6200 @ 36
• -1200 @ 28

Then a long list of 82 x -961 @ 38 movements, each corresponding to the print head putting down a line of ink. Around the 72th iteration, the paper sensor changed state as the bottom edge of the sheet fed beyond the paper tray where the sensor lived. After the 82nd single-line movement, there was another sequence to eject the printed sheet.

• -3475 @ 20
• -12905 @ 14
• -3282 @ 38

Very interesting there were three separate movements in the paper feed direction, at three different speeds.

• 2700 @ 36, our old friend returns.
• -1600 @ 29

That’s a lot of movements unique to printing a page. I’m not sure I could link them all to specific mechanical functionality, but at least I’ll have this data on hand as reference when taking this gearbox apart. Better to have it and not know what it means, than to not have it and wishing I did later when the gearbox is in pieces. But right now, I want to map these encoder counts to physical movement.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Captured CSV and Excel worksheets are included in the companion GitHub repository.

My current Arduino project is to translate a quadrature encoder’s positions over time into a series of movements, in the hope it would help me understand the inner workings of a Canon Pixma MX340 multi-function inkjet. Trying to keep the project simple, it was simpler to calculate “microseconds per encoder count” (shortened to us/enc below), which is the reciprocal of velocity “encoder count per unit of time”. I think it’ll still have all the information I need. I graphed output from my first draft sketch and it looked like a promising start.

The first problem I want to tackle is noise introduced by the encoder bouncing back and forth between two adjacent values. For example, 1799 then 1800 then back to 1799. This happens because the motion control system could not (or deliberately chose not to) hold the motor at a precise location, allowing it to move around a bit. Since these small bounces aren’t very frequent, they work out to very large us/enc values. Without any processing, the raw plot results in lots of noise in the orange line that doesn’t correspond to any actual movement on the blue line.

To keep my code simple, I’ve been resisting solutions that require me to implement a long history buffer, wary of bugs as I traverse the buffer. I’ve been able to get away with tracking a single history point so far, but in order to recognize bounces, I need to track a second history point to know if I’m just bouncing back and forth between the two history records. As expected, maintaining double the history entries approximately doubled my code complexity, but at least it’s still simpler than implementing a circular buffer or anything along those lines.

The results were worth it! A bit of debounce code eliminated all obvious noises, leaving me with a much cleaner output so I can get a better understanding of this system’s behavior.

---

This teardown ran far longer than I originally thought it would. Click here to rewind back to where this adventure started.

Captured CSV and Excel worksheets are included in the companion GitHub repository.