RE: [hpoj-devel] hpo bug (sane 1.0.4)

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Ben "Obi-Wan" Hollingsworth wrote:
> My old box doesn't have USB support.  I conjectured that 
> using that flag
> might make my compiles faster and/or my binary smaller.
It prevents a very small amount of code from being compiled, but I don't
think that the time/space savings is enough to be worth the trouble of
typing an extra parameter on the ./configure command line.  But do as you
wish.  :-)

> BTW, for you Debian types out there, I had to make one little hack to
> make hpoj recognize the QT stuff.  The deb for QT puts the includes
> in /usr/include/qt (not a bad idea, since there are dozens of them),
> but the libs & binaries in /usr/lib & /usr/bin.  The hpoj configure
> script expects all three subdirs to be under the same parent dir.
Thanks for pointing that out.  I added this to my TODO list.

> I had the foresight to leave my PSC 500 on when I came to work today,
> so I tried to scan something just now.  I was fiddling with 
> rc scripts,
> so I killed & restarted ptal-mlcd & ptal-printd numerous times this
> morning.  Here's what's currently running:
> 
>    > psg ptal
>    root     12720  0.0  2.4  1768  740 pts/15   S    11:18   
> 0:00 /usr/local/sbin/ptal-mlcd par:psc500 -alias mlcpp0
>    root     12722  0.0  1.2  1244  392 pts/15   S    11:18   
> 0:00 /usr/local/sbin/ptal-printd mlc:par:psc500 -like /dev/lp0
That looks fine, although the "-alias mlcpp0" isn't really necessary unless
you're upgrading from a previous version of hpoj and don't want to
reconfigure SANE or whatever for the new device name format.

...
> and this in the ptal-mlcd log file:
> 
> ---------
>    ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, 
> dev=<par:psc500>, pid=12720, errno=11
>    Reply timer popped on port=0, count=1!
> 
>    ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, 
> pid=12720, errno=11
>    exClose(reason=0x3002)
That's not good.  :-)  Occasionally I've managed to get the R series and PSC
500 into a bad state, where the LCD scrolls the message "turn the power off
and back on again".  I wonder if that's what happened here?  But in that
case I would have expected a different error.  Anyway, I'm just thinking
aloud here.

Another thing that comes to mind is to make sure that your parallel port is
configured in your BIOS setup for preferably ECP, or PS/2 (aka BPP)
otherwise, but not EPP.  Also, make sure you're using a good parallel cable
and that the device is connected directly to your computer without any
switchboxes or other pass-through devices, such as Zip drives.

Here's another thing you can try, but probably not until you get home and
make sure the device is in a good state.  Add the "-nofork" switch to
ptal-mlcd, and it will give you a debug console.  Use the "log" command to
enable debug logging ("nolog" turns off the debug messages).  Then use the
"activate" command to make it start trying to talk to the peripheral.  When
the messages stop spewing, use the "dump" command, which displays the state
of the internal data structures.  Wait about 20 seconds to see if you get
the "reply timer popped" message.  If that doesn't happen, then in another
window try ptal-devid (this should work if you've gotten this far).  After
this point try printing and scanning (separately) and see what happens.  You
can press control-C to kill ptal-mlcd.

David