SCSI is often not logical when connections get a bit complicated, or
even when they're simple. On my last computer I had 4 SCSI chains; 2
simple ones allowing 7 devices and 2 of the 15 device kind. Some
combinations needed termination in the middle, some termination at
two points and some none. Depended on what devices I put on and which
cables I used. Scanners were always the most difficult. I just
resurrected a MacPlus with one hard drive that only works without any
termination on the hard drive. Just try different cables and
termination combinations. Best chance is usually some kind of active
termination at the end (or part way along the chain).
If a SCSI device can't be seen by the computer or doesn't respond
consistently, it's usually a termination or cable issue.
Art is correct; the device ID has nothing to do with termination
location - termination only depends on physical location to block
echos.
At 8:07 PM -0700 9/9/02, Arthur Entlich wrote:
>Actually, I suspect your thinking wasn't correct previously (and it
>appears to me your still not set up correctly now). In regard to the
>SS4000, this might explain why the 25 pin wasn't working correctly.
>Since it was not terminated, in spite of being the last physical device
>on that side of the chain, the use of the "less securely grounded"
>cabling may have been enough to cause the upset, and the use of the
>Centronix 50 M may have "saved the day". Incorrect termination doesn't
>always lead to disaster, but it certainly makes it more likely.
>Termination stops "echoing" of the signal back down the cable, but good
>quality cables may help to prevent this problem by allowing for a strong
>enough "correct" signal that the echo doesn't cause enough conflict to
>be noticeable. It may be slowing down the speed if data has to be sent
>more than once.
>
>Also, your SCSI card being device 7 has nothing to do with
>auto-termination. Almost all, if not all SCSI cards are device 7. Your
>card is actually in the center of the chain (most SCSI cards which have
>both internal and external connectors have the internal connection chain
>making up one end, and the external chain the other). If either
>connection is not in use, then the card becomes the "end" of that side
>and is automatically terminated.
>
>So, in your case, your CD burner is the end of the internal side, and
>should be terminated, the card should NOT be terminated (which it seems
>in your case it will automatically decide not to do) and the last device
>on the external side (the flatbed in this case, previously the SS4000)
>should also be terminated.
>
>This is just one of the many reasons SCSI is fast being left behind for
>most consumer applications. The rules are just too easy to
>misinterpret. Apparently SCSI interfacing was one of the most expensive
>customer support issues facing companies that used it for consumer
>applications and although USB 1, 2, and Firewire have certainly had
>their problems (Via chip set for starters), they are much more user
>friendly, when the hardware does what it is supposed to, at least.
>
>Art
>
>
>Thomas Maugham wrote:
>
>> You're correct, of course, and my SCSI card is device 7 (the maximum) thus
>> auto termination is working. My CD burner (internal) is device 2, my
>> external JAZ and ZIP drives are 4 and 5 repectively, my SS4000 is 6 and my
>> flatbed scanner (last physical device on the chain) is 3 so all is well (at
>> least for now!!!) in SCSI Land! The termination switch on the SS4000 was
>> set to OFF previously and, of course, now it still is. With the exception of
>> the flatbed scanner, all the other devices have been up and running since
>> last Christmas and there haven't been any problems. Adding the flatbed
>> scanner was simple and everything else still works.
>>
>> But just to be safe, at each full moon I sacriface a goat or two to
>> hopefully keep the SCSI Gods appeased!
>>
>> Thanks for the good information, it confirms that my thinking is correct.
> >
>> Tom
>>
>
>
>----------------------------------------------------------------------------------------
>Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe
>filmscanners'
>or 'unsubscribe filmscanners_digest' (as appropriate) in the message
>title or body
--
* Henning J. Wulff
/|\ Wulff Photography & Design
/###\ mailto:henningw@archiphoto.com
|[ ]|
----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or
body
