[sane-devel] [genesy backend] some patches and a few questions

Gerhard Jaeger gerhard@gjaeger.de
Wed, 15 Dec 2004 08:50:41 +0100


On Wednesday 15 December 2004 07:50, St=E9phane VOLTZ wrote:
>  Hello,
>   I have worked on the genesys experimental backend to make my MD6471 wor=
> First here are some patches:
> - I had to put back a MD6471 sensor since there is a little difference wi=
> the ST24:
> http://perso.wanadoo.fr/septieme/MD6471/03_md6471_sensor.patch
> - since the motors from the different scanners are different, I added a=20
> motor_type field in the device structure. I haven't created a Genesys_Mot=
> struct since I haven't a clear idea of what it should really contain.

well, what about the PWM stuff, the MOTOR_SPEED_MAX etc?

> - I have removed the parameter override in genesys_create_slope_table, an=
> changed a little the pow() computing, since my compiler produces buggy co=
> when 'j' is 0.
> http://perso.wanadoo.fr/septieme/MD6471/05_create_slope_params.patch

Ah, that's what I've detected too in my little test-programm.

>  Then comes some problems:
> - I believe that there's a bug in genesys_create_slope_table. We cuurentl=
> have:
>      time_period =3D  /* time required for full steps */
>  (u_int32_t) (yres * exposure_time / dev->model->base_ydpi)  /
>        (start_speed + (1 - start_speed) * t);   =20
> and I think it should be (multiply instead of a divide):
>    time_period =3D  /* time required for full steps */
>  (u_int32_t) (yres * exposure_time / dev->model->base_ydpi) *
>       * (start_speed + (1 - start_speed) * t);
>  With the first formula (divided by (start_speed + ....), I cannot reach
> satsifying parameters to have a good slope_table, while with the second
> formula (multyply by ...), I can find near perfect match with the slope t=
> in the USB logs.=20

How did you test? Simply start the scanner and check the logs? I created
a samll test-programm with the slope-table function and tried to find out
the correct values, but there are too much "variables". One big question
will be, how to find out the correct settings for other scanners - I've
no idea so far.

> However, changing it would mean changing the start_speed=20
> and 'acceleration'. I can do it for the MD6471, but not fot the other=20
> scanners.=20

Maybe these values are other candidates for the motor-struct. My problem is,
how the figure out these values for my ST24 out of the USB-Logs?

> - the MD6471 doesn't need the extensive asic test done at init, and I fee=
> like adding a flag to optionally skip it.

I guess this test is only for "testing". Feel free to add this flag.

> - another problem is the warmup function, I think this isn't warmup, but
> offset calibration. In th MD6471 logs, a one line scan is done with AFE o=
> at zero, then at a higher value, but both with a coarse gain at zero. And=
> since this takes place where it should (right before coarse gain=20
> calibration), I really believe it is offset calibration. Lamp warmup=20
> detection is only a byproduct.
> - I have created for my needs a genesys_par_head() which is used instead =
> slow_back_home() which doesn't work for my scanner. In fact, it is really=
> close to genesys_check_scanner_lock(). It sends the head back home by set=
> motor to reverse direction, 2 table scanning and steps before scan area t=
> 65535. If parking head after moving it doesn't work, this will indeed det=
> if the head is locked, but doesn't seem the real goal of the function.
> - and last, I resurrected genesys_search_start_position(), but taylored f=
> the MD6471, would it be OK to add it, with a device flag to control if th=
> backend calls it ? I need this to locate the black and with stripes below=
> scanner's top in order to make offset and coarse gain calibration work=20
> reliably.
> To sum up is it OK to:
> - change genesy_create_slope_table()
> - add a flag for optional lazy init
> - add a genesys_park_head() and a flag to control it's use
> - add a flag to control the use of genesys_search_start_position(), and
> resurrect this function.
> - either modify warmup(), or create a genesys_offset_calibration with it'=
> assorted flag

Check it in, maybe I got some more ideas then for the Plustek devices.
I think we should now add a new file: genesys_devices.c, where we put in
all the device structures...

Keep up your work on that