# Re: Microtek E3 won't scan, but II-G okay (SANE-OS/2)

Irv Thomae (irv.thomae@succinct.com)
Sun, 18 Jul 99 16:32:36 -0500

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Nick Lamb: "Re: Release early, release often"
- Previous message: georgewu@mediaone.net: "Microtek X6EL problem"
- Maybe in reply to: Irv Thomae: "Microtek E3 won't scan, but II-G okay (SANE-OS/2)"
- Next in thread: Yuri Dario: "Re: Microtek E3 won't scan, but II-G okay (SANE-OS/2)"
- Reply: Yuri Dario: "Re: Microtek E3 won't scan, but II-G okay (SANE-OS/2)"

On Fri, 02 Jul 99 10:09:31 -0500, Irv Thomae wrote:

> Yuri Dario, author of the SANE-OS2 port, has asked me to post this
>problem-report here. We're aware that "microtek" backend problems with the
>E3 were fixed in the Linux distribution almost a year ago, but for reasons
>unclear, the OS/2 ports of SANE version 1.01 (as well as 0.72 and 0.74)
>continue unable to drive the E3:
> (1) After a short precal dance, the E3 quits instead of scanning
> and yet,
> (2)[YD]> Looking at code, there aren't OS/2 specific patches to the
> [microtek] backend.
>...................
> The E3 makes a series of short, slow-speed moves, then a brief,
>high-pitch whine (fast return to home postion, following precal?)
>Immediately after that short move, SCANIMAGE fails with a "Device I/O
>error".

> ....

With sane_debug_sanei_scsi=32 and sane_debug_microtek=32, the E3 failure
occurs after precalibration:

>[microtek] do_precalibrate done.
>[microtek] .scanning_frame...
>[microtek] .scanning_frame: in- 0,0 1181,1181
>[microtek] .scanning_frame: out- 0,0 1181,1181
>[microtek] .accessory...
>[microtek] .download_gamma...
>[microtek] .mode_select 0...
>[microtek] .mode_select: pap_len: 3505
>[microtek] .mode_select_1 0...
>[microtek] .save_mode_sense 0...
>[microtek] .wait_ready 0...
>[microtek] .start_scan...
>[sanei_scsi] sanei_scsi_cmd: command 0x1b failed.
>[microtek] end_scan...
>[microtek] .stop_scan...
>[sanei_scsi] sanei_scsi_cmd: command 0x1b failed.
>[microtek] end_scan: OY! on stop_scan
>[sanei_scsi] OS/2: ASPI closed
>scanimage: sane_start: Error during device I/O
>[microtek] sane_cancel...
>[microtek] end_scan...
>[microtek] sane_close...
>[microtek] sane_exit...
>[microtek] sane_exit: MICROTEK says goodbye.

Besides SANE, I also have Jan Schonepauck's "mtekscan" (Microtek only, last
updated 1997 AFAIK) While browsing through that documentation, I recently
noticed a comment to the effect that the start- or stop-scan command had
needed some "timeout-tweaking" before (mistakenly) declaring it failed.

From earlier exploration of this list's archives, I'm also aware that in
porting SANE to OS/2, Yuri had to contend with subtle differences between the
UNix/Linux thread model and that of OS/2.

I'm probably grasping at straws here, but is it conceivable that seemingly
identical backend code might show different _timing_ characteristics when
executed under OS/2 (multi-threaded, but lacking fork() ), as opposed to
running on the same x86 box under Linux?

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Nick Lamb: "Re: Release early, release often"
- Previous message: georgewu@mediaone.net: "Microtek X6EL problem"
- Maybe in reply to: Irv Thomae: "Microtek E3 won't scan, but II-G okay (SANE-OS/2)"
- Next in thread: Yuri Dario: "Re: Microtek E3 won't scan, but II-G okay (SANE-OS/2)"
- Reply: Yuri Dario: "Re: Microtek E3 won't scan, but II-G okay (SANE-OS/2)"