[sane-devel] Epson gt-8000 transparency experiment
Karl Heinz Kremer
khk@khk.net
Sat, 29 Nov 2003 10:02:55 -0500
On Nov 29, 2003, at 7:58 AM, Bart Buitinga wrote:
> Karl Heinz Kremer wrote:
>
> > You are very brave :-)
>
> not to mention accurate, smart and very very funny...
This was implied :-)
> But you're sure a very helpful group yourselves. It makes me think of
> the recently GNUified Arachne project, the originally Czech webbrowser
> for DOS that is conquering one 80386 after another (see
> http://home.hetnet.nl/~ba8tian/arachne/arachne.htm )
I used this on a 16MHZ 386SX a long time ago.
>
> >
> > I would not short two contacts without a resistor. For the first
> > attempt I would use something like 1K. I doubt that any of the 24V
> > lines are involved in sensing the TPU. If the 1K resistor does
> > not give you any result, go down to 0.5K.
>
>
> I'm not touching the 24V again; in fact I blocked the pins with
> matches.
> What I was thinking of is after lowering all 5V lines 1 by 1, to do the
> same with pairs. But first I'd like to know how to interprete the
> results:
>
> If nothing changes (4 5 6 14 15), the line may belong to an option
> accessory, but just isn't the one used for detection.
>
> If all goes black I think I hit the 5V line Byron describes as P/S
> output and the power supply blocks for safety reasons, similarly as
> with the 24V pins. This happens on pin 3
>
> If an Error condition occurs (and from the lengthy PDF manual on the
> Epson GT series that I found yesterday (now also available at
> http://www.xs4all.nl/~labrat/downloads/esc_i.pdf . 268 Pages give
> basics on scanning, detailed specs on all communication with the
> computer through serial, parallel and SCSI, appendix describes all
> scanner types separately, but nothing about the feature connector
> pinout of the gt-800 AKA ES-800c): blinking "error" + "ready" LEDS
> mean it's critical and the scanner blocks), it could be that the
> scanner misses an additional property of an option (Possibly if it
> senses a TPU, it wants to initialise it by flashing the lamp instead
> of calibrating the sensor with the tubes as during flatbed init. The
> error lights only flash after the first movement of the carriage,
> which supposedly checks wether the safety screw is loose, has ended,
> so I think that stretches this theory. Assuming that operating the
> lamp is about the only action a TPU can perform, I guess it would use
> at least 5 lines: 24V power, 5V power for the switch, one of the other
> 5V for option detection, one of the defaultly lowered lines for
> detecting wether TPU light is on/off and ground. But some of these may
> of course be shared with the ADF) Error occurs on pins 7 and 8.
The ADF needs more lines, because there is more that can go wrong in
the paper path, so you also have another input pin, but it may also use
more output pins for the motor.
If your software reports the ADF, you know that you are close.
>
>
> >
> > How do you test if the TPU is recognized? The Sane backend will
> > report the TPU as valid scan source if it's found, so you should
> > be able to just run a frontend and see if you can select the TPU.
>
> I'd be most happy to test SANE on my linux install, but can it be done
> with RedHat 5.2 or would you recommend another Linux for my AMD
> K5/166MHz, 48Mb, 2x500Mb?
Try to compile it. You don't need a fancy frontend: scanimage will do.
It will report all valid options. ADF or TPU are only reported as valid
options if they are actually found.
> (Knoppix also boots, but KDE, not to mention OpenOffice, tends to
> outwait me) Apart from that: Does SANE handle this parallel connected
> semi dinosaur right away or should I first get a SCSI controller?
> I think the win95 TWAIN32 driver I use has about all options for the
> scanner (ESC command level B4, the driver also supports B5 scanners
> and the .hlp describes the TPU and ADF options), and as it is called
> from some imaging program it shows a "source" option that is dimmed as
> long as there's no option detected.
This will also work.
>
> My procedure is as follows:close TWAIN32, Scanner off, paperclip
> placed, scanner on, if alive load TWAIN32.dll, look at source button,
> scan (or not).
> Both the hardware manual and the drivers .hlp explicitly mention the
> unavailability of the option features with no option installed. The
> scanner will respond NAK on a ESC E command and the driver GUI indeed
> dimms the source option button). There'll be some screenshots at
> http://www.xs4all.nl/~labrat/downloads soon.
>
> I'll be looking for some resistors...
You probably don't have the neighborhood Radio Shacks in Holland...
Good luck,
Karl Heinz
>
> Bart
> >
> > Karl Heinz
> >
> >
> > On Nov 28, 2003, at 6:57 PM, Bart Buitinga wrote:
> >
> >> Scanner reanimation:
> >>
> >> Pin 11 can be traced to the chassis at 0 ohms - lengthy route but
> checked
> >> (it also connects to pin 25 on the upper SCSI connector, two pins
> >> on the biggest square chip on the board via some mini resistors
> and
> >> equally small thingies that seem to have variable resistance but
> maybe it's just the combination. These all look fine).
> >> Pins 10 and 2 are directly connected to the chassis
> >> Pins 1 and 9 are together connected to the 24V parts of the main
> board
> >> (This area covers two entire edges on the upper side of the board)
> >> connected to the power supply connector through a 35V 100 microF
> >> condensator and some three pin element numbered fl4 on the board and
> >> 470 with an underscore 0 on its dark brown square side.
> >> 0 ohms between the power supply and pin 1 (24v)
> >>
> >> But then I thought to plug the lot back in to see if theres 24V
> output
> >> from the power supply, and with the 220 volts parts lying on a cd
> box,
> >> LIFE could be heard in the stepmotor :-) Leds also indicated the
> >> scanners awareness of its obvious erratic condition so I put the lot
> >> together again and am ready to continue. Nothing changed, really...
> >>
> >>
> >>
> >> Martin Collins wrote:
> >>
> >>> On Fri, 28 Nov 2003 19:39:48 +0100
> >>> Bart Buitinga <bartbuitinga@xs4all.nl> wrote:
> >>>
> >>>> I'm not sure what is
> >>>> meant with "high" when testing pins with a multimeter.
> >>>>
> >>> High is 5V for TTL electronics, low is <1V. 24V is goodbye :-(
> >>
> >>
> >>
> >>
> >> There we go........
> >>
> >> connecting 5V to ground... there are some to choose from. Can't be
> as
> >> risky as the 24V though.
> >>
> >> top row pins 1-8
> >> bottom row pins 9-15
> >>
> >> As said pins 2 and 10 are chassis together, 11 too, but elsewise.
> >> 3, 4, 5, 6, 7, 8, 14, 15 carry 5 volts
> >>
> >> 2-3 no life
> >> 2-4 initialising; scans as usual
> >> 2-5 same
> >> 2-6 same
> >> 2-7 error (red LED flashes)
> >> 2-8 error
> >> 2-14 scans as usual
> >> 2-15 same
> >>
> >> 11-3 no life
> >> 11-4 scans as usual
> >> 11-5 same
> >> 11-6 same
> >> 11-7 error
> >> 11-8 error
> >> 11-14 scans as usual
> >> 11-15 same
> >>
> >> Would it be safe to connect two 5V pins together to the ground?
> >> Would it make sense to put 5V on the 0.13V pins 12 and 13 (maybe one
> >> is for ADF, the other for TPU; result follows...
> >> 12-8 error
> >> 12-15 scans as usual,
> >> 13-15 same)
> >>
> >> Maybe a resistor used to ground the errorcausers (7, 8), instead of
> >> the bent paperclip so far used, could make a difference?
> >>
> >>
> >>
> >> I've come back on my plan to intercept the tube feeding cables: The
> >> screws in the lamp/sensor unit have been tightened too fanatically
> and
> >> the part seems to fragile to risk heavier tools or chemicals. Or
> maybe
> >> I'll just drill them out if I can immobilise the thing, but that's
> for
> >> later.
> >>
> >> But it feels good to be back in the modern colorful world. Please
> >> klick on any picture at http://www.xs4all.nl/~labrat to see what
> that
> >> means.
> >>
> >> Bart Buitinga
> >>
> >>
> >>>> So I tried connecting 10-12, 10-13, 2-12, 2-13,
> >>>>
> >>> What was probably needed was to connect the right 5V line to a 0V
> >>> line, one or more of which would be ground.
> >>>
> >>>> No more signs of life at all.
> >>>>
> >>> Ouch, sorry to hear that...
> >>>
> >>>> (Or has anyone around got the specific experience I need now???)
> >>>>
> >>> You could try looking at the circuit board. If there are no
> obviously
> >>> burnt out components follow back from pin 1 (or pin 11 if it is not
> >>> connected to ground) and replace each component in turn until it
> works
> >>> again. If there is an obviously burnt out component hope it is
> still
> >>> identifiable and is not an eeprom or something irreplaceable.
> >>> Good luck.
> >>> Martin
> >>
> >>
> >>
> >>
> >> --
> >> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> >> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> >> Unsubscribe: Send mail with subject "unsubscribe your_password"
> >> to sane-devel-request@lists.alioth.debian.org
> >
> >
> >
> >
> >
>
>
> >> >> maybe it's just the combination. These all look fine). Pins 10
> >> and 2 are directly connected to the chassis Pins 1 and 9 are
> >> together connected to the 24V parts of the main board (This area
> >> covers two entire edges on the upper side of the board) connected
> >> to the power supply connector through a 35V 100 microF condensator
> >> and some three pin element numbered fl4 on the board and 470
> >> with an underscore 0 on its dark brown square side. 0 ohms
> >> between the power supply and pin 1 (24v)
> >>
> >> But then I thought to plug the lot back in to see if theres 24V
> >> output from the power supply, and with the 220 volts parts lying
> >> on a cd box, LIFE could be heard in the stepmotor :-) Leds also
> >> indicated the scanners awareness of its obvious erratic
> >> condition so I put the lot together again and am ready to
> >> continue. Nothing changed, really...
> >>
> >>
> >>
> >> Martin Collins wrote:
> >>
> >>> On Fri, 28 Nov 2003 19:39:48 +0100 Bart Buitinga
> >>> <bartbuitinga@xs4all.nl> wrote:
> >>>
> >>>> I'm not sure what is meant with "high" when testing pins with
> >>>> a multimeter.
> >>>>
> >>> High is 5V for TTL electronics, low is <1V. 24V is goodbye :-(
> >>
> >>
> >>
> >>
> >> There we go........
> >>
> >> connecting 5V to ground... there are some to choose from. Can't be
> >> as risky as the 24V though.
> >>
> >> top row pins 1-8 bottom row pins 9-15
> >>
> >> As said pins 2 and 10 are chassis together, 11 too, but elsewise. 3,
> >> 4, 5, 6, 7, 8, 14, 15 carry 5 volts
> >>
> >> 2-3 no life 2-4 initialising; scans as usual 2-5 same 2-6 same 2-7
> >> error (red LED flashes) 2-8 error 2-14 scans as usual 2-15 same
> >>
> >> 11-3 no life 11-4 scans as usual 11-5 same 11-6 same 11-7 error 11-8
> >> error 11-14 scans as usual 11-15 same
> >>
> >> Would it be safe to connect two 5V pins together to the ground?
> Would
> >> it make sense to put 5V on the 0.13V pins 12 and 13 (maybe one is
> >> for ADF, the other for TPU; result follows... 12-8 error 12-15
> >> scans as usual, 13-15 same)
> >>
> >> Maybe a resistor used to ground the errorcausers (7, 8), instead
> >> of the bent paperclip so far used, could make a difference?
> >>
> >>
> >>
> >> I've come back on my plan to intercept the tube feeding cables:
> >> The screws in the lamp/sensor unit have been tightened too
> >> fanatically and the part seems to fragile to risk heavier tools
> >> or chemicals. Or maybe I'll just drill them out if I can
> >> immobilise the thing, but that's for later.
> >>
> >> But it feels good to be back in the modern colorful world. Please
> klick
> >> on any picture at http://www.xs4all.nl/~labrat to see what that
> means.
> >>
>
> >>
> >> Bart Buitinga
> >>
> >>
> >>>> So I tried connecting 10-12, 10-13, 2-12, 2-13,
> >>>>
> >>> What was probably needed was to connect the right 5V line to a 0V
> line, one or more of which would be ground.
> >>>
> >>>> No more signs of life at all.
> >>>>
> >>> Ouch, sorry to hear that...
> >>>
> >>>> (Or has anyone around got the specific experience I need now???)
> >>>>
> >>> You could try looking at the circuit board. If there are no
> obviously
> >>> burnt out components follow back from pin 1 (or pin 11 if it is not
> >>> connected to ground) and replace each component in turn until it
> works
> >>> again. If there is an obviously burnt out component hope it is
> still
> >>> identifiable and is not an eeprom or something irreplaceable.
> >>> Good luck.
> >>> Martin
> >>
> >>
> >>
> >>
> >> --
> >> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> >> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> >> Unsubscribe: Send mail with subject "unsubscribe your_password"
> >> to sane-devel-request@lists.alioth.debian.org
> >
> >
> >
> >
> >
>
>
> >>> >>> line, one or more of which would be ground.
> >>>
> >>>> No more signs of life at all.
> >>>>
> >>> Ouch, sorry to hear that...
> >>>
> >>>> (Or has anyone around got the specific experience I need
> >>>> now???)
> >>>>
> >>> You could try looking at the circuit board. If there are no
> >>> obviously burnt out components follow back from pin 1 (or pin
> >>> 11 if it is not connected to ground) and replace each component
> >>> in turn until it works again. If there is an obviously burnt
> >>> out component hope it is still identifiable and is not an
> >>> eeprom or something irreplaceable. Good luck. Martin
> >>
> >>
> >>
> >>
> >> -- sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> >>
>
> >> Unsubscribe: Send mail with subject "unsubscribe your_password" to
> >> sane-devel-request@lists.alioth.debian.org
> >
> >
> >
> >
> >
>
>
>
>
> --
> sane-devel mailing list: sane-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/sane-devel
> Unsubscribe: Send mail with subject "unsubscribe your_password"
> to sane-devel-request@lists.alioth.debian.org