[sane-devel] FreeBSD and Microtek Scanmaker II
Mon, 16 Jun 2003 21:16:55 +0200
> On Sunday 15 June 2003 22:20, abel deuring wrote:
>>IIRC, the delay between two scan passes is really long.
> I don't think so. It always was working fast. Usually about 1 sec after
> the pass the scanner made some switching noises and then recalibrated
> the position and processed the next pass.
What I meant with "time between two scan passes" is the time between the
last read command from one scan pass (or perhaps a command telling the
scanner that this scan pass is ove) and the execution of the next
command. I had only a very short look into microtek.c, so I may be
wrong, but as I understand it, the last command for a scan pass is a
"read", and the next command is a "scan start". The "scan start" command
is probably issued immediately after the last read from the previous
scan pass, so the duration of this "start" command is the time required
to move the scan head back, to switch the color filter and then to do
the "usual things" for the scan start, like perhaps recalibrating the
CCD, moving the scan head into the start position, and whatever else.
And this time is IIRC in the order of a minute or so, perhaps even more.
> The effect now is that the scanner does not do anything after returning
> to the start position. It's like it does not listen anymore.
>>So you could try to increase that time to 3 or 4 minutes or whatever
>>might be appropriate. You can do this by setting the environment
>>variable SANE_SCSICMD_TIMEOUT to the timeout value (in seconds).
> This environment variable seems not to have any effect on FreeBSD.
Which values did you try?
> I made some additional logs for you. Perhaps they are more informative.
> The command was:
> SANE_DEBUG_DLL=128 SANE_DEBUG_SANEI_SCSI=128 scanimage -v -d
> 'microtek:/dev/scanner' --mode color -y 50 > microtek-on-fbsd48.log
> These lines might be interesting:
> [sanei_scsi] sanei_scsi_cmd: scsi returned with status 10
> [sanei_scsi] sanei_scsi_cmd: scsi returned with status 16
The first error occurs immediately after a "read", and this at least
does not contradict my suspicions about the timeout problems. But we
could get a better clue, if you add a "SANE_DEBUG_MICROTEK=255". The DLL
debug output is less interesting.