[sane-devel] Reflecta ProScan 7200

[Michael Rickmann]

Am 11.04.2011 00:03, schrieb Jan Vleeshouwers:
> Michael Rickmann<mrickma<at>  gwdg.de>  writes:
>
>>> allan
<---- snip

Hello Jan,
>> Michael,
> Good to hear you are starting to get some response from the scanner. Could you
> tell me how you wrapped the SCSI-commands?
Have a look at
http://wwwuser.gwdg.de/~mrickma/sane-proscan-7200/status-110411/files.tar.gz 
.
They are the files which I have used over last weekend. In pie-usb.c you 
find a function pie_usb_scsi_wrapper from which I branch into the USB 
code. This function takes the same arguments as sanei-scsi-cmd. In 
sane_init and sane_start I first try to attach a SCSI scanner, if that 
fails I try the same for USB. Depending on the outcome I set a function 
pointer to either of the afore mentioned functions.
With the code contained in that download I can get some images using 
xsane, still to dark, faked calibration, frame a bit too high, too slow, 
8-bit only, but at any resolution and quality settings.

> I have done a couple of basic scan runs with varying resolutions, and compared
> the logs to what SCSI-2 and pie.c have got to say. For a rather detailed update
> see http://www.stadspartijeindhoven.nl/jv/DataAnalysis.ods.
That is very valuable. I have not done yet such a systematic 
investigation. A lot of things become clear in your account.
> Your INQUIRY-results
> match what I found, but I also see several options not accounted for in the
> pie-backend. What is interesting about the INQUIRY-command is that it is issued
> repeatedly although it always returns the same information. I haven't been able
> to figure out why that is. Might the device driver be trying to find the best
> way to communicate with the scanner?
That seems harmless, it works with a single INQUIRY as well. I guess it 
is just different Windows dlls which require that information but do not 
communicate it.
> I'm able to interpret many other logged activities as well, but there are still
> large holes, especially with respect to SCSI-commands D7, DC and DD.
>
The DD is also harmless, I named it PIE_READ_STATUS in my code but I do 
not use it yet. It will become important for error handling during the 
initial internal calibration of the scanner and lamp warm up, I guess.
The D7 (named PIE_READ_CALIBRATION) and DD (named PIE_WRITE_CALIBRATION) 
commands are really nasty, as they seem to be used for calibration. I 
tried to formulate a simplified flowchart of what happens when preview 
and an image at normal quality is aquired:
SET_EXP_TIME        x3
SET_HIGHLIGHT_SHADOW    x3
READ_CAL_INFO
SET_SCAN_FRAME
     CUSTOM_READ_d7
     CUSTOM_WRITE_dc
     MODE
     SCAN
         READ        1 line
         TEST_UNIT_READY
         READ        13 lines
         CUSTOM_READ_d7
         CUSTOM_WRITE_dc
         READ        31 lines
     COPY
PARAM
READ            image
CUSTOM_WRITE_d2

SET_EXP_TIME        x3
SET_HIGHLIGHT_SHADOW    x3
READ_CAL_INFO
SET_SCAN_FRAME
     CUSTOM_READ_d7
     CUSTOM_WRITE_dc
     MODE
     SCAN
     COPY
PARAM
READ            image
CUSTOM_WRITE_d2
The double indented lines represent the period when the Win-progs say 
calibrating. Interestingly, my scanner does not move during that period. 
The lines which are read must have been cashed by the scanner. Moreover, 
the scanner does not accept calibration data as sent by the SCSI routine 
pie_perform_cal. It does not accept the wrapped SCSI write, just anwers 
03 02 (error).


> I'm currently checking where different settings can be traced back in the logs.
> With respect to the "color depth" option (8 or 16 bit) in Cyberview, I expected
> large differences in log file size but actually there is almost none. It seems
> as if Cyberview always requests a depth of 16 bit from the scanner, but
> post-processes it to 8 bits afterwards, if asked for.
I think that aquiring 16-bit is preferable, when you have to manipulate 
the outcome before converting into 8-bits.
But the scanner is perfectly able to send in 8-bit mode. It can also 
send in INQ_IMG_FMT_OKLINE (pie.c) mode which is not indexed and which I 
could not detect in any of my logs.
> Changing the "scan mode" option of Cyberview ("Normal" or "Quality") results in
> a change in the required-speed byte of the MODE SELECT data. There is not much
> information about this setting from PIE/Reflecta, and I also do not know what
> speed may have to do with it.
>
That kept me busy last weekend. The quality setting also seems to 
influence what I call calibration mode. As you see in my rough outline 
above, there a scans during which reading the 45 lines is ommited and 
then they have to be ommitted. It appeares that real calibration is done 
after startup or whenever Quality is involved in the current or previous 
scans.
> Yours - Jan
>
>
If you wish to start toying around with your Reflecta scanner under SANE 
and need some help setting up a build system, let me know. I mostly work 
under Ubuntu 10.10.
Regards
Michael