On Fri, Nov 20, 1998 at 01:41:21PM +0100, Sebastian Erdmann wrote:
>
> On Fri, 20 Nov 1998 00:31:31 +0100, Bernd Schroeder wrote:
> >
> > This sounds indeed strange. Normally the scanner should be in reset state
> > after it is switched on. Or are the colors wrong if the scanner is switched
> > on before the system is booted (or the SCSI driver is loaded) ? Then
> > the SCSI driver sends one or more commands to the device, but these
> > commands should not affect the results of a scan.
>
> I tried every computer/scanner power-up sequence I could think of :-)
> I also tried loading/unloading the SCSI driver, but the problem occurs
> every time. It doesn't seem to be related to SCSI, since it occurs on
> both the Adaptec AVA-1505 host adapter (supplied with the scanner)
> and my NCR 53C810 controller.
But I still don't understand why the device doesn't work after it is
powered on, and then works better, if it switched off an on again.
>
> [...]
> > > I fixed it anyway to prevent potential problems: The scanner seems
> > > to come up with random values for the NTRACK and NCALIB bits in
> > > the system status. The fix (included in the patch below) was to
> > > explicitly set these bits to zero in sane_start().
> >
> > NCALIB set to 1 prevents the scanner from calibration before a scan.
> > This is explicitly set (and later reset) in the do_dummy_scan()-function.
> > Please check, whether the differences for this bit result from these
> > different settings.
>
> Note that my patch places the call to do_dummy_scan() (and therefore
> the call to scsi_send_diagnostic()) in sane_start() before the call
> to scsi_send_system_status(). I did this because I'm not sure whether
> the system status is preserved across a self test. Therefore I need
> to set NTRACK and NCALIB in sane_start().
>
> [...]
> > I experimented with this command myself a while ago as a replacement for
> > this "do_dummy_scan" stuff, but it has some disadvantages.
> >
> > In particular this command is used for every scan if scanimage is used, and
> > as you wrote the execution of this command takes some time. On my
> > own ScanMaker 630 every second "send diagnostics" fails, BTW, with
> > sense code "lamp failure" :/ .
>
> :-/ ... well, this bug doesn't occur on my scanner.
>
> Yes, this "send diagnostics" command is annoying, because it keeps
> the scanner busy for a rather long time. This is the reason for the
> did_self_test flag in my patch. Of course, this flag doesn't help
> with scanimage. On the other hand, my patch shouldn't affect your
> ScanMaker 630, because do_dummy_scan() returns early for this model.
Not in that version of the backend, but in the one I am actually
working on :) . Some ScanMaker 630 have a similar problem in that the
colors are wrong in color scans after a lineart scan (mainly an inverted
green channel), and this can be cured in a similar way.
The reason why I am somewhat sceptical about this "send diagnostics" is
that I think it is an overkill to introduce a command that costs a lot
of time and additional movements of the scan head (and may have side effects)
to work around a problem, that occurs only once after the scanner is powered
on.
> > I suggest not to include this patch into sane-1.00, but to remove the
> > NTRACK and NCALIB changes, and also to introduce an option in the
> > configuration file to enable/disable the "send diagnostics" command
> > (but in a later release of the backend).
> >
> > Bernd
>
> It would be sufficient to issue the "send diagnostics" command just
> once after switching on the scanner. But I didn't find a way to
> determine in software whether the scanner acts weirdly or not --
> the only method seems to be to manually inspect a scanned image.
Yes, that seems to be a problem. I, too, didn't find a way to reliably
recognize, whether the next scan will produce garbage.
> As an alternative, I could write a small stand-alone program that
> just issues a "send diagnostics" command. But such a program would
> duplicate a lot of functionality of the SANE microtek2 backend and
> the SCSI layer. Yet another alternative would be an option settable
> via sane_control_option(). But those alternatives would all require
> user intervention.
>
> If you like, I could go ahead and implement the configuration file
> option as per your suggestion. I think a similar option to control
> do_dummy_scan would also be useful.
I think, that this is the best method to introduce a switches into the
backend (one for the do_dummy_scan and another for the "power on"
problem).
The next release will have an option "disable backtracking", and it can
be configured in the configuration file, whether this option will be
visible in the frontend or not. If not it is set to a default value.
Some other less important options will follow (bind resolution is another
candidate). The purpose is to have less active options in order to reduce
the height of the xscanimage window, because on small screens and with
low resolutions xscanimage exceeds the size of the screen.
So something like 'option fix-thisorthatproblem on/off'
in the configuration file, that activates/deactivates a respective
boolean option in the frontend might indeed be useful (one for each problem).
But I strongly recommend to set the default value for this
"send diagnostics" to "off" (and never activate it if it is not an X6) :) .
Unfortunately I can't provide a current version of the backend, which
actually works, because I am about to include support for non-blocking
IO's. This will simplify a lot of things, but unfortunately it also affects
large parts of the code.
Of course, the best solution would be to know how the Windows software
handles theses sorts of problems. I contacted Microtek once about two
months ago via email because of this problem, that the colors are
wrong after one successful color or grayscale scan, and actually got
a response, but this response was - mildly said - not very exhaustive.
But I am planning to present them a list with problems once again.
Another way would be to trace the SCSI commands of the Windows software
(under wine, for example). I tried this, too, but didn't manage to get
the Scanwizard or even a simple test application running under wine.
It looks as if you have the documentation, so if iyou discover anything that
explains, why these problems occur, please let me know.
Bernd
-- Bernd Schroeder Email: mailto:bernd@aquila.muc.de PGP public key available: mailto:pgp@aquila.muc.de | Subject: send key
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com