[Gimp-print-devel] heads up on SureColor P-Series printers (only initial experience mind you)

[Walker Blackwell]

There could be trouble ahead for anyone using Gutenprint with wide-format (24” and wider) SureColor P-Series. In my limited testing on a SureColorP7000, the printer let one print run through fine (literally the same as 9900 printer, same head, etc) and then shut down immediately on the second print. 2 more boot-up and print-tries resulted in the same shut-down error.

It got worse than that however. On the fourth boot-up, the printer will just turned after initial cartridge pressurization but well before getting to “ready” state. It’s a very heavy anchor now.

In short, (my hunch only) the wide-format SureColor P printers may be requiring an authenticated API of some sort, or Gutenprint is corrupting the NVRAM at print-time. Nothing I do can fix the corruption so I’m ordering a brand-new Main Board Assembly to test with Epson driver. I will see if I can scope the USB with the Epson driver if there is a command that is sent to the printer to make it friendly. Any help there would be warmly appreciated as this is first time I’ve done something like that.

Is anyone else successfully printing to the SureColorP wide formats without corruption with newest code?

All the best,
Walker

[f***@walkerblackwell.com]

There could be trouble ahead for anyone using Gutenprint with wide-format (24” and wider) SureColor P-Series. In my limited testing on a SureColorP7000, the printer let one print run through fine (literally the same as 9900 printer, same head, etc) and then shut down immediately on the second print. 2 more boot-up and print-tries resulted in the same shut-down error. There was no diagnostic error on the printer panel itself: just a hard shutdown.

It got worse than that however. On the fourth boot-up, the printer just turned off after initial cartridge pressurization but well before getting to “ready” state. It’s a very heavy anchor now.

In short, (my hunch only) the wide-format SureColor P printers may be requiring an authenticated API of some sort, or Gutenprint is corrupting the NVRAM at print-time. Nothing I do fixes the corruption so I’m ordering a brand-new Main Board Assembly to hopefully solve the immediate large-anchor problem. I will see if I can scope the USB and see if there is a command that is sent to the printer to make it friendly. Any help there would be warmly appreciated as this is first time I’ve done something like that.

Is anyone else successfully printing to the SureColorP wide formats without corruption with newest code?

All the best,
Walker

[Solomon Peachy]

Post by Walker Blackwell
Is anyone else successfully printing to the SureColorP wide formats
without corruption with newest code?

Perhaps an obvious question, but what does the printer do when plugged
into a Windows (or OSX) machine?

(That said, I suspect the underlying problem here is that your printer
is defective...)

- Solomon

[f***@walkerblackwell.com]

So far this has been tested on two SureColor P7000s one at epson dealer (showroom printer that was working well until that point) and one internally with different computers both clean and new. Only same factor is the print data sent to the printer.

I will investigate further when new board arrives . . .

Printer un-connected, connected to windows, connected to mac, connected with pending job from epson driver, it doesn’t matter, I’ve tried it all. It has an NVRAM corruption or something equiv I think introduced from the data sent to it.

best,
Walker

Post by Solomon Peachy

Post by Walker Blackwell
Is anyone else successfully printing to the SureColorP wide formats
without corruption with newest code?

Perhaps an obvious question, but what does the printer do when plugged
into a Windows (or OSX) machine?
(That said, I suspect the underlying problem here is that your printer
is defective...)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Robert Krawitz]

Post by f***@walkerblackwell.com
So far this has been tested on two SureColor P7000s one at epson dealer (showroom printer that was working well until that point) and one internally with different computers both clean and new. Only same factor is the print data sent to the printer.
I will investigate further when new board arrives . . .
Printer un-connected, connected to windows, connected to mac, connected with pending job from epson driver, it doesn’t matter, I’ve tried it all. It has an NVRAM corruption or something equiv I think introduced from the data sent to it.

I'm not going to announce 5.2.13 until this is resolved, if necessary
by pulling support for these printers.

Walker, do you know whether this affects other SureColor printers?
There's no command I'm aware of being sent that specifically writes to
nvram.

Post by f***@walkerblackwell.com

Post by Solomon Peachy

Post by Walker Blackwell
Is anyone else successfully printing to the SureColorP wide formats
without corruption with newest code?

Perhaps an obvious question, but what does the printer do when plugged
into a Windows (or OSX) machine?
(That said, I suspect the underlying problem here is that your printer
is defective...)

[f***@walkerblackwell.com]

It does not effect any small format SCP printers (P400-P800)

It’s going to be a few weeks until I get the new board so I will let you know when I do although I’m hesitant to fry another board until I get my hands on NVRAM utility for this printer which has not surfaced yet. If anyone else has successfully used this on wide format SC-P printers, your input would be helpful as well.

-Walker

Post by Robert Krawitz

Post by f***@walkerblackwell.com
So far this has been tested on two SureColor P7000s one at epson dealer (showroom printer that was working well until that point) and one internally with different computers both clean and new. Only same factor is the print data sent to the printer.
I will investigate further when new board arrives . . .
Printer un-connected, connected to windows, connected to mac, connected with pending job from epson driver, it doesn’t matter, I’ve tried it all. It has an NVRAM corruption or something equiv I think introduced from the data sent to it.

I'm not going to announce 5.2.13 until this is resolved, if necessary
by pulling support for these printers.
Walker, do you know whether this affects other SureColor printers?
There's no command I'm aware of being sent that specifically writes to
nvram.

Post by f***@walkerblackwell.com

Post by Solomon Peachy

Post by Walker Blackwell
Is anyone else successfully printing to the SureColorP wide formats
without corruption with newest code?

Perhaps an obvious question, but what does the printer do when plugged
into a Windows (or OSX) machine?
(That said, I suspect the underlying problem here is that your printer
is defective...)

--
*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Robert Krawitz]

Post by f***@walkerblackwell.com
It does not effect any small format SCP printers (P400-P800)
It's going to be a few weeks until I get the new board so I will let you know when I do although I'm hesitant to fry another board until I get my hands on NVRAM utility for this printer which has not surfaced yet. If anyone else has successfully used this on wide format SC-P printers, your input would be helpful as well.

So, that means:

P400 => OK
P600 => OK
P800 => OK
P6000 => BAD
P7000 => BAD
P7000 Commercial Edition => BAD
P8000 => BAD
P9000 CE => BAD
P10000 => BAD
P20000 => BAD

Support for these printers is in 5.2.12 and this is the first report
I've seen of this. Are you using default settings or something else?

Post by f***@walkerblackwell.com

Post by Robert Krawitz

Post by f***@walkerblackwell.com
So far this has been tested on two SureColor P7000s one at epson dealer (showroom printer that was working well until that point) and one internally with different computers both clean and new. Only same factor is the print data sent to the printer.
I will investigate further when new board arrives . . .
Printer un-connected, connected to windows, connected to mac, connected with pending job from epson driver, it doesn't matter, I've tried it all. It has an NVRAM corruption or something equiv I think introduced from the data sent to it.

I'm not going to announce 5.2.13 until this is resolved, if necessary
by pulling support for these printers.
Walker, do you know whether this affects other SureColor printers?
There's no command I'm aware of being sent that specifically writes to
nvram.

[f***@walkerblackwell.com]

Post by Robert Krawitz
P400 => OK
P600 => OK
P800 => OK
P6000 => BAD
P7000 => BAD
P7000 Commercial Edition => BAD
P8000 => BAD
P9000 CE => BAD
P10000 => BAD
P20000 => BAD

Yes possibly.

All I can say at this point is “possibly bad” until I can verify that this isn’t some other variable specific to only P7000 or P7080 (eu/china version) or my own test environment. The fact that nobody else has mentioned this at all is a bit odd so I feel like it still could just be me and I need to do further digging . . . .

There was one other person asking about violet/llk on this forum a while ago who has one (7000/9000). Maybe they would like to chime in with their experience?

-Walker

[Robert Krawitz]

Post by f***@walkerblackwell.com

Post by Robert Krawitz
P400 => OK
P600 => OK
P800 => OK
P6000 => BAD
P7000 => BAD
P7000 Commercial Edition => BAD
P8000 => BAD
P9000 CE => BAD
P10000 => BAD
P20000 => BAD

Yes possibly.
All I can say at this point is “possibly bad” until I can verify that this isn’t some other variable specific to only P7000 or P7080 (eu/china version) or my own test environment. The fact that nobody else has mentioned this at all is a bit odd so I feel like it still could just be me and I need to do further digging . . . .
There was one other person asking about violet/llk on this forum a while ago who has one (7000/9000). Maybe they would like to chime in with their experience?

OK. But this is obviously of very serious concern.

[f***@walkerblackwell.com]

We have an Epson repair tech coming next week to either re flash or replace the mainboard and power-board.

If it’s a re-flash only, I will attempt to print with the driver again with the tech present. If this kills the board (again) I’ll have confirmed it. If it doesn’t there was some other variable at play.

Regardless, I should be able to report back to everyone here by mid-week next week.

best,
Walker

Post by Robert Krawitz

Post by f***@walkerblackwell.com

Post by Robert Krawitz
P400 => OK
P600 => OK
P800 => OK
P6000 => BAD
P7000 => BAD
P7000 Commercial Edition => BAD
P8000 => BAD
P9000 CE => BAD
P10000 => BAD
P20000 => BAD

Yes possibly.
All I can say at this point is “possibly bad” until I can verify that this isn’t some other variable specific to only P7000 or P7080 (eu/china version) or my own test environment. The fact that nobody else has mentioned this at all is a bit odd so I feel like it still could just be me and I need to do further digging . . . .
There was one other person asking about violet/llk on this forum a while ago who has one (7000/9000). Maybe they would like to chime in with their experience?

OK. But this is obviously of very serious concern.
--
*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Solomon Peachy]

Post by f***@walkerblackwell.com
We have an Epson repair tech coming next week to either re flash or replace the mainboard and power-board.
If it???s a re-flash only, I will attempt to print with the driver
again with the tech present. If this kills the board (again) I???ll
have confirmed it. If it doesn???t there was some other variable at
play.

If possible, capture the print data that's to be sent to the printer (eg
by printing to a file via the GIMP plugin and sending it to the printer
via 'lpr -o raw') before your next attempt to [not] kill the printer. :)

If the problem turns out to be the data sent over, this might be useful
for offline analysis -- both for us and Epson.

- Solomon

[Robert Krawitz]

Post by Solomon Peachy

Post by f***@walkerblackwell.com
We have an Epson repair tech coming next week to either re flash or replace the mainboard and power-board.
If it???s a re-flash only, I will attempt to print with the driver
again with the tech present. If this kills the board (again) I???ll
have confirmed it. If it doesn???t there was some other variable at
play.

If possible, capture the print data that's to be sent to the printer (eg
by printing to a file via the GIMP plugin and sending it to the printer
via 'lpr -o raw') before your next attempt to [not] kill the printer. :)
If the problem turns out to be the data sent over, this might be useful
for offline analysis -- both for us and Epson.

I'd certainly like to see what the OEM driver is sending vs. ours for
the same equivalent (or as close as can be) settings.

[Robert Krawitz]

And since we are holding off 5.2.13 I am waiting before I build the mac version.

Yep. Sorry, but I want to be sure to get this one right.

Post by Robert Krawitz

Post by Solomon Peachy

Post by f***@walkerblackwell.com
We have an Epson repair tech coming next week to either re flash or replace the mainboard and power-board.
If it???s a re-flash only, I will attempt to print with the driver
again with the tech present. If this kills the board (again) I???ll
have confirmed it. If it doesn???t there was some other variable at
play.

If possible, capture the print data that's to be sent to the printer (eg
by printing to a file via the GIMP plugin and sending it to the printer
via 'lpr -o raw') before your next attempt to [not] kill the printer. :)
If the problem turns out to be the data sent over, this might be useful
for offline analysis -- both for us and Epson.

I'd certainly like to see what the OEM driver is sending vs. ours for
the same equivalent (or as close as can be) settings.
--
*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[f***@walkerblackwell.com]

Post by Solomon Peachy

Post by Robert Krawitz
I'd certainly like to see what the OEM driver is sending vs. ours for
the same equivalent (or as close as can be) settings.
--

I’ll try my best but I’m also teaching a Piezography workshop at the same time the tech comes.

If anyone wants to give my addled brain a quick how-too on scoping USB (lpr -0 raw) (or just a url to the manual on how to do this) I’d be much obliged. If this turns out to not be an issue I’ll be happy but totally embarrassed for holding up code production!

How do I scrape the data to a file? Sorry, I’m just an printmaker, not a programmer. But if I can download the data, maybe someone here will be better at looking at it.

best,
Walker

Post by Solomon Peachy

Post by Robert Krawitz
*** MIT Engineers A Proud Tradition http://mitathletics.com ***
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Solomon Peachy]

Post by f***@walkerblackwell.com
If anyone wants to give my addled brain a quick how-too on scoping USB
(lpr -0 raw) (or just a url to the manual on how to do this) I’d be
much obliged. If this turns out to not be an issue I’ll be happy but
totally embarrassed for holding up code production!

Assuming you're printing from an application via the typical CUPS path:

* Add 'PreserveJobFiles On' to /etc/cups/cupsd.conf
* List all settings you used to print (if using an application) or the
cmdline you used. And include the output of 'lpoptions -l' for the
printer in question.

With that we should be able to either have the raw spool data, or be
able to regenerate the spool data from the inputs you supply.

USB sniffing shouldn't be necessary in this context. But on Linux, you
can use tcpdump with usbmon to capture everything.

To do this, run 'lsusb', and look for the logical bus the printer is
attached to printer. For example:

Bus 001 Device 006: ID 06d3:3b36 Mitsubishi Electric Corp.

This printer is attached to bus 001.

You'd then run (as root)

tcpdump -ni usbmon1 -w /tmp/capture.pcap

(If your printer is on bus 2, you'd use usbmon2, and so forth..)

Then trigger the print. After it's done, ctrl-C the tcpdump process and
send us (and probably Epson) /tmp/capture.pcap. Assuming the printer
self-destructs, anyway...

Hope this helps.

- Solomon

[f***@walkerblackwell.com]

Thank you muchly. I will do both.

best,
Walker

Post by Solomon Peachy

Post by f***@walkerblackwell.com
If anyone wants to give my addled brain a quick how-too on scoping USB
(lpr -0 raw) (or just a url to the manual on how to do this) I’d be
much obliged. If this turns out to not be an issue I’ll be happy but
totally embarrassed for holding up code production!

* Add 'PreserveJobFiles On' to /etc/cups/cupsd.conf
* List all settings you used to print (if using an application) or the
cmdline you used. And include the output of 'lpoptions -l' for the
printer in question.
With that we should be able to either have the raw spool data, or be
able to regenerate the spool data from the inputs you supply.
USB sniffing shouldn't be necessary in this context. But on Linux, you
can use tcpdump with usbmon to capture everything.
To do this, run 'lsusb', and look for the logical bus the printer is
Bus 001 Device 006: ID 06d3:3b36 Mitsubishi Electric Corp.
This printer is attached to bus 001.
You'd then run (as root)
tcpdump -ni usbmon1 -w /tmp/capture.pcap
(If your printer is on bus 2, you'd use usbmon2, and so forth..)
Then trigger the print. After it's done, ctrl-C the tcpdump process and
send us (and probably Epson) /tmp/capture.pcap. Assuming the printer
self-destructs, anyway...
Hope this helps.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Matt Hirsch]

Just to chime in, the P9000 CE support was added because of me. I've
continued to use gutenprint with my P9000CE for over a year and never run
into any problems like this or otherwise. Just another data point.

Post by f***@walkerblackwell.com
Thank you muchly. I will do both.
best,
Walker

Post by Solomon Peachy

Post by f***@walkerblackwell.com
If anyone wants to give my addled brain a quick how-too on scoping USB
(lpr -0 raw) (or just a url to the manual on how to do this) I’d be
much obliged. If this turns out to not be an issue I’ll be happy but
totally embarrassed for holding up code production!

* Add 'PreserveJobFiles On' to /etc/cups/cupsd.conf
* List all settings you used to print (if using an application) or the
cmdline you used. And include the output of 'lpoptions -l' for the
printer in question.
With that we should be able to either have the raw spool data, or be
able to regenerate the spool data from the inputs you supply.
USB sniffing shouldn't be necessary in this context. But on Linux, you
can use tcpdump with usbmon to capture everything.
To do this, run 'lsusb', and look for the logical bus the printer is
Bus 001 Device 006: ID 06d3:3b36 Mitsubishi Electric Corp.
This printer is attached to bus 001.
You'd then run (as root)
tcpdump -ni usbmon1 -w /tmp/capture.pcap
(If your printer is on bus 2, you'd use usbmon2, and so forth..)
Then trigger the print. After it's done, ctrl-C the tcpdump process and
send us (and probably Epson) /tmp/capture.pcap. Assuming the printer
self-destructs, anyway...
Hope this helps.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
------------------------------------------------------------

------------------

Post by Solomon Peachy
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot______

_________________________________________

Post by Solomon Peachy
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gimp-print-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[f***@walkerblackwell.com]

Oh, this is SO gratifying to hear!!!!

Epson tech arriving later today. Will test with 5.2.12 and save spool data and let all know results of the P7000 test in a bit.

best,
Walker

Just to chime in, the P9000 CE support was added because of me. I've continued to use gutenprint with my P9000CE for over a year and never run into any problems like this or otherwise. Just another data point.

[f***@walkerblackwell.com]

Sorry, I sent that last post twice. Feel free to delete if it posts.

-Walker