MPC6000 - light copies, independent toner message

[E Winter]

Hi there,

I'm having a MPC6000 out there with low image density plus an error message claiming that there is an "independent toner" installed for black. I already found a RTB and checked the results for the dev fill and initialisation.

The dev fill result (3815) was 7777 and after trying to "fake-fill" the units it switched to 4444. I barely remember having problems with the dev fill during installing the machine back then and that the "plan b" in the troubleshooting guide didn't helped me at all so I just worked around it (I think I got all dev out of the bottles with a little help from the output check). Dev setup check (3812) and process control check are good on this machine (1111 / 10101010) so I didn't had a bad feeling because of the unsuccesfully finished dev fill sp.

According to the RTB it seems that a bad result flag is able to produce the problems mentioned above and that this can only be solved by installing new developers and eventually new toner cartridges. The customer already tried another toner and got the same display message. RTB says that this toner may became unuseable if the machine messed the ID chip with bad informations.

Isn't there another way to work around this? It's kind of lame to dispose 4 dev and 2 toners just because of some software flags

Unfortunately I'm kind of a "noob" on this machines - I'm only having a few in the field and all are running in an extreme low volume enviroment.

[Shadow1]

There is an SP code to turn off the 3rd party toner detection, but I'm on my home computer, and don't have my notes handy.

There is also a set of codes for developer fill mode, but again I don't have my notes handy. Both codes are in SP5xxx somewhere (not very helpful, I know) I'll look them up tomorrow and post them if somebody else doesn't beat me to it.

Tech services also had me D/L the NVRam to an SD card, do and engine clear, U/L the NVRam and rerun the install procedure starting at Developer Init to fix this once.

In theory there have been some very big improvements to the MPC6000 over the 5560, but Process Control is NOT one of them. When it works it makes really nice images, but these machines consistently fail initial setup, go 1 color light, all colors light, arc drums, and fubar perfectly good toner bags. Just wait until you have to rebuild a PCU - also NOT an improvement. Most of this could be fixed by firmware. All of this could be fixed by dragging the engineers out of their cozy little cubicles and forcing them to work on their own products.

Sorry I'm in such a bad mood tonight, but I spent most of the day dealing with engineering stupidity and with a very dirty AF1224c thrown in on top of it... kinda like the exclamation point after an explative.

[stephend]

Insert the toner cartridges with problems.
Enter SP 3401 and set to 0 to force the machine to ignore the toner detection.
Reboot.
The message about "independent toner" should be gone.
Turn back on 3401. Set to 1

PS. We found machines that are ignoring this action. In this case is nothing else to do than redo the dev and change the toner cartridges.

What nobody mentioned in any bulletin or in User manual is the toner replacement procedure. On C6000 and 7500 the machine must be first turned off before you replace the toner....I know it's stupid but if the customers will follow this procedure...they will avoid this "independent toner supplier" msg.
Apparently the resurn signal from some cartridges trigger this msg....another firmware bug that won't be fixed pretty soon. Good luck

[E Winter]

There is an SP code to turn off the 3rd party toner detection, but I'm on my home computer, and don't have my notes handy.

I tried this one - it does cover the message but then there is no remaining toner display icon for the affected color.

Tech services also had me D/L the NVRam to an SD card, do and engine clear, U/L the NVRam and rerun the install procedure starting at Developer Init to fix this once.

LOL - I also tried this because I had another machines month ago with "toner end" message (after toner replacement). Worked fine back then but unfortunately I didn't help for the recent case.

I spent most of the day dealing with engineering stupidity and with a very dirty AF1224c thrown in on top of it...

Argh..... I know what you are making through

Insert the toner cartridges with problems.
Enter SP 3401 and set to 0 to force the machine to ignore the toner detection.
Reboot.
The message about "independent toner" should be gone.
Turn back on 3401. Set to 1

Worth a try - thanks!

On C6000 and 7500 the machine must be first turned off before you replace the toner....I know it's stupid but if the customers will follow this procedure...they will avoid this "independent toner supplier" msg.

Good to know - I'll forward this information to the customer.

[Shadow1]

The other code I was looking for is SP3817 - Developer Filling:admission - If any of the colors is set to 1 the machine will not add toner. Execute SP3817-005 to reset them all. One of the other techs in my district was about to go the developer change route and discovered this code just before he blew through almost $1k worth of developer and parts WAY before PM. Don't know how or why this code got set on a machine that was working, but we suspect a firmware bug. Actually, given the total unstability of these machines, I'd say there are quite a few firmware bugs.

[E Winter]

What a day..... I spent five hours on this machine and it was for nothing (again).

The task was just to recplace all devs properly to get rid of the independent toner message and light image.

I did it straight by the book, emptying and vaccing all dev units, put the new dev cartridges in place, unsealed them, closed the front cover, turned the machine on. At this point an RTB says I have to wait until the machine is ready (twice beep) before I start the dev fill in sp. Ok then....unfortunately the machine didn't went to that point because some seconds after I switched it on there was a message "please insert c/m/y/k toner" on the display - no way to get into the ready condition.

OK - what do do? Call Ricoh before somebody is going to blame you for tweaking arond again. We checked some SPs and the problem is that there is no valid dev fill in admission for any color. We tried some SP stuff and memory clear here and there but there was no way to get this "dev fill in" sp running.

Finally they recommended to change both NV Rams and fill in the dev's via output check->development motor - the only way to provide my very unhappy customer a "working" machine for now. So besides the NV Rams I'll need another set of dev's again for the next visit

I'm not very optimistic in this case and the customer.... well you can imagine.

[Wishbone]

See my new post on how to fix you dev. fill problems.

[Vulkor]

I've got two of these in the field. Both were pains in the ass to get DV installed in Initially. You've given me great concern cause I know none of the customers will have enough initiative to turn off the machine before installing toner.

[knobby]

So what happens when it runs out in the middle of a long run that the customer spent 30 minutes scanning in and setrting up ?

Dont think they are going to turn the machine off !

[Vulkor]

Yeah they won't. Some of ours are too lazy or just don't care and you bring up a good point Knobby.

[Shadow1]

Did the engineers somehow forget that this is supposed to be a light production machine??? Just who do they think is going to turn a machine off in the middle of a production run and completely restart a job just to change the toner - isn't that why the Katana's have 2 bottles, so the machine doesn't even have to stop and ask for toner. That has to be about the dumbest requirement (if it's even true) I've ever seen.

Fact is, 90% of the problems we have with the machine could be fixed with a firmware update just need to get the engineers to do it. I'm sure they're overworked and underpaid like the rest of us, but you can only piss off so many customers and techs before it really starts to hurt.

So, instead, they keep saying that WE'RE not doing the setup right.

If their setup procedure is so complicated and unforgiving that an intelligent, skilled, experienced technician can't get through it without constant random failures, that is a problem.

The "constant random failures" part of that last seems to take the blame (mostly) off the tech - If we're doing something wrong, I would expect to see failures in the same part of the setup. i.e. process control always fails, line position adjustment always fails, SC codes, always goes light, always has fireflies - we're not a bunch of chimpanzees with screwdrivers - to have that many different problems points to something wrong with the way the machine adjusts itself.

Case in point - I had a machine go almost blank in black this week with 360k on developer. PM is at 450. If the machine wasn't setup properly why did it go that far. Since it did run that long I'll assume it was setup right so why did process control not see there was almost no toner in the developer? Why did it still not see it after forcing ProCon? Why did it not report an SC code if there was some sort of problem, and as light as it was there was no way it could have done line position. If the developer was worn (this is the 10% carrier toner, on the lanier 6714 using the same 10% carrier I NEVER changed developer with excellent results) why wasn't it overtoned and dusting like you would expect if process control was actually compensating?

Simple answer, they have overengineered this turd, but it's our fault we can't make it work. In the words of Mr. Scott, "The more they overcheck the plumbing, the easier it is to stop up the drain."

[stephend]

I share the same feelings with you...and everyday I'm taking another happy pill when I'm doing a new C6000 install or I'm receiving a call.
Unfortunately this model is a total disappointment.
I laughed when I heard first time about this "fix"...but because the advice was given by the our tech support guy who is also a trainer with over 20 years experience in Ricoh...I start crying instead.
Are many "why's" about Ricoh machines....
Why are so service intensive....why are not tech friendly...why they didn't fix obvious design flaws on the next generation? The answer is simple....to save money and to make more money....
I had to replace motors on 20K machines (C6000), rebuild transfer units completely at 40K so I'm against this "piece of art". I won't trade 5 C6000 for a 3260 or a 5560.

[Herrmann]

What happens, if you give a "forced Toner Supply" ? do the image improve? If so, check the Toner supply clutches, i have found several of them being bad.

[E Winter]

Status report:

I had another visit on this machine together with a ricoh specialist. At the end of the day we still didn't got the dev fill in process running properly. This time we swapped both NVRams before changing the dev but after running the fill SP the machine gave us a bad fill check # for black (dev already inside) and didn't fill the dev unit. We tried another NV Ram reset - after that the fill status for all colors became bad - even after restoring the NV ram backup... So again I needed to fill the dev via output check

I think this fill check permission stuff is just unneccessary SHIT. As if we wouldn't recognize if there is any dev left in the bottles or beeing too stupid to empty the units properly. This whole stuff produces way more trouble as it's suppose to prevent. It's just SHIT that the machine isn't able to do a proper toner supply when the fill check didn't show 1111. I'd say "OK" if that would happen if the TD init check ended with errors but..... aargh...

The machine is now going back to ricoh and will be repaired there - the customer didn't agree to any more research activities