[sane-devel] Epson gt-8000 transparency experiment
Bart Buitinga
bartbuitinga@xs4all.nl
Sat, 29 Nov 2003 13:58:58 +0100
Karl Heinz Kremer wrote:
> You are very brave :-)
not to mention accurate, smart and very very funny... 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 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.
>
> 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? (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.
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...
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
>
>
>
>
>