Re: Microtek E3 with snapshot 20000130 compiled for OS/2: Still no scans

From: Matto Marjanovic (
Date: Mon Feb 14 2000 - 21:25:44 PST

  • Next message: Henning Meier-Geinitz: "Re: 'scanimage -T' ?"

    > Not since v0.51 has sane-os2 worked with the E3, at least not for
    >me - see several postings last July & August under the thread title
    >"Microtek E3 won't scan but II-G okay (SANE OS/2)".

    Man, I just re-discovered that entire thread in my mailbox, patiently
     waiting to be dealt with....

    > With the new snapshot, the E3 no longer executes those
    >preliminary moves - Sane-OS/2 just reports an I/O error. I'm
    >attaching a pair of log files created by redirecting stdout to file;
    >"10test.log" is a typical aborted run with last summer's build, and
    >"11test.log" uses the 0.11.1 microtek backend as included in last
    >weekend' developmental snapshot. Both tests were run with
    >sane_debug_sanei_scsi=128 and sane_debug_microtek = 128.

    Ok, first just a nit-pick: "10test.log" bugged out because of an
     "unrecognized option `--calib_once=yes'" to scanimage (the option
     is new with v0.11.0 of the backend). But, I still have the logs
     you sent from last summer, so I'm set with that.

    Something changed in the OS/2 scsi code between the two releases,
     because the new version is actually calling the sense handler, which
     reports "ERR_SCSICMD", i.e. a "SCSI Command Error" in Microtek
     parlance, which could mean a number of things, among them:
       a) the command was just not recognized.
       b) the command was sent at an inoportune time.

    The command that bombed was the magic, undocumented "start calibration"
     command, which *should* work on an E3 just as well as an E6 -- well,
     that is a guess, since the entire command stream for that was kind
     of a guess. However, if you add "norealcal" and "noprecal" to the
     .conf file, all this calibration stuff will be skipped --- please
     do this, see what happens, send the full log to me.
    (Assuming the .conf file is parsed correctly; the log file will reveal
     this one way or the other.)

    In one of your earlier messages, you suggested that maybe there was
     a *timing* problem involved here. That is not out of the realm of
     possibilities --- although the E3/E6 seem to be pretty well designed
     in this regard. My E6 will happily accept a command and finish
     whatever it was doing before it executes it, whereas the previous
     generation of scanners seem to complain if they are asked for something
     else too soon.

    So, possibility (b) might be related to that. After I get a look at
     the non-precal debug log, I'll try adding some retry-code to the
     backend --- I haven't done this before because the original lame
     linux scsi drivers never returned reliable sense codes, so I never
     got any sense errors to act upon anyway. (I think the new drivers
     have fixed that now/soon. I'm not sure. Anyone know?)

    But, as far as (b) is concerned, the process fails at a point where
     timing just shouldn't be a problem. Hmmmm. It would be nice to
     get more detailed look of what the scsi system thinks is happening.

    Anyhow, if the ERR_SCSICMD can be trusted, then the scanner is
     bitching about something, and it's not just that the OS/2 scsi
     system has bombed out. But, maybe the OS/2 scsi system sent
     bogus stuff to the scanner, and the scanner is bitching about

    This (older) generation of Microtek scanners seem pretty well built
     and designed to me, *except* for the scsi interface. That part was
     definitely coded by a crack team consisting of a monkey and maybe
     a racoon or squirrel.

    -matt m.

    Source code, list archive, and docs:
    To unsubscribe: echo unsubscribe sane-devel | mail

    This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 21:23:29 PST