Why do printers break? Join the PrintCat 🐾 investigation

[james]

Update: This activity has now ended. You can still see the results here and learn more about our work with repair data here. Thank you to everybody who took part!

Printers can be frustrating

Unreliable, easy to break and hard to repair, printers are so often examples of devices that are just not designed to last. In fact, the average lifespan of printers today is as little as 4 years before becoming e-waste.

Change language | Cambia lingua | Changer la langue | Sprache ändern | andere taal | تغيير اللغة

Let’s change that

To celebrate Earth Day 2021, we’re launching PrintCat , a people-powered investigation into why printers break so often. We want to understand why printers fail so that we can tell policymakers how future models can be made to last longer and be easier to repair; repairable devices can reduce e-waste and lessen the strain on our planet’s resources.

With PrintCat, you can join the investigation.

Together with our partners in the Open Repair Alliance, we’ve collected information on over 800 broken printers and we need your help to categorise them.
Go to PrintCat

How does PrintCat work?

1. Go to PrintCat and choose your preferred language from the menu at the bottom right.

2. You will see some information about a broken printer that was brought to a real-life repair event (remember those?). Click the translate button to read it in your preferred language.
   

   

3. Select the type of problem that best describes the printer described from the list below the description and confirm your choice. If you’re not sure, just select ‘I don’t know’ at the bottom.
   

   

That’s it!

Once you’ve selected an option, you’ll see another printer. The more printer faults you can categorise, the more we learn! PrintCat shows each printer to three people to help confirm the right category.

Why printers, and why now

Consumer complaints suggest that many inkjet printers are thrown away after a lifetime of two to three years, with some being in use for as little as six months before they become e-waste.
– Coolproducts, 2019

Until now, there’s not been any regulation on printers’ repairability. In 2011, printer manufacturers signed a “voluntary agreement” with the EU, aiming to “reduce the environmental footprint” of printers, and exempting them from formal regulation.

Manufacturers are currently discussing a new version of the agreement, and the draft version we’ve seen is extremely weak on repair

If approved, this new voluntary agreement would allow manufacturers to refuse to make spare parts available for printers priced below €350.

What we hope to achieve

Most printers brought to community repair events fit in this category, so we thought it would be worth exploring why they fail. The European Commission could reject the voluntary agreement proposed by the industry, and decide to develop regulations on printers. We hope our findings will help make the case for more ambitious measures tackling repairability of printers.

And we also hope many people will enjoy contributing to PrintCat and learning more about why printers fail. PrintCat is the first in a series of three microtasks we’re running as part of our participation in the ACTION accelerator, engaging citizen scientists with open data. Over the next few months, there will be more opportunities to analyse data collected at repair events - so watch this space!

In the meantime…
Go to PrintCat

Questions? Comments? Feedback?

Great! Feel free to post below and let’s chat.

---

We are hugely grateful to to The ACTION (Participatory science toolkit against pollution) project for funding this work and for their support.

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 824603. This post reflects the author’s views. The European Commission is not liable for any use that may be made of the information contained therein.

[james]

To kick things off, I thought I’d share my PrintCat experience so far.

I’ve worked through about a dozen printers, but am actually finding it a little tricky. Even when there’s a fairly good description of the problem, I often can’t identify the issue from the list.

It’s true that I haven’t been in regular contact with printers for about a decade, so I’m wondering whether I just don’t understand (or have forgotten) how they work. But is anyone else finding it difficult?

For example, would ‘paper jam’ be categorised as ‘paper feed’ or ‘paper output’?

[Monique]

At first I thought that paper feed and paper output were both “paper jam” but having digested so much printer data I decided that there were enough records that specifically mentioned “feed” and “pickup” to warrant the two options. If it doesn’t mention feed/pick-up/load I pick “paper output”, i.e. paper is getting jammed somewhere internally.

I saw a record that mentioned the paper was not being picked up and there was a clicking sound. For that I picked “Internal damage”. You will see that if noise is mentioned you might get “Internal damage” as a suggestion.

[neil]

I wondered the same, great question - that’s something I love about these quests, it really gets you thinking about the different bits of devices…

I guess paper feeders/loaders are probably more noticeable on the bigger printers (laser printers, the bigger inkjets). The bits where the paper sits and gets pulled in. If the paper doesn’t load at all it’s probably one problem, if it disappears inside or gets stuck on the way out it’s probably another.

^ image from here

I’m also learning what a printhead is and does (e.g. here)

[Monique]

Thinking about my own paper jams there are two distinct types, one where I can clear it from the paper tray - say it goes in a bit skewed and bunches up - and one where I have to open the printer up and extract the paper from the rollers.

[james]

Thanks both! Super helpful, that all makes a lot of sense.

On a separate note, I’m wondering whether the @Data Delvers (who have helped out in previous Open Data Dives) would be interested in taking a look at PrintCat. This latest data dive feels like an evolution of some of the work we did together.

[Graham_Rolle]

Hi James

I did have a look at a few, and I’ll need to go back and look deeper, as I didn’t find any that I’d call ‘well documented’ as a fault.

Printers for home use are generally built to a price, and predominantly use cleaver software to improve output, over a better (read more accurately built) device. One of the big issues that have caused issues is printer control software that made use of ‘flash’ HP used this for some of there older printers, so if you had a old printer on Win 10, that worked, with the advent of 'flash.exe’s removal (win 10 update KB4577586, also win 7, 8, 8.1 etc.) you could not control the functions and setup of the printer, although the ‘Driver’ bit still worked, for whatever the last print setting was…

Really annoying.

The other big issue is manufacturers deliberately building in obsolescence; sell a cheap printer, with expensive ink, make the money on the ink whilst they can; build in items of short durability so they will fail/ware out. Design nearly the same printer with different ink carts (so that cheaper clones will have to re invent / re tool) and start over. (a software count is also used, and reduced by using non original cartridges, when this unit has exceeded its count, the hardware will fail to function due to a deliberate software failure.)

Almost exactly why the 350 Euro limit they are self imposing

[Graham_Rolle]

Paper Feed issues are often physical issues damp paper, creased edges, feed roller surface dirty of aged and gone hard, or just alignment.

Paper jam’s two areas, the output try miss aligned, feed over rollers same as above, the other area is the double sided ‘unit’ if fitted , it has another bunch of rollers and guides, and sufferes in the same way, more often the rubber(ish) drive rollers become hard or indented due to a lack of use in comparison with the straight through / rollover feed used for single sided use.

[neil]

I came across this problem statement:

Error 5100, cartridge stuck?

It sounds like it could be the bit that moves the cartridges (the carriage maybe?). I wonder should this be recorded as ‘Ink cartridge’ fault type, or something else (perhaps ‘Other’)?

[Monique]

According to the interwebs it is a very common error in Canon printers and a cartridge that has been improperly inserted can cause it. Among many other things.

Canon Printer Error 5100: FIX In 5 Minutes (Easy Guide)

[Mend_It_Australia]

PrintCat has only one option to select but what if there are multiple issues to be considered as to why the printer is not working?

[Monique]

PrintCat asks for the “main fault” if it can be identified.

[Mend_It_Australia]

Okay, so this is not for hypothetical examples, this is real life example of printers that have identifiable problems?

[james]

PrintCat uses real data on around 800 printers that were brought to repair events, yep. Every description you read was entered by a volunteer at or after an event
The data comes from the Open Repair Alliance

[Monique]

@Mend_It_Australia

Okay, so this is not for hypothetical examples, this is real life example of printers that have identifiable problems?

We are hoping that the type of fault can be identified from each of these real-world cases. It’s not always possible to get a precise answer - or any answer sometimes - but the results of these quests give us a pretty good idea of the top issues that affect the devices that turn up at community repair events.

[Hans_van_der_Made]

Hi Monique,
I am trying to help with the selection of probable causes, but I’m struggling, really.

I’d say a common cause is when a piece of paper, or any type of debris really, causes sensors to malfunction. Another common problem is when rubber parts wear out, causing paper transport problems. Sometimes, paper sheets tear, and shreds of paper cause mechanical problems. Cleaning is often the first thing to do.

Electronics fail as well: fuses blow, power supplies that smell of burned plastic, etc. I’ve seen large ink stains, on failed printed circuit boards, that were an immediate giveaway. I can’t seem to point anyone in the right direction with the available choices, though.

Going through the PrintCat-descriptions and available solutions, I am asked to select causes, but a simple “look for debris along the paper trajectory”, or “check if transport mechanism moves freely” isn’t there. Instead, I am asked to decide between paper input, and output, which does not seem useful, at least from my limited point of view.

A simple flow chart could be:

• an sign of life? does it power on? (fuse, power supply, cord)
• if electronics seem to work: does it try to move the paper, or print head, or does it report an error before even trying? (jam, dirty/broken sensor)
• is paper transported as it should? (jams, pickup rollers, gears, debris)
• does the printing work at least partially? (ink dry, cartridge defective, etc.)
• if a self-test page can be printed from the printer itself, but not from an attached computer, the failure might be software or configuration related.

Translating to causes, I’d suggest categories like these:

• electronic failure, power failure
• paper transport problem (rollers, belts, gears, dirt, sensors, timing problem)
• printing problem (cartridge, ink, dirt, belt, damaged cables)
• pollution (cleaning first always helps)
• ink or toner problem
• software or driver problem

I’m not a professional printer technician, and most professional printers have a proper service manual containing a better flow chart than I’m suggesting here. I still hope it’s of use, in any way.

[Monique]

Hello Hans, welcome to the community and thank you for your suggestions!

@Hans_van_der_Made

A simple flow chart could be:

• an sign of life? does it power on? (fuse, power supply, cord)
• if electronics seem to work: does it try to move the paper, or print head, or does it report an error before even trying? (jam, dirty/broken sensor)
• is paper transported as it should? (jams, pickup rollers, gears, debris)
• does the printing work at least partially? (ink dry, cartridge defective, etc.)
• if a self-test page can be printed from the printer itself, but not from an attached computer, the failure might be software or configuration related.

This flow chart would be very useful at the point where the data is collected. The data that we show you in PrintCat has been collected at events all over the world using a variety of collection methods used by different people and some of the data is very old. We can suggest what we’d like them to collect but it is their choice.

The people who write the “problem” text are usually the volunteer repairers themselves and they are very busy at the time and don’t always write much down - sometimes nothing at all (we exclude empty “problems”). Which is why we do these quests, to see if we can figure out what sort of fault was presented.

The labels on the fault type buttons have been compiled from an original list used by professional repairers combined with a few that we added when we looked at the data we have. We also ran some “word frequency” queries to find out how often certain terms show up (over 7 different languages).

For instance, “paper input” and “paper output” were originally going to be just “paper jam” but certain words indicating a difference came to light and so we thought it would be useful to us if we can find out where the jams tend to occur - when the paper is in the tray just going in or when the paper is being transported internally. Each of these can indicate a different component that may have failed.

A large part of these quests is all about the components - their design, quality, reparability and availability of spares. If we can get an idea of which particular bits of a printer are causing the problem, we can then assess where the issue lies e.g. poor design, sourcing, manufacturing etc.

Coming up with the list of “fault types” is the hardest part of designing these quests and it takes our whole team many iterations to decide!

Each time we do a quest we learn more and more from participants like yourself, so many many thanks for your feedback!

[ugo]

Someone emailed us with a good question about how to choose a fault type in case of a potentially ambiguous record:

For example a printer printing half a page.
There could be a few reasons why this is happening.
Are there tabs for multiple issues?
And the printer would need to be seen to troubleshoot which issue, right?

These are all good points:

• It’s true that there could be multiple reasons for a printer printing half a page. But you can only pick one through the system, the “main one”. In case different people pick different options, the PrintCat admins will review and choose the most likely option.

• As @Monique wrote above, we are analysing the data that volunteers uploaded after attempting a repair - either successfully or not. The data is not always sufficiently detailed, and therefore we might not know what the fault is based on what was submitted. We have to accept that, and choose “Unknown” in case we can’t infer it from the information provided.

• This in itself is useful, as it confirms the need to improve the way we document the repairs attempted at community events - especially if we want to be able to use the data to make the case for more repairable products with policymakers.

Thanks everyone for your thoughtful comments - we’ll make use of them to improve our work, so keep them coming!

[Dave]

Hmmm.

Where’s the “PEBKAC” button

Seriously: can’t we have some way of reporting bad data?
I’ve seen a few others that were almost as meaningless and, since we’re spending the time and effort to classify the faults, we might as well clean the data at the same time.

EDIT:
just seen another one:

which suggests that maybe there should be more data input validation?
I can’t think of a case where a real fault description would fit into 3 characters.

[Monique]

@Dave

Seriously: can’t we have some way of reporting bad data?
I’ve seen a few others that were almost as meaningless and, since we’re spending the time and effort to classify the faults, we might as well clean the data at the same time.

There really is no point in reporting bad data as we already know about it, sorry!

Best thing to do with bad data in a quest is give it a fault type of “Unknown”, I can use that as part of the data quality assessment queries.

I’ve got dashboards full of tables highlighting the problems (such as a bunch that have nothing but weights in them which btw are all from one group in 2016). Data cleaning is on the roadmap for the Fixometer but, other tasks always overtake the housework on the list of priorities and we’re not exactly brimming with resources to embark upon a big clean up. Bits get done over time - we recently cleaned up most of the character encoding issues in the Fixometer, still some lurking in this ORA data but it was a major achievement imo!

Btw, data doesn’t always come in via the Fixometer UI, we do ingest bulk spreadsheets often containing historic data and its a shame when the problem text is poor but even records with empty problem text has it’s uses. (Obviously I exclude all empties in these quests though).

I’m not sure what the Fixometer UI validation rules are (not my area) but if the paper record has no text and we insist on a minimum number of characters then the data entry person may well give up or just enter nonsense. The Fixo UI team are always looking at ways to improve data entry though.