Nakal schrieb: > 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 > 2>&1 > > 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. Abel
