Scanner disconnected - and re-connected

[Computamedic]

I have a client with an OfficeJet 8500 A909a All-in-One which is the source of much current frustration.

The printer/scanner is used primarily from a Windows 7 laptop and very often the scanner is reported as "Disconnected" despite the fact that the device will respond to a PING and the EWS web page.  By ad to disconnectednecte process of elimination I have deduced that removing the printer and fax devices from Windows 7 and using the "Add new device" function to re-detect the 8500 everything returns to normal - all this without touching the 8500 itself.  However, within a short time, often only minutes, the scanner will again become disconnected.  Repeating the same process will restore it again.

The question that is driving me mad is (a) on what basis does the software decide the scanner is disconnected when the device itself is blatantly on-line and (b) why does it so rapidly chnage from connected to disconnected.

The 8500 is connected wirelessly to the router (via a repeater), as is the laptop.

The client also maintains that the printer device wil loccasionally go off-line too, but this is currently much less of a problem but, potentially connected to the same problem.

Any advice much appreciated.

[Computamedic]

Anybody have any ideas??

[UniProg]

Hello Computamedic,

Please go here and download, then run, the HP Print & Scan Doctor and let me know your results.

Good luck!

[Computamedic]

Thanks for that - but the result wasn't particularly surprising.  At a point where the scanner was reported as disconnected  via the HP Support Center, running the Print/Scan Doctor reported the 8500 on an IP address of 0.0.0.0.

Without doing anything to the printer, removing the printer device from the PC (via right click on the device in Devices & Printers) and re-discovering it via the Add New Device from the HP menu item, re-running the Print/Scan doctor now reports the 8500 on 192.168.1.103 correctly - and the HP Support Centre reports it as connected.  Incidentally, attempting a re-discover via the Add New Device without firstly removing the existing device will not achieve anything.

There is obviously a situation where the HP software in the PC "forgets" the IP address of the scanner and whilst it's relatively easy to re-establish connection as I described, it's tedious at the least to have to repeat this process as much as 5 or 6 times a day - virtually every time a scan is needed.

This is running on a relatively new Acer Windows 7 laptop with 4GB RAM.

[UniProg]

Thanks for the update.  Take a look at this document, particularly the 'setting of a static IP address' for your printer.  I think that will make a world of difference.

Please let me know your results.

[Computamedic]

I appreciate the thought - but the address allocation on the printer isn't the point.  The printer has maintained 192.168.1.103 since installation and resolving the connection issue can only be done at the PC, not the printer.  When the Print/Scan Diagnostic reports an IP address of 0.0.0.0 a PING from the laptop to 192.168.1.103 gets the reply expected.  The problem lies in the HP software refusing to recognise that the scanner is there, not that the scanner isn't there.

My original question was an attempt to find out WHAT the software uses to identify the existence of the scanner.  It's obviously not the response to a PING but is it a query against a specific port.  Why would the software (and the diagnostic) be so determined that  the address is 0.0.0.0 when it blantantly isn't??

[Computamedic]

Taking another look at this problem over the weekend, the Print/Scan Diagnostic now detects the device on the correct IP address (192.168.1.103) and the Printer Check runs faultlessly (and the printer is working fine).  The Scanner Check immediately reports a Driver problem but all the suggestions are ineffectual.  As mentioned before, the only solution appears to be to remove the 8500 from Devices & Printers and use the Add New Device function from the HP menu.  This, I'm guessing, re-installs the errant driver and works fine - until "something" causes the driver problem to repeat and the problem to re-appear.

If the problem with the driver is a consequence of some other software I fear it may be a long and tortuous path to find the solution.  Is there no more detailed diagnostic available to identify WHAT the diagnostic detects in the driver??  It almost looks as though there is a background task not running.  It just HAS to be possible to reolve this.

[UniProg]

Hello,

Thank you for all the information and update.  Have you considered the Event Log?  This may show what's going on.