1 of 1 people found this helpful
Are the computers connecting to the print queue using Network Printer (UNC type) connections?
If not, what print processor is being used by the computers? and what print processor is being used by the Pharos direct queue? (Printer Properties, Advanced, Print Processor). I read in this Pharos Support article a mis-match with the print processors can cause issues. I suspect that may be tied to a similar issue I'm seeing (still testing).
Thanks Paul. Client printers connected via UNC. When we configure the server side queues, we also create an IP (RAW9100) port and point it at the device, we then use the auto configure option the driver to setup the necessary options/trays etc. Then switch the ports back to the Pharos ones. We change the print processor from the default HP one to WINPRINT RAW on the server and then disable bi directional printing and disable advanced printing features. The queues are/were setup and configured before we pointed the clients at them. (Will go and confirm that the client drivers processors etc. are configured as the servers though)
To be honest we still get no print jobs when printing directly on the server through Pharos using test pages and Notepad/word pad documents (bread and butter stuff) and by just changing the ports to point directly at the device rather than through Pharos it works which leads me to believe that the driver setup (on the server at least) is good. Until we can get the server working correctly we'll leave the clients alone and still working on an old 8.1 install. At least I have repeatable print jobs that I can always get to fail to print, so its not an intermittent problem, just need to find a solution and/or work around now...
Bizarrely same driver and jobs work correctly on a HPCM6040, just not on a M401
After some extensive testing carried out by the end user (Thanks Roy!) We are seeing this behaviour (missing last pages/jobs not printing) across all print devices. (MFP and SFP) We have tried a clean vanilla client install connected to the UNC server shares so that there are no other drivers on the client to interfere with the job rendering and the same problems persist (HP UPD 5.8.0). Changing the devices in Pharos from RAW to LPR makes a difference for some documents in that they print but others still do not.
Feeling slightly frustrated that its taking Pharos so long to get to the root cause of this and resolve the issue as it appears to have been going on since v8.2 in one form or another, ever since they moved from having a "real" windows output queue.
The windows spooler doesn't have this problem ;-)
The challenge is that the device is receiving the same data whether it comes through our channel or not, so it is a bugger somewhere inside the HP.
Can you perform this test:
- Install the LPR Client on the Pharos print server.
- Using the same document, submit a job through a Pharos "Hold" queue.
- In a command prompt, change to the ...\JobStore\UserName directory (it will be holding the job).
- Release it via the LPR command line. This will be a RAW job, so LPR -S <printerip> -P raw1 -o l spoolfile.spl will be required.
- Release it again via the Release Station/terminal/iMFP application. Ensure that the Device is using the LPR protocol and that the same LPR queue name (raw1) is present. I would, for this purpose, kill the SNMP state check.
Is there a difference in the output?
I know this discussion is regarding Postscript jobs and the UPD 5.8.0...
I have seen what sounds like the same behavior on occasion. We're running Uniprint 8.4 using UPD 5.7.0 PCL 5. Would you like me to try the same thing with our system? (of course, I'll have to isolate a document that is not getting the last pages printed)
- Paul L.
That would be most helpful. Thank you!