Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Epson Expression series (XP-610, XP-620, XP-630, XP-820, XP-830, etc) #1

Open
blenheimears opened this issue Jun 25, 2016 · 74 comments

Comments

@blenheimears
Copy link

These are units that have both a printer and scanner in one. I don't think the cartridge level can be reset, but the waste ink counter should be able to be reset. These printers have Cyan, Yellow, Magenta, Black, and Photo Black cartridges. There are no light cyan or light magenta cartridges, except on the XP-860 and XP-950 (which also don't have the photo black cartridge). These test reports are from an Epson XP-630. I also have an XP-620 (which uses a different cartridge) but I don't have any cartridges for it yet. I can run a test on it once my cartridges arrive.

testreport-epson-xp-630.zip

@lion-simba
Copy link
Owner

Thanks for the report!

Could you please provide me with approximate level of inks, that were in the printer during these reports being generated?

Is it a new printer or an old one? I'm trying to estimate how much of it's waste ink tanker/counter should be filled for this time.

Couple of new reports for the same printer would be also helpful. Please make two reports consequently (without printing) and then third report after printing one page with black-only text.

@blenheimears
Copy link
Author

It's a brand new printer so the waste ink should be relatively low. Another utility says that one waste ink counter is about 6% full (which I thought was unusually high for such a new printer) and the other is less than 1%. I think one counter is referring to the main pad that absorbs ink during head cleaning and charging, and the other is the pad that runs the length of the printer to absorb the edges off borderless photo prints. Not sure which one is which. I have attached three new reports, the first two taken about a minute apart without printing, and the third after printing a page of black text. Also, the ink level is from the printer's LCD right after printing the text. I haven't printed a lot since the first two reports so the level would be only slightly higher for the first two reports.
inklevel
XP630-testreports3-5.zip

@blenheimears
Copy link
Author

If I can find a copy of the official Epson waste pad reset utility that works with this printer I can attach a Wireshark capture of the USB traffic.

@lion-simba
Copy link
Owner

Yep, USB traffic dump would be helpful too.

@lion-simba
Copy link
Owner

I think I have identified addresses of all ink counters and one waste ink counter. I was unable to differentiate between cyan and magenta because they have almost same ink level. I was also unable to found second waste ink counter. I have one candidate, but it's located not in sequential addresses, which is weird. Are you sure this printer have two waste ink counters?

In any case, we can start testing what I've found. I created a branch https://github.com/lion-simba/reink/tree/xp630 with added support for XP-630.

Let's try the following:
Dump EEPROM before resetting waste ink counter: ./reink -d 0x00-0xFF -r ... > waste1.dump
Reset waste ink counter: ./reink -s -r ...
Dump EEPROM after resetting waste ink counter: ./reink -d 0x00-0xFF -r ... > waste2.dump
Turn the printer off and on.
Dump EEPROM after swithing the printer off and on: ./reink -d 0x00-0xFF -r ... > waste3.dump
Check that the waste ink counter was reset.

Let's also do the same procedure for black ink:
Dump EEPROM before resetting black ink counter: ./reink -d 0x00-0xFF -r ... > ink1-1.dump
Reset black ink counter: ./reink -z1 -r ...
Dump EEPROM after resetting black ink counter: ./reink -d 0x00-0xFF -r ... > ink1-2.dump
Turn the printer off and on.
Dump EEPROM after swithing the printer off and on: ./reink -d 0x00-0xFF -r ... > ink1-3.dump
Check that the black ink counter was reset.

Then repeat for for other colors: -z2 (cyan), -z3 (magenta), -z4 (yellow), -z7 (photo black).

In any case, attach all the dumps you get.

@blenheimears
Copy link
Author

I managed to obtain a copy of the official reset utility for the XP-620 (not the 630). I will post reports of this printer before and after resetting the counters and also a Wireshark USB traffic dump.

@blenheimears
Copy link
Author

I do also want to verify that we have the correct addresses with Wireshark before writing to the printer's EEPROM.

@blenheimears
Copy link
Author

I tried to do a dump of the eeprom, and I get "Fail to read EEPROM data from address 0."
It appears this printer might use a different protocol than others.

Setting debug mode gives:
=== printer_model ===
=== printer_connect ===
Opening raw device... OK
Entering IEEE 1284.4 mode... OK
Perfoming IEEE 1284.4 Init transaction... OK
^^^ printer_connect ^^^
=== open_channel ===
Obtaining IEEE 1284.4 socket for "EPSON-CTRL" service... OK, socket=2.
Opening IEEE 1284.4 channel 2-2... OK
^^^ open_channel ^^^
Let's get printer info. Executing "di" command... === printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... OK, got 1 credits.
Writing data to printer... OK
Get the answer... OK
^^^ printer_transact ^^^
OK
Parsing result... === get_tag ===
Searching for "MDL:" substring... FOUND, pos=54.
Searching for ";" character... FOUND, pos_end=71.
Tag value:"XP-630 Series".
^^^ get_tag ^^^
OK
Printer "Epson Expression Premium XP-630".
=== close_channel ===
Closing IEEE 1284.4 channel 2-2... OK
^^^ close_channel ^^^
=== printer_disconnect ===
Perfoming IEEE 1284.4 Exit transaction... OK
Closing raw device... OK
^^^ printer_disconnect ^^^
^^^ printer_model ^^^
=== do_eeprom_dump ===
=== printer_connect ===
Opening raw device... OK
Entering IEEE 1284.4 mode... OK
Perfoming IEEE 1284.4 Init transaction... OK
^^^ printer_connect ^^^
=== open_channel ===
Obtaining IEEE 1284.4 socket for "EPSON-CTRL" service... OK, socket=2.
Opening IEEE 1284.4 channel 2-2... OK
^^^ open_channel ^^^
Let's get the EEPROM dump (0 - ff)...
=== read_eeprom_address ===
Reading eeprom address 0... === printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... OK, got 1 credits.
Writing data to printer... OK
Get the answer... OK
^^^ printer_transact ^^^
=== get_tag ===
Searching for "EE:" substring... NOT FOUND.
Can't get reply data.
Fail to read EEPROM data from address 0.

@blenheimears
Copy link
Author

I also created a test report for the XP-620. This created a very large log file (about 12MB uncompressed) and ran for a long time until I interrupted it. I don't know if this log file is very useful but since I have the official reset utility for the XP-620 I can do a wireshark dump of the USB traffic when reading the counters and resetting.
testreport.log.zip

@blenheimears
Copy link
Author

Here is a Wireshark capture of the USB traffic to/from the printer while reading and resetting both waste ink counters of the XP-620 using the official Epson utility. I think I did this capture correctly but it might not be correct. This was done with the Epson utility on Windows 10 64-bit in VirtualBox as guest, with Wireshark running on the host system (Ubuntu 16.04). Part of the reset procedure requires turning the printer off and back on (although I think this happens after the reset actually happens), which disconnected the printer from VirtualBox for a moment until I reconnected it manually.
xp-620-reset.pcapng.zip

@lion-simba
Copy link
Owner

Regarding failed EEPROM dump, it seems like my mistake. I have missed that this printer is using two-byte addresses. I just corrected this in xp630 branch. Please get the changes and try again.

Also, given that this is two-byte addresses printer, we might actually have seen only part of it's eeprom... Let's try to do a full dump: 0x0000-0xFFFF. Please replace 0x00-0xFF in all commands from my previous comment to 0x0000-0xFFFF.

Test report from XP-620 seems good, although it was not completed (just as you stated). It has checked only 0x2e89 of 0xFFFF possible model codes. And it seems that it was running with enabled debug (REINK_DEBUG). Enabled debug will drastically increase time needed for checking all the model codes. I suggest to re-run the report with disabled debug.

Thanks for the USB traffic log. I'll check it later.

@lion-simba
Copy link
Owner

I have analysed XP-620's USB traffic log. It revealed the following:

  • protocol is the same, so ReInk can support it.
  • model code is 0x57 0x05, so there is no more need in first long-running testreport.
  • there were two communication sessions with printer: one read from addresses 0x0010-0x0013 and 0x0006; the other wrote byte 0x00 to 0x0010-0x0013, 0x0014-0x0015, 0x0006 and 0x01ed, and byte 0x5e to 0x0034-0x0035.
  • it seems that after restarting printer, it has connected as USB Mass Storage Device, is it exporting some internal file storage over USB?

So, if the utility first enquire current values of ink counters prior to resetting them, it must be that the first waste ink counter is at 0x0010-0x0013 and the second is at 0x0006.

The question remains: what are all others address utility is writing to?

@blenheimears
Copy link
Author

The mass storage is probably from the printer's SD card slot, but there was not an SD card in the slot when I made that log. The computer might still see it as an empty drive though. Not sure what the other addresses are. I noticed after running the Epson utility that the printer took a long time to print the first time, and moved the print carriage back and forth several times, similar to what it does during a head cleaning. The LCD display on the printer read "Printing" and not "cleaning" though, but it still could have been a head cleaning. The other addresses might have something to do with this.

@lion-simba
Copy link
Owner

I've added waste ink counter reset for XP-620 in a new xp620 branch. Currently it writes zeroes to 0x0010-0x0013 and 0x0006. Probably it's enough.

Could you please test it? Let's also get the dumps before and after reset.
Dump EEPROM before resetting waste ink counter: ./reink -d 0x0000-0xFFFF -r ... > waste1.dump
Reset waste ink counter: ./reink -s -r ...
Dump EEPROM after resetting waste ink counter: ./reink -d 0x0000-0xFFFF -r ... > waste2.dump
Turn the printer off and on.
Dump EEPROM after swithing the printer off and on: ./reink -d 0x0000-0xFFFF -r ... > waste3.dump
Check that the waste ink counter was reset.

@blenheimears
Copy link
Author

Dumping the eeprom appears to work but the result is different from the official utility. It could just be that the official utility formats the data differently.
waste1.zip
I have attached dumps from both the official utility and ReInk. Resetting the counter doesn't work. This might have to do with the two-byte addresses. Enabling debug mode gives:

=== printer_model ===
=== printer_connect ===
Opening raw device... OK
Entering IEEE 1284.4 mode... OK
Perfoming IEEE 1284.4 Init transaction... OK
^^^ printer_connect ^^^
=== open_channel ===
Obtaining IEEE 1284.4 socket for "EPSON-CTRL" service... OK, socket=2.
Opening IEEE 1284.4 channel 2-2... OK
^^^ open_channel ^^^
Let's get printer info. Executing "di" command... === printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... OK, got 1 credits.
Writing data to printer... OK
Get the answer... OK
^^^ printer_transact ^^^
OK
Parsing result... === get_tag ===
Searching for "MDL:" substring... FOUND, pos=54.
Searching for ";" character... FOUND, pos_end=71.
Tag value:"XP-620 Series".
^^^ get_tag ^^^
OK
Printer "Epson Expression Premium XP-620".
=== close_channel ===
Closing IEEE 1284.4 channel 2-2... OK
^^^ close_channel ^^^
=== printer_disconnect ===
Perfoming IEEE 1284.4 Exit transaction... OK
Closing raw device... OK
^^^ printer_disconnect ^^^
^^^ printer_model ^^^
=== do_waste_reset ===
=== printer_connect ===
Opening raw device... OK
Entering IEEE 1284.4 mode... OK
Perfoming IEEE 1284.4 Init transaction... OK
^^^ printer_connect ^^^
=== open_channel ===
Obtaining IEEE 1284.4 socket for "EPSON-CTRL" service... OK, socket=2.
Opening IEEE 1284.4 channel 2-2... OK
^^^ open_channel ^^^
Resetting... === write_eeprom_address ===
Writing 0 to eeprom address 0x10... === printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... OK, got 1 credits.
Writing data to printer... OK
Get the answer... OK
^^^ printer_transact ^^^
=== get_tag ===
Searching for "OK" substring... NOT FOUND.
Can't get reply data.
Can't write to eeprom.

@blenheimears
Copy link
Author

Later I will attach a Wireshark capture of the official utility dumping the EEPROM.

@blenheimears
Copy link
Author

Here are three Wireshark dumps, one is the official utility reading the EEPROM, the other is the official utility reading and resetting the waste ink counters (again, just to verify that it does the same thing each time and that there isn't some kind of checksum byte that it's writing to), and the last one is a capture of what ReInk is doing during the failed reset. Just to be safe I would suggest doing the same thing that the official utility does during resetting, because if it's writing to those other bytes there must be a reason.
wiresharkdumps-xp620.zip

@blenheimears
Copy link
Author

Here is also a test report from the XP-620.
testreport-xp620.log.zip

@blenheimears
Copy link
Author

Here are the ink levels from the XP-620.
xp620-ink-levels

@blenheimears
Copy link
Author

Just realized that waste1.dump is an empty file. My bad. I will do a full dump of the eeprom tomorrow.

@perdixxx
Copy link

perdixxx commented Jan 4, 2017

Hi, I encountered the problem of a full ink-waste on my Epson XP-760 when I found this tool and your discussion. Did the reset of the ink-waste work in the end? Would this also work on the XP-760?

I did the testreport, which look in my case like:

testreport.txt

@GNUtoo
Copy link

GNUtoo commented Feb 25, 2019

Hi,

Here's a testreport for the Epson XP-700.

It has 4 cartridges:

  • one big black cartridge
  • one yellow
  • one Magenta
  • one Photo-black

For some reason, the yellow cartridge is not recognized. I hope that this doesn't affect the test results.

$ sudo ./reink -t -r /dev/usb/lp0
ReInk v0.6 test report.
sysname: Linux
release: 4.19.8-gnu-1-x86_64
varsion: #1 SMP PREEMPT Sat Dec 22 14:03:34 CET 2018
arch: x86_64

=== printer_connect ===
Opening raw device... OK
Entering IEEE 1284.4 mode... --- EnterD4Mode ---
Send:
*****@ejl 1284.4
@ejl
@ejl

0: 00 00 00 1b 01 40 45 4a 4c 20 31 32 38 34 2e 34
@ E J L 1 2 8 4 . 4
16: 0a 40 45 4a 4c 0a 40 45 4a 4c 0a
@ E J L @ E J L
SafeWrite:
*****@ejl 1284.4
@ejl
@ejl

0: 00 00 00 1b 01 40 45 4a 4c 20 31 32 38 34 2e 34
@ E J L 1 2 8 4 . 4
16: 0a 40 45 4a 4c 0a 40 45 4a 4c 0a
@ E J L @ E J L
length: 8
read: 0 8 total: 8
Recv:
0: 00 00 00 08 01 00 c5 00
OK
Perfoming IEEE 1284.4 Init transaction... --- Init ---
Send:
0: 00 00 00 08 01 00 00 10
SafeWrite:
0: 00 00 00 08 01 00 00 10
length: 9
read: 0 9 total: 9
Recv:
0: 00 00 00 09 01 00 80 00 10
OK
^^^ printer_connect ^^^
=== open_channel ===
Obtaining IEEE 1284.4 socket for "EPSON-CTRL" service... --- GetSocketID ---
Send:
****** EPSON-CTRL
0: 00 00 00 11 01 00 09 45 50 53 4f 4e 2d 43 54 52
E P S O N - C T R
16: 4c
L
SafeWrite:
****** EPSON-CTRL
0: 00 00 00 11 01 00 09 45 50 53 4f 4e 2d 43 54 52
E P S O N - C T R
16: 4c
L
length: 19
read: 0 19 total: 19
Recv:
*********EPSON-CTRL
0: 00 00 00 13 01 00 89 00 02 45 50 53 4f 4e 2d 43
E P S O N - C
16: 54 52 4c
T R L
OK, socket=2.
Opening IEEE 1284.4 channel 2-2... --- OpenChannel ---
Send:
0: 00 00 00 11 01 00 01 02 02 02 00 02 00 00 00 00
16: 00
SafeWrite:
0: 00 00 00 11 01 00 01 02 02 02 00 02 00 00 00 00
16: 00
length: 16
read: 0 16 total: 16
Recv:
0: 00 00 00 10 01 00 81 00 02 02 00 40 02 00 00 00
OK
^^^ open_channel ^^^
=== open_channel ===
Obtaining IEEE 1284.4 socket for "EPSON-DATA" service... --- GetSocketID ---
Send:
****** EPSON-DATA
0: 00 00 00 11 01 00 09 45 50 53 4f 4e 2d 44 41 54
E P S O N - D A T
16: 41
A
SafeWrite:
****** EPSON-DATA
0: 00 00 00 11 01 00 09 45 50 53 4f 4e 2d 44 41 54
E P S O N - D A T
16: 41
A
length: 19
read: 0 19 total: 19
Recv:
********@EPSON-DATA
0: 00 00 00 13 01 00 89 00 40 45 50 53 4f 4e 2d 44
@ E P S O N - D
16: 41 54 41
A T A
OK, socket=64.
Opening IEEE 1284.4 channel 64-64... --- OpenChannel ---
Send:
0: 00 00 00 11 01 00 01 40 40 02 00 02 00 00 00 00
16: 00
SafeWrite:
0: 00 00 00 11 01 00 01 40 40 02 00 02 00 00 00 00
16: 00
length: 16
read: 0 16 total: 16
Recv:
0: 00 00 00 10 01 00 81 04 40 40 02 00 02 00 00 00
No sufficient resources available now.
IEEE 1284.4: "OpenChannel" transaction failed.
=== printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... --- CreditRequest ---
Send:
0: 00 00 00 0d 01 00 04 02 02 00 80 ff ff
SafeWrite:
0: 00 00 00 0d 01 00 04 02 02 00 80 ff ff
length: 12
read: 0 12 total: 12
Recv:
0: 00 00 00 0c 01 00 84 00 02 02 00 01
OK, got 1 credits.
Writing data to printer... --- Send Data ---
SafeWrite:
0: 02 02 00 0b 00 00 64 69 01 00 01
OK
Get the answer... --- Credit ---
Send:
0: 00 00 00 0b 01 00 03 02 02 00 01
SafeWrite:
0: 00 00 00 0b 01 00 03 02 02 00 01
length: 10
read: 0 10 total: 10
Recv:
0: 00 00 00 0a 01 00 83 00 02 02
Recv:
0: 02 02 00 9d 00 01
toGet: 151
Recv:
@ejl ID
MFG:EPSON;
CMD:ESCPL2,BDC,D4,D4PX,ESCPR2;
MDL:XP-700 Series;
CLS:PRINTER;
DES:EPSON XP-700 Series;
CID:EpsonRGB;
FID:FXN,DPA,WFA,ETA,AFN,DAN;
RID:40;
0: 40 45 4a 4c 20 49 44 0d 0a 4d 46 47 3a 45 50 53
@ E J L I D M F G : E P S
16: 4f 4e 3b 43 4d 44 3a 45 53 43 50 4c 32 2c 42 44
O N ; C M D : E S C P L 2 , B D
32: 43 2c 44 34 2c 44 34 50 58 2c 45 53 43 50 52 32
C , D 4 , D 4 P X , E S C P R 2
48: 3b 4d 44 4c 3a 58 50 2d 37 30 30 20 53 65 72 69
; M D L : X P - 7 0 0 S e r i
64: 65 73 3b 43 4c 53 3a 50 52 49 4e 54 45 52 3b 44
e s ; C L S : P R I N T E R ; D
80: 45 53 3a 45 50 53 4f 4e 20 58 50 2d 37 30 30 20
E S : E P S O N X P - 7 0 0
96: 53 65 72 69 65 73 3b 43 49 44 3a 45 70 73 6f 6e
S e r i e s ; C I D : E p s o n
112: 52 47 42 3b 46 49 44 3a 46 58 4e 2c 44 50 41 2c
R G B ; F I D : F X N , D P A ,
128: 57 46 41 2c 45 54 41 2c 41 46 4e 2c 44 41 4e 3b
W F A , E T A , A F N , D A N ;
144: 52 49 44 3a 34 30 3b
R I D : 4 0 ;
OK
^^^ printer_transact ^^^
=== printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... --- CreditRequest ---
Send:
0: 00 00 00 0d 01 00 04 02 02 00 80 ff ff
SafeWrite:
0: 00 00 00 0d 01 00 04 02 02 00 80 ff ff
length: 12
read: 0 12 total: 12
Recv:
0: 00 00 00 0c 01 00 84 00 02 02 00 01
OK, got 1 credits.
Writing data to printer... --- Send Data ---
SafeWrite:
0: 02 02 00 0b 00 00 73 74 01 00 01
OK
Get the answer... --- Credit ---
Send:
0: 00 00 00 0b 01 00 03 02 02 00 01
SafeWrite:
0: 00 00 00 0b 01 00 03 02 02 00 01
length: 10
read: 0 10 total: 10
Recv:
0: 00 00 00 0a 01 00 83 00 02 02
Recv:
0: 02 02 00 9d 00 01
toGet: 151
Recv:
@bdc ST2


              *i**i**i**i**r*
                             *
                              N*
                                N*NN	NN****
                                                  *****unknown****

2012111942 1Tghj^Vggdd^{fdiiiiiidddddddddddddddddddddddd$7**
0: 40 42 44 43 20 53 54 32 0d 0a 8b 00 01 01 00 02
@ B D C S T 2
16: 01 05 06 02 01 01 0e 01 1f 0f 10 03 0b 00 69 03
i
32: 01 69 05 03 69 04 02 69 01 00 72 10 0c 04 0c 4e
i i i r N
48: 06 0c 4e 08 4e 4e 09 4e 4e 13 01 01 19 0c 00 00
N N N N N
64: 00 00 00 75 6e 6b 6e 6f 77 6e 1b 01 00 1f 0a 32
u n k n o w n 2
80: 30 31 32 31 31 31 39 34 32 20 31 00 00 00 54 81
0 1 2 1 1 1 9 4 2 1 T
96: 67 68 6a 5e 56 80 67 67 64 64 5e 7b 66 64 69 69
g h j ^ V g g d d ^ { f d i i
112: 69 69 69 69 64 64 64 64 64 64 64 64 64 64 64 64
i i i i d d d d d d d d d d d d
128: 64 64 64 64 64 64 64 64 64 64 64 64 24 02 05 05
d d d d d d d d d d d d $
144: 37 05 02 00 00 00 00
7
OK
^^^ printer_transact ^^^
Searching printer secret model code with brute force.
=== read_eeprom_address ===
Reading eeprom address 0... === printer_transact ===
Requesting some IEEE 1284.4 credits on channel 2-2... --- CreditRequest ---
Send:
0: 00 00 00 0d 01 00 04 02 02 00 80 ff ff
SafeWrite:
0: 00 00 00 0d 01 00 04 02 02 00 80 ff ff
length: 12
read: 0 12 total: 12
Recv:
0: 00 00 00 0c 01 00 84 00 02 02 00 01
OK, got 1 credits.
Writing data to printer... --- Send Data ---
SafeWrite:
0: 02 02 00 11 00 00 7c 7c 07 00 00 00 41 be a0 00
16: 00
OK
Get the answer... --- Credit ---
Send:
0: 00 00 00 0b 01 00 03 02 02 00 01
SafeWrite:
0: 00 00 00 0b 01 00 03 02 02 00 01
length: 10
read: 0 10 total: 10
Recv:
0: 00 00 00 0a 01 00 83 00 02 02
Recv:
0: 02 02 00 10 00 01
toGet: 10
Recv:
||:41:NA;

0: 7c 7c 3a 34 31 3a 4e 41 3b 0c
| | : 4 1 : N A ;
OK
^^^ printer_transact ^^^
=== get_tag ===
Searching for "EE:" substring... NOT FOUND.
Can't get reply data.

@dgerber
Copy link

dgerber commented May 7, 2019

XP-830 here. Model code is 0x28 0x09.

The printer was blocked with "end of life" message a first time; then received a waste ink counter reset with "WIC reset utility" (and ink cartridges were taken off); finally got blocked with EOL message for second time (which Epson says requires a service by them). Below are EEPROM dumps of non-null bytes. Cols 3,5 marks which bytes changed in-between. Found no non-null bytes in 0x282-0xffff.

It seems at least bytes 0x08, 0x10-0x15, 0x34 are involved (and 0x1ed? -- higher bytes were not dumped between the two EOL states).

The second but not least issue is that writing to EEPROM fails. With current reink the response is "||:42:NA;".
When mimicking traffic from @blenheimears's dumps above, the device does answer with "||:42:OK;", but subsequent reads still return the original value:

Sending...:
 >> 02 02 00 1A 01 00 7C 7C 10 00 28 09 42 BD 21 34 00 5E 42 6D 75 69 62 66 62 2F
 >>       °        °  |  |     °  (  Ť  B     !  4  °  ^  B  m  u  i  b  f  b  /
Received 16B:
<<  02 02 00 10 00 01 7C 7C 3A 34 32 3A 4F 4B 3B 0C
<<        °     °     |  |  :  4  2  :  O  K  ;
Sending...:
 >> 02 02 00 11 01 00 7C 7C 07 00 28 09 41 BE A0 34 00
 >>       °        °  |  |     °  (  Ť  A        4  °
Received 26B:
<<  02 02 00 1A 00 01 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 33 34 36 38 3B 0C
<<        °     °     @  B  D  C     P  S  Ř     E  E  :  0  0  3  4  6  8  ;

Maybe this would work as long as the printer is not in the (second/last) EOL state?

(It also fails when writing to "protection" byte 0x01ed. @sinopsysHK, have you had any success with PR11?)

EEPROM dumps:

addr,waste_dead1,wicreset,afterwic_wo_cartridges,use,waste_dead2
0000,,,,,
0001,,,,,
0002,02,,02,,02
0003,,,,,
0004,68,,68,,68
0005,08,,08,,08
0006,,,,,
0007,,,,,
0008,9D,X,D0,X,9D
0009,,,,,
000A,E4,,E4,X,3B
000B,6C,,6C,X,71
000C,14,,14,X,36
000D,69,,69,X,6D
000E,E6,X,E7,X,3F
000F,6C,,6C,X,71
0010,05,X,B5,X,13
0011,21,X,1D,X,21
0012,,X,D9,,D9
0013,,X,0B,,0B
0014,02,X,,X,5F
0015,25,X,,X,03
0016,58,,58,X,2C
0017,CC,,CC,X,12
0018,16,,16,X,C4
0019,06,,06,X,
001A,C0,,C0,X,E7
001B,9F,,9F,X,8C
001C,85,,85,X,5B
001D,04,,04,X,06
001E,70,,70,X,20
001F,23,,23,X,E1
0020,34,,34,X,FF
0021,02,,02,X,03
0022,AC,,AC,X,CC
0023,7A,,7A,X,F4
0024,06,,06,X,CB
0025,02,,02,X,03
0026,79,,79,X,58
0027,01,,01,X,5E
0028,21,,21,X,52
0029,02,,02,X,06
002A,,,,,
002B,,,,,
002C,,,,,
002D,,,,,
002E,A0,,A0,,A0
002F,73,,73,,73
0030,05,,05,X,03
0031,,,,,
0032,73,,73,X,5F
0033,17,,17,,17
0034,68,X,5E,X,68
0035,5E,,5E,,5E
0036,,X,01,X,
0037,,,,,
0038,,,,,
0039,,,,,
003A,,,,X,01
003B,,,,,
003C,,,,,
003D,,,,,
003E,,,,,
003F,,,,,
0040,36,,36,,36
0041,FF,,FF,,FF
0042,48,,48,X,2B
0043,F9,,F9,X,F1
0044,FF,,FF,,FF
0045,35,,35,X,BA
0046,F6,,F6,X,F8
0047,FF,,FF,,FF
0048,07,,07,X,7E
0049,F3,,F3,X,F5
004A,FF,,FF,,FF
004B,C8,,C8,X,36
004C,F2,,F2,X,F5
004D,FF,,FF,,FF
004E,4A,,4A,X,CB
004F,F2,,F2,X,F6
0050,FF,,FF,,FF
0051,FF,,FF,,FF
0052,FF,,FF,,FF
0053,,,,,
0054,F4,,F4,,F4
0055,02,,02,,02
0056,9C,X,B5,X,14
0057,67,,67,X,6D
0058,22,X,38,X,23
0059,0E,,0E,X,32
005A,3C,X,7E,X,97
005B,79,X,D0,X,5A
005C,DF,X,E0,X,2C
005D,07,,07,X,08
005E,,,,,
005F,,,,,
0060,36,,36,X,FC
0061,CD,,CD,X,D3
0062,,,,,
0063,,,,,
0064,,,,,
0065,,,,,
0066,FF,,FF,,FF
0067,FF,,FF,,FF
0068,,,,,
0069,,,,,
006A,40,,40,,40
006B,01,,01,,01
006C,0B,,0B,,0B
006D,,,,,
006E,05,,05,,05
006F,18,,18,X,19
0070,03,,03,,03
0071,30,,30,X,23
0072,54,,54,X,6A
0073,05,,05,X,06
0074,,,,,
0075,82,,82,X,85
0076,A8,X,A9,X,12
0077,0D,,0D,X,0E
0078,08,,08,,08
0079,1C,,1C,,1C
007A,1E,,1E,,1E
007B,08,,08,,08
007C,B3,,B3,,B3
007D,,,,,
007E,8E,,8E,,8E
007F,26,,26,,26
0080,FF,,FF,,FF
0081,D0,,D0,,D0
0082,01,,01,,01
0083,,,,,
0084,23,,23,,23
0085,05,,05,,05
0086,07,,07,,07
0087,FD,,FD,,FD
0088,04,,04,,04
0089,FD,,FD,,FD
008A,02,,02,,02
008B,FB,,FB,,FB
008C,FE,,FE,,FE
008D,FB,,FB,,FB
008E,09,,09,,09
008F,FB,,FB,,FB
0090,,,,,
0091,02,,02,,02
0092,05,,05,,05
0093,,,,,
0094,,,,,
0095,FD,,FD,,FD
0096,FA,,FA,,FA
0097,,,,,
0098,A8,X,A9,X,12
0099,0D,,0D,X,0E
009A,,,,,
009B,,,,,
009C,,,,,
009D,,,,,
009E,,,,,
009F,,,,,
00A0,82,,82,,82
00A1,01,,01,,01
00A2,D1,,D1,,D1
00A3,0B,,0B,,0B
00A4,A9,,A9,,A9
00A5,01,,01,,01
00A6,37,,37,,37
00A7,05,,05,,05
00A8,67,,67,X,96
00A9,26,,26,,26
00AA,,,,,
00AB,,,,,
00AC,,,,,
00AD,,,,,
00AE,,,,,
00AF,,,,,
00B0,,,,,
00B1,,,,,
00B2,,,,,
00B3,,,,,
00B4,01,,01,,01
00B5,,,,,
00B6,,,,,
00B7,,,,,
00B8,67,,67,,67
00B9,68,,68,,68
00BA,5D,,5D,,5D
00BB,64,,64,,64
00BC,61,,61,,61
00BD,6B,,6B,,6B
00BE,64,,64,,64
00BF,68,,68,,68
00C0,5C,,5C,,5C
00C1,65,,65,,65
00C2,64,,64,,64
00C3,64,,64,,64
00C4,65,,65,,65
00C5,66,,66,,66
00C6,62,,62,,62
00C7,63,,63,,63
00C8,01,,01,,01
00C9,68,,68,,68
00CA,55,,55,,55
00CB,4D,,4D,,4D
00CC,A3,,A3,,A3
00CD,72,,72,,72
00CE,14,,14,,14
00CF,68,,68,,68
00D0,,,,,
00D1,,,,,
00D2,4F,,4F,,4F
00D3,,,,,
00D4,01,,01,,01
00D5,,,,,
00D6,,,,,
00D7,,,,,
00D8,57,,57,,57
00D9,35,,35,,35
00DA,39,,39,,39
00DB,59,,59,,59
00DC,30,,30,,30
00DD,30,,30,,30
00DE,35,,35,,35
00DF,35,,35,,35
00E0,38,,38,,38
00E1,30,,30,,30
00E2,,,,,
00E3,,,,,
00E4,,,,,
00E5,,,,,
00E6,,,,,
00E7,,,,,
00E8,,,,,
00E9,,,,,
00EA,44,,44,,44
00EB,D2,,D2,,D2
00EC,44,,44,,44
00ED,58,,58,,58
00EE,14,,14,,14
00EF,DB,,DB,,DB
00F0,03,,03,,03
00F1,,,,,
00F2,,,,,
00F3,,,,,
00F4,41,,41,,41
00F5,03,,03,,03
00F6,4F,,4F,,4F
00F7,4F,,4F,,4F
00F8,3F,,3F,X,17
00F9,3F,,3F,,3F
00FA,26,,26,,26
00FB,3F,,3F,,3F
00FC,17,,17,,17
00FD,,,,,
00FE,,,,,
00FF,,,,,
0100,,,,,
0101,04,,,,04
0102,21,,,,21
0103,,,,,
0104,,,,,
0105,,,,,
0106,20,,,,20
0107,,,,,
0108,,,,,
0109,,,,,
010A,,,,,
010B,,,,,
010C,AE,,,,AE
010D,01,,,,01
010E,88,,,,88
010F,04,,,,04
0110,,,,,
0111,,,,,
0112,,,,,
0113,0A,,,,0A
0114,,,,,
0115,AE,,,,AE
0116,01,,,,01
0117,88,,,,88
0118,04,,,,04
0119,31,,,,31
011A,,,,,
011B,,,,,
011C,,,,,
011D,04,,,,04
011E,06,,,,06
011F,66,,,,66
0120,,,,,
0121,66,,,,66
0122,,,,,
0123,,,,,
0124,58,,,,58
0125,02,,,,02
0126,,,,,
0127,,,,,
0128,,,,,
0129,,,,,
012A,,,,,
012B,,,,,
012C,,,,,
012D,,,,,
012E,21,,,,21
012F,11,,,,11
0130,,,,,
0131,,,,,
0132,AB,,,,AB
0133,92,,,,92
0134,01,,,,01
0135,,,,,
0136,,,,,
0137,20,,,,20
0138,,,,,
0139,,,,,
013A,,,,,
013B,,,,,
013C,,,,,
013D,,,,,
013E,20,,,,20
013F,,,,,
0140,,,,,
0141,,,,,
0142,,,,,
0143,AE,,,,AE
0144,01,,,,01
0145,88,,,,88
0146,04,,,,04
0147,20,,,,20
0148,,,,,
0149,,,,,
014A,,,,,
014B,03,,,,03
014C,64,,,,64
014D,,,,,
014E,,,,,
014F,,,,,
0150,CC,,,,CC
0151,01,,,,01
0152,74,,,,74
0153,04,,,,04
0154,05,,,,05
0155,06,,,,06
0156,03,,,,03
0157,,,,,
0158,05,,,,05
0159,06,,,,06
015A,01,,,,01
015B,10,,,,10
015C,,,,,
015D,,,,,
015E,21,,,,21
015F,D0,,,,D0
0160,,,,,
0161,,,,,
0162,10,,,,10
0163,03,,,,03
0164,,,,,
0165,,,,,
0166,,,,,
0167,,,,,
0168,,,,,
0169,,,,,
016A,05,,,,05
016B,06,,,,06
016C,,,,,
016D,,,,,
016E,05,,,,05
016F,06,,,,06
0170,01,,,,01
0171,10,,,,10
0172,05,,,,05
0173,06,,,,06
0174,01,,,,01
0175,31,,,,31
0176,,,,,
0177,03,,,,03
0178,,,,,
0179,03,,,,03
017A,22,,,,22
017B,99,,,,99
017C,,,,,
017D,,,,,
017E,,,,,
017F,70,,,,70
0180,99,,,,99
0181,,,,,
0182,05,,,,05
0183,06,,,,06
0184,,,,,
0185,,,,,
0186,,,,,
0187,,,,,
0188,,,,,
0189,,,,,
018A,22,,,,22
018B,30,,,,30
018C,30,,,,30
018D,30,,,,30
018E,30,,,,30
018F,,,,,
0190,02,,,,02
0191,,,,,
0192,,,,,
0193,22,,,,22
0194,69,,,,69
0195,01,,,,01
0196,8D,,,,8D
0197,02,,,,02
0198,66,,,,66
0199,0E,,,,0E
019A,D3,,,,D3
019B,02,,,,02
019C,5B,,,,5B
019D,01,,,,01
019E,F1,,,,F1
019F,0C,,,,0C
01A0,55,,,,55
01A1,0E,,,,0E
01A2,F7,,,,F7
01A3,0C,,,,0C
01A4,,,,,
01A5,,,,,
01A6,,,,,
01A7,,,,,
01A8,,,,,
01A9,,,,,
01AA,,,,,
01AB,,,,,
01AC,01,,,,01
01AD,,,,,
01AE,,,,,
01AF,,,,,
01B0,,,,,
01B1,,,,,
01B2,64,,,,65
01B3,01,,,,01
01B4,AC,,,,AC
01B5,,,,,
01B6,7E,,,,7E
01B7,03,,,,03
01B8,91,,,,91
01B9,,,,,
01BA,B0,,,,B0
01BB,06,,,,06
01BC,56,,,,51
01BD,02,,,,02
01BE,CF,,,,D6
01BF,01,,,,01
01C0,CD,,,,D3
01C1,01,,,,01
01C2,71,,,,76
01C3,01,,,,01
01C4,,,,,
01C5,,,,,
01C6,80,,,,82
01C7,,,,,
01C8,,,,,
01C9,,,,,
01CA,1D,,,,1D
01CB,1C,,,,1C
01CC,,,,,
01CD,,,,,
01CE,,,,,
01CF,,,,,
01D0,,,,,
01D1,,,,,
01D2,,,,,
01D3,,,,,
01D4,,,,,
01D5,,,,,
01D6,,,,,
01D7,,,,,
01D8,,,,,
01D9,,,,,
01DA,,,,,
01DB,,,,,
01DC,,,,,
01DD,,,,,
01DE,,,,,
01DF,,,,,
01E0,,,,,
01E1,,,,,
01E2,,,,,
01E3,,,,,
01E4,,,,,
01E5,,,,,
01E6,,,,,
01E7,,,,,
01E8,,,,,
01E9,,,,,
01EA,,,,,
01EB,,,,,
01EC,02,,,,02
01ED,,,,,
01EE,,,,,
01EF,,,,,
01F0,,,,,
01F1,80,,,,80
01F2,,,,,
01F3,,,,,
01F4,,,,,
01F5,80,,,,80
01F6,02,,,,02
01F7,04,,,,04
01F8,,,,,
01F9,,,,,
01FA,,,,,
01FB,,,,,
01FC,,,,,
01FD,,,,,
01FE,,,,,
01FF,,,,,
0200,F8,,,,FA
0201,EB,,,,ED
0202,,,,,
0203,,,,,
0204,CC,,,,D0
0205,01,,,,01
0206,,,,,
0207,,,,,
0208,,,,,
0209,,,,,
020A,0F,,,,32
020B,,,,,
020C,,,,,
020D,,,,,
020E,,,,,
020F,,,,,
0210,,,,,
0211,,,,,
0212,0A,,,,0A
0213,0B,,,,0B
0214,,,,,
0215,34,,,,34
0216,08,,,,08
0217,,,,,
0218,,,,,
0219,9A,,,,9A
021A,0B,,,,0B
021B,,,,,
021C,,,,,
021D,01,,,,01
021E,,,,,
021F,,,,,
0220,,,,,
0221,,,,,
0222,,,,,
0223,,,,,
0224,,,,,
0225,,,,,
0226,,,,,
0227,,,,,
0228,,,,,
0229,,,,,
022A,,,,,
022B,,,,,
022C,,,,,
022D,,,,,
022E,,,,,
022F,,,,,
0230,,,,,
0231,,,,,
0232,,,,,
0233,,,,,
0234,,,,,
0235,,,,,
0236,,,,,
0237,,,,,
0238,,,,,
0239,,,,,
023A,,,,,
023B,,,,,
023C,,,,,
023D,,,,,
023E,,,,,
023F,01,,,,01
0240,,,,,
0241,,,,,
0242,,,,,
0243,,,,,
0244,,,,,
0245,,,,,
0246,,,,,
0247,0B,,,,0B
0248,,,,,
0249,0B,,,,0B
024A,0B,,,,0B
024B,,,,,
024C,,,,,
024D,25,,,,25
024E,25,,,,25
024F,25,,,,25
0250,25,,,,25
0251,25,,,,25
0252,0B,,,,0B
0253,25,,,,25
0254,25,,,,25
0255,25,,,,25
0256,0B,,,,0B
0257,,,,,
0258,,,,,
0259,0B,,,,0B
025A,0B,,,,0B
025B,,,,,
025C,0B,,,,0B
025D,0B,,,,0B
025E,,,,,
025F,,,,,
0260,,,,,
0261,,,,,
0262,,,,,
0263,,,,,
0264,,,,,
0265,,,,,
0266,,,,,
0267,,,,,
0268,,,,,
0269,,,,,
026A,,,,,
026B,,,,,
026C,,,,,
026D,,,,,
026E,,,,,
026F,,,,,
0270,,,,,
0271,,,,,
0272,,,,,
0273,,,,,
0274,,,,,
0275,,,,,
0276,,,,,
0277,,,,,
0278,,,,,
0279,,,,,
027A,,,,,
027B,,,,,
027C,,,,,
027D,,,,,
027E,,,,,
027F,,,,,
0280,3D,,,,3D
0281,0A,,,,0A

@sinopsysHK
Copy link

sinopsysHK commented May 7, 2019 via email

@dgerber
Copy link

dgerber commented Jun 5, 2019

So, the suffix in write commands seems to be a (model specific?) opaque key...
In what looks like the manufacturer's "adjustment program" for the XP-830, XP-530, XP-630 and XP-635, it's hardcoded as "4A 73 6A 74 68 62 73 6E" (ASCII: "Jsjthbsn", in place of "Bmuibf b/" in the above wireshark logs), and it does work on an XP-830.

@sinopsysHK
Copy link

So it means reink in current version do not enable the reset as this command suffix isn't supported hence the failure on XP-620 I guess.

Obviously my proposed PR will not work neither for XP-821 neither as I didn't add this suffix (I thought it could have been par of the USB protocol)

But reviewing the code and the trace it is clear that this 8 bytes suffix is fully part of the command but I have no clue it it is dynamically computed (kind of checksum) or if it is static kind of internal key. I couldn't find any reference on that matter :(

@deinhofer
Copy link

Hi,
Here is the report for my XP-510.
Are you still trying to support the XP-models??
epson-xp-510-1strun.txt

thank you!!

@Typhon0
Copy link

Typhon0 commented Jul 28, 2021

Hi, by searching how to reset the waste ink counter on my XP-510 I found a blog using an snmpget command to reset the waste ink counter.

snmpget.exe -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.17.0.0.72.112.116.116.122.113.106.118

It's actually working, but I don't know if the snmp packets are useful to support this model in reink.

@gravasio
Copy link

gravasio commented Nov 8, 2021

Hi, just to add a hint I found the OID for the XP-540:
snmpget.exe -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.20.4.66.189.33.17.0.0.71.106.115.110.106.98.111.98

@3BIUM
Copy link

3BIUM commented Jan 1, 2023

Hi all,

thanks to this thread I was able to finally reset my Epson XP-850 that was sitting getting dust for four years.
I gathered all the information using that dodgy WIC reset utility (using the "trial" key) and reading the logs (as per @r1m post).
For my model, it behaved exactly the same as it did for @r1m.
The only different thing I did, was set back to the previous values addresses 52.0, 53.0, 237.1, but it always failed to modify 273.1 and I left it as is. I'm not that knowledgeable to understand why, but the utility managed to do so with the same write key.

It should be obvious, but: if you want to replicate it, do it at your own risk.

Just one note in case you only use the WIC utility with the "trial" key: be aware that if your printer has two WICs, it will reset both to 80% and, in my case, only the first one was above 100%, the second was at 12%.

@Earnestly if you want, you can update the table:
Epson XP-850
Model Number: .40.0
Key: .73.106.99.106.116.100.118.116 - Ijcjtdvt (Hibiscus)

@axel-1267
Copy link

axel-1267 commented Jan 2, 2023

$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.24.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.25.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.30.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.28.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.29.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.46.0.94.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.26.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.27.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.34.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.47.0.94.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.49.0.0.88.98.108.98.117.112.99.106

Hello, i've tried this on my XP-325 (identical to XP-315) but it does not work. snmpget report always this when i send commands: "00 7C 7C 3A 34 32 3A 4E 41 3B 0C "
Don't tell me the write key is different also for this clone model...
image
Screenshot from 2023-01-02 13-16-53

@Earnestly
Copy link

Earnestly commented Jan 2, 2023

Thanks @3BIUM, updated.

@axel-1267 Those bytes, 7C 7C 3A 34 32 3A 4E 41 3B 0C represent ||:42:NA; which indicates failure, likely because the write key isn't accepted but there may be other reasons I'm not familiar with.

I'm not sure how accurate the wicreset tools are (it seems like it "sprays" a bunch of bytes in certain ranges), or how they're even determining the counter values. I've isolated from examples that it reads 2 or 3 addresses (oid ~24..34) which are used to produce the percent levels for both ink counters.

E.g. The two ink counters here appear to consist of three addresses:

EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.129.8.65.190.160.24.0
EpsonCommonIONET::perform SNMP [READ]: 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31 38 36 46 3B 0C
PrinterEpsonDD4::memoryQuery MEMORY READ: 18 6F
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.129.8.65.190.160.25.0
EpsonCommonIONET::perform SNMP [READ]: 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31 39 31 32 3B 0C
PrinterEpsonDD4::memoryQuery MEMORY READ: 19 12
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.129.8.65.190.160.30.0
EpsonCommonIONET::perform SNMP [READ]: 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31 45 30 30 3B 0C
PrinterEpsonDD4::memoryQuery MEMORY READ: 1E 00
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.129.8.65.190.160.26.0
EpsonCommonIONET::perform SNMP [READ]: 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31 41 36 43 3B 0C
PrinterEpsonDD4::memoryQuery MEMORY READ: 1A 6C
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.129.8.65.190.160.27.0
EpsonCommonIONET::perform SNMP [READ]: 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31 42 30 30 3B 0C
PrinterEpsonDD4::memoryQuery MEMORY READ: 1B 00
EpsonCommonIONET::perform SNMP [SEND]: 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.129.8.65.190.160.34.0
EpsonCommonIONET::perform SNMP [READ]: 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 32 32 30 30 3B 0C
PrinterEpsonDD4::memoryQuery MEMORY READ: 22 00

And from this, it determines:

PrinterEpsonDD4::inkWasteQuery Counter 68.39% This counter is ok.
PrinterEpsonDD4::inkWasteQuery Counter 3.32% This counter is ok.

I have not yet found no way to correlate this. The bit patterns interpreted as IEEE, various fixed-point formats, integer types, etc. don't seem to produce anything that could correspond to the percentages the tool prints.

More application.log examples might be useful to determine more about this.

The next step might be trying to map the EEPROM to note where values are stored, e.g. ~192..201 appears to be the serial ID.

@marcows
Copy link

marcows commented Jan 3, 2023

truncated to 8 characters (or padded with 0's) and then caesar shifted by one (based on ascii, so 0 is shifted to /)

@Earnestly, instead of 0 the key is padded with . which is the ASCII character before /

Great investigation, will soon have a look at the XP-610 I got from my parents-in-law.

@Earnestly
Copy link

Earnestly commented Jan 3, 2023

Good insight, updated to . which is the correct shift direction. Should be possible to express the shift more programmatically with LC_ALL=C tr '[!-~]' '[~-~!-}]'.

@Earnestly
Copy link

Earnestly commented Jan 3, 2023

It seems like the ink counter calculation can be figured out, given the log above:

PrinterEpsonDD4::memoryQuery MEMORY READ: 18 6F
PrinterEpsonDD4::memoryQuery MEMORY READ: 19 12
PrinterEpsonDD4::memoryQuery MEMORY READ: 1E 00
PrinterEpsonDD4::memoryQuery MEMORY READ: 1A 6C
PrinterEpsonDD4::memoryQuery MEMORY READ: 1B 00
PrinterEpsonDD4::memoryQuery MEMORY READ: 22 00
...
PrinterEpsonDD4::inkWasteQuery Counter 68.39% This counter is ok.
PrinterEpsonDD4::inkWasteQuery Counter 3.32% This counter is ok.

Here the values 6F 12 00 seem to be for the first percentage counter and 6C 00 00 for the second. The third byte seems to be a bit of an outlier as it is always 00 and the addresses aren't in sequence; so discarding it.

Interpreting 0x6F12 as 0x126F results in 4719 (other way is too large), and dividing that by its percentage of .6839 (68.39/100) produces roughly 6900. Using this as the factor, it appears to correctly produce the percentages for the first ink counter:

$ gawk 'BEGIN {print strtonum("0x126f") / 69.00}'
68.3913

$ gawk 'BEGIN {print strtonum("0x125e") / 69.00}'
68.1449

For the second counter, the factor appears to be 3257.

$ gawk 'BEGIN {print strtonum("0x006c") / 32.57}'
3.31593

$ gawk 'BEGIN {print strtonum("0x0072") / 32.57}'
3.50015

The address locations may be model specific though, so I'm not sure how useful this is.

@3BIUM
Copy link

3BIUM commented Jan 3, 2023

@Earnestly, looking at my logs, I think you figured it out correctly.

I saw a Youtube video where someone used the official (but cracked) Epson utility and it showed the counters in "point" units (with also the percentages) and there were also indicated "max" values for both counters, which were respectively 8450 and 2903; if I recall correctly, the printer model in the video was the XP-750 (edit: in another video the values were the same also for the XP-600/XP-605). From my logs, calculating the read percentages, I can tell they match also the maximum values for my model (XP-850).
I believe they are model specific, as are the addresses where the counters values are located. From my logs, when the program reads the values, it calls addresses 6.0 (two times), 16.0, 17.0, 18.0, 19.0. So for me the counters values are located at 17.0 & 16.0 (first counter) and 19.0 & 18.0 (second counter). I don't know what 6.0 is for as it was zero and during the reset was overwritten with zero.

It remains to understand what the other addresses (in my case 20.0, 21.0, 52.0 and 53.0) are for. As someone has already pointed out they could be a way to flag that the "trial" key has alredy been used on a printer. In my case the values were 13, 00, 68, 5E and were changed to 00, 00, 5E, 5E when resetting to 80%.
The last used address is 237.1 which in my case was 0A and changed to 00. Considering the fact that now I can't modify it, I believe it is a way to flag if the printer has to display the WIC warning and, if the counters didn't overflow, it can't be set to display the warning.
I didn't test all these theories as I don't want to mess with the printer as I need it now, maybe in the future.

@Earnestly
Copy link

Earnestly commented Jan 3, 2023

That is interesting; soon I might have a spare XP-625 with which I can try various experiments. I may have already written to certain locations and unknowingly changed internal colour settings so that blue now prints as yellow.

It would be nice to believe that these locations can be determined from the content of the eepom itself. Perhaps even the key as the key needs to exist somewhere, in some form, to be compared, but I doubt this is in the eeprom.

@r1m
Copy link

r1m commented Jan 4, 2023

I tried the same than you to convert values to percentage on my printer, you were quicker than me to figure that out. 😉
XP-540 max values seems to be 4806 and 2082.

I believe it would not be so easy to find those from eeprom only, wicreset uses a dedicated database.
I tried to find some patterns in wicreset database located in %APPDATA%\wicreset and trying to figure out patterns that looks like eprom mapping but no luck so far.

@marcows
Copy link

marcows commented Jan 9, 2023

Another one for the table above:

XP-610
Model no.: .121.4 (0x79 0x04)
Key: .72.112.116.116.122.113.106.118 (Hpttzqjv -> Gossypiu)

Determined from ~/.wicreset/application.log using the TRIAL key.

Printer selection in wicreset is named "EPSON XP-610/611/615", so the key (and model no.?) might work for XP-611 and XP-615 as well.

The two waste ink counters could be cleared with these commands then:

$ snmpget -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.16.0.0.72.112.116.116.122.113.106.118
$ snmpget -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.17.0.0.72.112.116.116.122.113.106.118
$ snmpget -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.6.0.0.72.112.116.116.122.113.106.118

$ snmpget -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.18.0.0.72.112.116.116.122.113.106.118
$ snmpget -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.19.0.0.72.112.116.116.122.113.106.118
$ snmpget -Oa -v1 -c public $printer_ip 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.121.4.66.189.33.6.0.0.72.112.116.116.122.113.106.118

The wicreset tool wrote bytes to addresses as follows in this order:

0x0010 0x68 (16.0.104)
0x0011 0x1A (17.0.26)
0x0006 0x00 (6.0.0)
0x0034 0x5E (52.0.94)
0x0014 0x00 (20.0.0)
0x0015 0x00 (21.0.0)
0x0012 0x12 (18.0.18)
0x0013 0x09 (19.0.9)
0x0006 0x00 (6.0.0)
0x0035 0x5E (53.0.94)
0x01ED 0x00 (237.1.0)

This matches #1 (comment) above describing the XP-850 amongst others, also the max counter values of 8450 and 2903 do fit. However, I don't know all of my EEPROM values before the reset.

@marcows
Copy link

marcows commented Jan 9, 2023

The table seems to suffer a bit from dec/hex confusion.

In #1 (comment) for XP-620 there is written 0x57 0x05, the table contains .57.5.
Using the hex value would lead to the same model no. as XP-625, which seems plausible.

In 34bc702 of the xp630 branch it is 0x28,0x09 instead of .28.9., might have to be fixed for XP-630 and XP-830, would be equal to XP-530 then.

@marcows
Copy link

marcows commented Jan 9, 2023

I piped snmpget -Oa -v1 -c public $IP $READ_BYTE_OID output through this one-liner to get a readable hex dump (or any other format the SRecord package supports) of the EEPROM:

sed -n '/^EE:/s/^EE:\([0-9a-fA-F]\{4\}\)\([0-9a-fA-F]\{2\}\);.*/\1:\2/p' | srec_cat - -hex_dump -o - -hex_dump

For my XP-610, reading from 0x0200 and higher returned all 0, so it seems 512 bytes of memory are accessible. However, I only checked up to 0x3FF.

@Earnestly
Copy link

Earnestly commented Jan 10, 2023

Added the XP-610 model, thanks. The OID is in decimal, so the 0x57 wouldn't convert to 57 but to 87 as decimal. As an aside there is a useful flag for snmpget/walk: --hexOutputLen=0. It might help make it a bit easier to parse if you want to convert the hex yourself.

Srecord seems interesting, I'll have to keep that in mind.

@marcows
Copy link

marcows commented Jan 10, 2023

The OID is in decimal, so the 0x57 wouldn't convert to 57 but to 87 as decimal.

Sure, but your table contains .57.5 | 0x39 0x05 instead of .87.5 | 0x57 0x05 for the XP-620.
Similarly for the XP-630 and XP-830.

useful flag for snmpget/walk: --hexOutputLen=0

Will have a look at.

@Earnestly
Copy link

Earnestly commented Jan 10, 2023

That would mean both the 620 and 625 have the same model number which is curious. Regardless, I'll just update it anyway as the whole thing can change as things are learned.

@marcows
Copy link

marcows commented Jan 10, 2023

That would mean both the 620 and 625 have the same model number which is curious.

Which was the case before with 700+850, 630+830 and newly 510+610.

Having a look at the table now, same model number also means same write key. That's consistent.

The table could be adapted to reduce redundancy, only the first XP-* column is different for several rows. Would lose alphabetical order of the printer names of course, but might help recognize other patterns.

@marcows
Copy link

marcows commented Jan 10, 2023

I'd prefer to name Addr2 and Addr1 something like Addr low byte resp. Addr high byte.

By the way, what's this oidPrvCtrl part and how did you get to it?

@Earnestly
Copy link

Earnestly commented Jan 11, 2023

It's from their escpr linux drivers, see epson-net-snmp.c. Low/high is a good idea too.

@marcows
Copy link

marcows commented Jan 12, 2023

@axel-1267 You could identify your model number from wicreset's application.log. If it exists in the table above, then it seems the same key is valid for your printer.

@Dj33as
Copy link

Dj33as commented Jan 12, 2023

$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.24.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.25.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.30.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.28.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.29.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.46.0.94.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.26.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.27.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.34.0.0.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.47.0.94.88.98.108.98.117.112.99.106
$ snmpget -Ov -OQ -v1 -c public "$network_address_of_printer" 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.129.8.66.189.33.49.0.0.88.98.108.98.117.112.99.106

Hello, i've tried this on my XP-325 (identical to XP-315) but it does not work. snmpget report always this when i send commands: "00 7C 7C 3A 34 32 3A 4E 41 3B 0C " Don't tell me the write key is different also for this clone model... image Screenshot from 2023-01-02 13-16-53

I used the same write key on my XP-315 and XP-313 , Used snmp commands with Linux its throw this "00 7C 7C 3A 34 32 3A 4F 4B 3B 0C" :42:OK; instead of "00 7C 7C 3A 34 32 3A 4E 41 3B 0C " that you got and i was able to reset both wastink counters on my printers.
Capture
I think the key only work on similar printer?
Thanks @Earnestly ,@marcows and the others for their help.

@marcows
Copy link

marcows commented Jan 12, 2023

As an aside there is a useful flag for snmpget/walk: --hexOutputLen=0. It might help make it a bit easier to parse if you want to convert the hex yourself.

Using -Oa I already got the format to easily convert to hex dump, I didn't convert the hex myself, just split the hex part into address:data.

Compare these outputs:

$ snmpget -Oa -v1 -c public $IP 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.121.4.65.190.160.16.0
SNMPv2-SMI::enterprises.1248.1.2.2.44.1.1.2.1.124.124.7.0.121.4.65.190.160.16.0 = STRING: ".@BDC PS
EE:0010DD;
          "
$ snmpget -OQ -Ov -OT -v1 -c public $IP 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.121.4.65.190.160.16.0
"00 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31   [.@BDC PS
EE:001]
30 44 44 3B 0C   [0DD;
                      ]"
$ snmpget -OQ -Ov -OT --hexOutputLength=0 -v1 -c public $IP 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.7.0.121.4.65.190.160.16.0
"00 40 42 44 43 20 50 53 0D 0A 45 45 3A 30 30 31 30 44 44 3B 0C   [.@BDC PS
EE:0010DD;
          ]"

simple hex dump for further processing with srec_cat:
0010:DD

@axel-1267
Copy link

@axel-1267 You could identify your model number from wicreset's application.log. If it exists in the table above, then it seems the same key is valid for your printer.

Thanks, I will give a try and dive the logs.

@Dj33as Thanks for your report. I thought about mine and will give it another shot. It could be a network problem on my lan (SNMP traffic restricted) and not the key.

@dgerber
Copy link

dgerber commented Mar 21, 2023

@Earnestly thanks for noting the naming usage! After trying a few taxons...
XP-7100: 'Mfvdpkvn' (Leucojum) !
See https://codeberg.org/atufi/reinkpy

@Earnestly
Copy link

Ha, that's wonderful

@Jocabin
Copy link

Jocabin commented Apr 5, 2023

Hello, I just discover this project and I want to contribute and add support for my printer. I got an XP-245.
Can someone explain me how you know what addresses I need to put into printers.c structure. Except the model_code, I don't understand how do you discern addreses for black, cyan, etc..

@dgerber
Copy link

dgerber commented Apr 6, 2023 via email

@volodya31415
Copy link

Had the "ink pad full issue" with my Expression XP-820. I initially thought that all I need to is replace the tank - $10 and 5 min with screws. But then it turned out to be a stupid counter, and the old tank was nowhere full anyway. After wasting N hours trying to reset the counter (and being rather displeased with Epson), I can confirm that the write code for XP-820 is the same as XP-850 "Ijcjtdvt". The reset sequence that worked for me goes over 16 through 21, use at your own risk:

for xx in 16 17 18 19 20 21 ; do snmpget -Ov -OQ -v1 -c public $printer_ip_address 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.40.0.66.189.33.$xx.0.0.73.106.99.106.116.100.118.116 ; done

One more thing - before I got this working I did upgrade the firmware, this might or might not be needed. I was hoping firmware upgrade will reset the counters, but this did not happen.

To Epson folks - this should be a button on the menu. You can warn customers that not replacing tank will make ink spill, but ultimately it is their choice, just like what cartridges to use. XHFKF! And if you are planning to brick the printer after N pages, this should be in bold letters on the box, so we can avoid buying it, and not have a problem when we need to print something by tomorrow.

@CiRIP
Copy link

CiRIP commented Mar 11, 2024

At the risk of having the gray market Epson reset cabal on my ass, here's a dump of the database WicReset uses. It has a ton of printer models, and the file format isn't super hard to parse.

I might write a parser for it sometime soon. I'd be super grateful if anyone else wants to help.

P.S. I'm also looking into the chipless firmware thing. If anyone has anything relating to that, please chime in.

devices.zip

@Mahito78
Copy link

I stumbled upon a Python project based on Reink which contains some keys for printers. One of them is for the XP-2150. I have an XP-2100, but thanks to the file from wicreset, I found out that the XP-2100 and XP-2150 share the same behaviors.

Here is the key: 67.106.101.98.101.98.115.106
The model key is 50.09.

I wonder if it is possible to reset the counter for the ink cartridge. I'm trying to find the OID code for it but haven't managed to get it...

At the risk of having the gray market Epson reset cabal on my ass, here's a dump of the database WicReset uses. It has a ton of printer models, and the file format isn't super hard to parse.

I might write a parser for it sometime soon. I'd be super grateful if anyone else wants to help.

P.S. I'm also looking into the chipless firmware thing. If anyone has anything relating to that, please chime in.

devices.zip

@wldini
Copy link

wldini commented Aug 23, 2024

Hi, I'm trying to reset the inkpad on my XP-960, could you help me? Is it possible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests