[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
storm totalscan [Re: primax scanner testing]
From: Graham Hay ####@####.#### Date: 5 Nov 2002 18:42:11 -0000 Message-Id: <20021105183751.66419.qmail@web20507.mail.yahoo.com> --- Andre Herms ####@####.#### wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 04 November 2002 07:37, you wrote: > > Hi Andre, > > > > I was looking around for information on getting my scanner working > > under linux and found http://primax.sourceforge.net/ and the link > > to your SANE backend. (definitely the right idea) > > > > I have a Storm Totalscan with a parallel port interface. Its > > supposed to really be Primax Colorado D600. > > > > According to http://px-backend.sourceforge.net/ it should be > > compatible but was untested. I've tried both primaxd with xsane, > > setting the localhost stuff, and the primax_scan program but it > > has some problems. (Yes, I did set EPP in the bios) > > I'm not complaining - just thought you'd like to know. > > > > First of all - it doesn't recognize the scanner and here's why: > > > > Looking at primaxd for example, it has much the same code as > > primax_scan for the identification: > > > > in parport_lock.c, detect_scanner, about line 84 or so: > > > > status = epp_read_one(&back, 0x0E); > > if (!status) { > > switch (back & 0x0F) { > > ... > > ... > > case 0x44: > > printf("Looks like a Primax Colorado D600_OEM\n"); > > > > This looks like a bug. 'back' is of type unsigned char. > > We did this because the D600 is not supported yet. This avoids hardware > damage > :-). > > Removing the "& 0x0f" is the right thing. Aha - to protect and confuse the innocent. OK. I notice there was a list of part numbers, and since I was having problems I opened mine up and heres what I found, I used []'s for extra stuff: model Storm Totalscan central ASIC EICI 072100 [F9810D154] ADC [59752AN] LM9811[CCV] memory W241024AJ-15 [753SE2742755Q116] other Primax EICI 080300 [9810] line buffer [9742H] 74HC244[A? - more like a symbol] motor 62003F Kind of a mix of what other people have it seems. Maybe someone wants to add the info to the list. > > > I installed libieee1284 which sounds like a good idea, and > > tried the CVS code. I didn't have much luck - I had to change > > the CPPFLAGS += to CPPFLAGS = for starters to keep the > > autoconf stuff happy, but on one of the programs it > > complained about config.h.in missing or something. Can't > > You should really use the CVS version as there are some bugfixes which are > not > the official release. > If you don't have the config.h.in you have to create it with the autoheader > program. > > Please try to make it work. I ended up having a look at what autoconf tried to do, and made my own makefile for primax_scan - much less painful (for me). The auto stuff didn't set $SED, missed -lm on the TIFF test, etc. so I gave it a miss. But at least I'm looking at recent code. > I don't have a D600 for testing so I cannot help you much. Some hints are: > Try to use the primax_scan command line tool. > Use the -S option with 600. > It is reported to work with resolutions up to 450 dpi. > At higher resuolutions there appeare some problems. > > > p.s. I'm not on any of the mailing lists, but feel free to copy > > the mail or your response to one if you want to. > > You should really join the primax mailing list. There are others with more > experience with the D600 than me. Done. Hello all. > It would be really great if you could help us make the D600 work. > Please go on. > > Andre Happy to help but I'll need some feedback. Since I'm getting crashes in the calibration (divide by zero), for (pix_count = 0; pix_count < max_pix; pix_count++){ line[pix_count] = (avg[pix_count] / count[pix_count]) & 0xff; (count[pix_count] == 0) I'm looking into why that is. The first thing that stands out is in init_LM9811(). It seems to be reading the adc register values and checking against its own list. There are three there but only one looked at? adc_register[0][] Theres a nice friendly warning: /* FIX THIS IF MORE TYPES ARE SUPPORTED */ which caught my eye. What I read back doesn't match any of those listed and it prints out init_adc: reg: 5 00 -> 70 init_adc: reg: 6 10 -> 00 So it seems to want: 0x0A, 0xE8, 0xFE, 0x8E, 0x31, 0x70, 0x00, 0xF0 and I have 0x0A, 0xE8, 0xFE, 0x8E, 0x31, 0x00, 0x10, 0xF0 so it changes it. Is that ok? normal? If I leave that alone, but skip calibration, it will go off and start to scan. With -S 300, it'll get half way along and stop, waiting to read back stuff. With -S 600 it just segfaults in malloc for some reason. -S 150 goes a short way but does produce an all-black tiff. Does anyone have any advice for proceeding? I don't know enough about why its failing to do much. > > PS: If you have only problems with compilation - please send me more infos so > > I can help you. I could also send you a more compilable tar.gz package. > > - -- > Andre Herms ####@####.#### I think I'm ok for building now, but a tar.gz would be nice in case I screwed up somewhere. Graham __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |