Pro-100. - Still Having Problems With Displayed Ink Levels

[stratman]

On the purge issue, post #106 Stratman:- if you change all of the cartridges when one is showing low (Warning) then you get just one single purge on all the eight cartridges together, instead of the customary eight purges x 8 times when changing them individually..

This is/was not in dispute. My comments were in regards to at what point you refill/reset such that you do not cause more frequent ink purges leading to a diaper filled earlier than necessary.

Refilling on a LOW warning instead of an EMPTY warning accelerates filling the diaper and demonstrates a seminal distrust of the ink level monitoring technology, one's refilling abilities, or both. It will also lead to earlier full diaper warning.

Again, if you are having ink level monitoring issues - which are not resolved by updating your firmware - then I do not begrudge you if you do refill at LOW until the issue is resolved either with someone finding out what happens with a DIM'ed chip or a new resetter. Of course, if the issue is nonexistent with a new retail cartridge, then why are people waiting around for answers on a DIM'ed chip? Go get a new retail cartridge and be done with it.

 

[The Hat]

A Canon printer does not run a purge cycle every time the user lifts the top cover, it will however run a purge anytime any one cartridge chip status has changed i.e. from low to full or ½ full to full again.

The print head does move to the centre of the carriageway but not before passing the red LED sensor which checks every cartridges status first.

So if the user removes a cartridge to visually check the ink level themselves the printer doesn’t necessarily run a purge clean for that single action, it would however depend on the time duration that the print head was stopped in the central position..

 

[stratman]

A Canon printer does not run a purge cycle every time the user lifts the top cover, it will however run a purge anytime any one cartridge chip status has changed i.e. from low to full or ½ full to full again.

The print head does move to the centre of the carriageway but not before passing the red LED sensor which checks every cartridges status first.

So if the user removes a cartridge to visually check the ink level themselves the printer doesn’t necessarily run a purge clean for that single action, it would however depend on the time duration that the print head was stopped in the central position..

And the conversation begins again.

I have also wondered about the time requirement you allude to. However, some sort of maintenance has occurred with a quick lift of the lid (eg accidental when I only wanted to access the scanner but lifted the *bonnet* instead) but not every time from my recollection.

 

[jtoolman]

I will be working on the Pro-10 extensively in the next few weeks. I wonder if Roy could take up the testing as I had suggested. He has the DIM'ed chips. So only reset the one that signals LOW and only top off the others that have not signaled up as yet and don't reset those. Roy might actually end up enjoying that setup.

If this works. You "might" want to DIM the chips.

Now from another perspective.... what if Redsetter can fix the DIM'ed chip issue and we discover the above trick works. Should they actually "fix" ( assuming it can be fixed) the DIMed chip issue?

We need to find out if this trick works and real fast too. This trick IF IT WORKS can be of real use to many and I for one am warming up to it.

Aren't you eventually going to have to reset the other to full at some time anyway. If we use the two cart set way of replacing when any empty cart is reported?

Why would I not want to have at least a semi working ink monitoring with about 4-5 gradual drops as opposed to a sudden plunge to empty?

I suppose it would only apply to those who already DIMed their chips. But no me right?

Joe

 

[mikling]

OK, Hat. What is happening with the counter is unusual. This is not the norm, so old knowledge must be remade.
It is indeed possible that Canon has tried to disable the chip permanently when it is DIMed. We know that the printer is decrementing the counter somehow when it is being used or else we would not register the 80% full when it is probably 80% empty. What is likely happening digitally is that one bit somewhere in the counter value is frozen. If that bit is frozen, it will display a wrong value to the ink level query routine. What we do know is that if this bit is frozen, then it may retain a value that is positive that enables the Optical subroutine to work. Now if the optical subroutine works, then it behaves as an unchipped cartridge until the optical sensor kicks in and another counter might be used to the Low to Empty countdown.

With what I am proposing, no filling of cartridges will occur sooner because if the DIMed ones at 80% are stuck until the optical sensor, then a FULL use is allowed. I think this is where I am losing you folks. I will continue my testing to prove or disprove that after LOW -EMPTY will come up. This is safely done by simply topping up a LOW cartridge and continue to use again without resetting. This would safely simulate the onward path to EMPTY. I am currently doing that now.

With the topping off of ink to all at the same time and not having to open the lid, the waste ink pad issue is the least of concern as likely something else will break before a waste issue comes up.

So if Empty does come up, then DIMed chips can be actually beneficial.I will test on 1.02 and I think Roy is on the newer firmware. We both can test to prove or better understand the mechanics of what is happening.

 

[mikling]

To Toolman.

Let's present a case where Gray is always the one most used. If my theory works, then no, you'll never have to reset the other 7 colors. The time to refill will be dictated by when Gray goes to empty. Now if gray goes to Empty and Photocyan goes Low in that time, then you WILL have to reset BOTH the Grey and Photocyan because the Photocyan is already on the path from LOW to EMPTY which is unstoppable. But if Gray is used in an extraordinary amount and the other counters are frozen then we'll never have to reset those.....UNTIL your printing pattern changes and say Magenta is now heavily used and that color becomes the determinant of when to refill and reset.... If one goes to empty, only that one and the others in LOW state needs to be reset. Otherwise, the others may not need to be reset.

Hat, we know that on a normal chip with a normal operating counter, you cannot stop the count to LOW But when the chips are DIMed, something different is happening and that is what we are uncovering.

Again I restate that these are all THEORIES and ADVASNCED concepts to be proven on testing. So let no one go off and state what we are shooting at is fact so far. When the testing is done, then it can become fact but that time has not arrived yet until further findings. If you're a newbie to Canons, your head will spin and disregard the discussion.

Wait some more until my Light Gray gets used up to Empty and then we'll know what the situation is.

 

[mikling]

On the Pro-10 with the lack of optical sensors, at this point, some more insight as to what Canon is doing is required before those chips are DIMed. Redsetter will find this out for us in January.

 

[Bithead]

Hi All,

This is not about ink monitoring but about the chip. I have been refilling and resetting using mikling's PRO-100 inks and the resetter. I'm on my third cycle of refills.

I was fooling around with the canon product My Image Garden which will download various print related subjects from the Canon web site. I downloaded some paper craft objects.

As part of the download process it displays a message declaring that this is for legitimate Canon ink cartridges only.

The application then refused to print because it could not find any legitimate Canon ink cartridges.

I did not DIM any of my cartridges, I've only used the resetter.

My ink monitoring seems to be ok although I started watching it more closely after this thread was started.
When the grey cartridges got down to about 50% the ink monitor showed 80% and when the grey got to 25-30 % the ink monitor showed 50%.

I think there is a lot more going on with the chip than just counting ink shots.

Just adding more confusion to the mix.

 

[stratman]

My ink monitoring seems to be ok although I started watching it more closely after this thread was started. When the grey cartridges got down to about 50% the ink monitor showed 80% and when the grey got to 25-30 % the ink monitor showed 50%.

Could be your ink level monitoring is functioning as expected.

Remember, there is ink stored not only in the reservoir side but also in the sponge. If you only consider what ink is in the reservoir side and not the sponge side, then it might seem confusing about the relevancy of the ink level monitoring.

I take it you are using all OEM Canon cartridges? If so, and none have been DIM'ed, then your experience is may truly be a game changer for refillers and portends worse problems in the future unless it is the resetter that is the crux of the issue -- which is what I have trending towards the top of my list given all other variable stable from previous Canon printers. The improperly functioning ink level monitoring and now your issue of unrecognized - yet still functioning enough for the printer to still be used -is a strong indicator of resetter problem not coded/machined properly.

However, the fly in the ointment is that Canon themselves have acknowledged a previous ink level monitoring issue and created a firmware upgrade to fix the problem. This may represent unintended consequences from Canon developing new measures in the chip or could be crappy coding (odds on favorite if going the route of 'Canon's out to get us cabal',IMO - it was simple human error).

No one yet knows if the issue is the resetter, the chip (coding and/or manufacture), firmware, ???? or a combination of issues.

My advice to you would be to uninstall your printer and its software, cold boot and then reinstall the printer and applications. You didn't say what Operating System you have, but of course make sure you use appropriate versions of the software and firmware for the OS and printer. You probably already know this but add ed it for completeness.

 

[Bithead]

Could be your ink level monitoring is functioning as expected.

Remember, there is ink stored not only in the reservoir side but also in the sponge. If you only consider what ink is in the reservoir side and not the sponge side, then it might seem confusing about the relevancy of the ink level monitoring.

I take it you are using all OEM Canon cartridges? If so, and none have been DIM'ed, then your experience is may truly be a game changer for refillers and portends worse problems in the future unless it is the resetter that is the crux of the issue -- which is what I have trending towards the top of my list given all other variable stable from previous Canon printers. The improperly functioning ink level monitoring and now your issue of unrecognized - yet still functioning enough for the printer to still be used -is a strong indicator of resetter problem not coded/machined properly.

However, the fly in the ointment is that Canon themselves have acknowledged a previous ink level monitoring issue and created a firmware upgrade to fix the problem. This may represent unintended consequences from Canon developing new measures in the chip or could be crappy coding (odds on favorite if going the route of 'Canon's out to get us cabal',IMO - it was simple human error).

No one yet knows if the issue is the resetter, the chip (coding and/or manufacture), firmware, ???? or a combination of issues.

My advice to you would be to uninstall your printer and its software, cold boot and then reinstall the printer and applications. You didn't say what Operating System you have, but of course make sure you use appropriate versions of the software and firmware for the OS and printer. You probably already know this but add ed it for completeness.

I am using the OEM cartridges that came with the printer. The canceled print occurred in both Win 8.1 64 bit and Win 7 64 bit.

I originally tried it in 8.1 and thought it could be the OS, booted Win 7 and got the same result.

I am running firmware version 1.1