Need help from IT gurus.

[jmaister]

A KMC2525E is having frequent problem printing. Symptoms include incomplete documents(has page layout but no fonts), emulation errors(machine codes) and sometimes print job just disappear at the machine and the PC will report printing error.

Its definitely not the machine(not going there yet).

I had initially thought is the printerport, swapped nic, didnt help. Restarted printer spooler, problem persist. Then I did the Speedtest.

Its a office in Seattle, but Speedtest.net think its in the east-coast, the downstream is 0.5Mbps, ping is 265ms.

If I ping local, times taken is <1ms and TTL=255.

I've a hunch that the time delay has a play in this, what's your take on it?

[Masterchief]

Incorrect drivers installed???
Driver setup utilities not added upon software installation (print utilility)

Has the machine firmware been upgraded to the latest version

New setting rages are implemented in U325 Setting the distance between pages
to increase the distance by print coverage as measures against background
image in the high coverage print and half speed mode. The distance between
pages increases for the high coverage print with 5 ranks. Higher rank increases
the distance more.
When recovering from sleep mode, there might be the possibility to occur abnormal image (*1)
with the first page printer output. Therefore, it is corrected.
(* 1) Abnormal image (misalignment of the block): The image that both Color misalignment (both
main and sub scan direction) and shrinking occurs at same time.
[Cause]
There is a possibility to judge abnormal signal of ASIC through initial communication after
recovering from sleep mode as Vsync ON (*2). Therefore, correct image can not be generated
and it became abnormal image.

[D_L_P]

Another thing to try, setup a Unix LPR port.

It can be added under Add/Remove Windows Components-> Other Network File and Printing Services->Print Services for Unix.

Then when you go to Add Port there will be LRP Port listed along with the Standard TCP/IP, Local, etc...

This port seems to work better in environments where lag times or dropping print jobs is an issue.

[linuxxpwin]

does this have a UFR Driver? I have had a few cases where I have had to use this driver type to correct printing issues. Rather than PCL Drivers.

[jmaister]

All win xp base systems, will look into drivers, when their IT start to cooperate.

[jmaister]

sorry i don no

Funny man, u troll much?

A taskalfa is going to replace this machine soon, I'll see if it happens with this unit.

[mrwho]

Another thing to try, setup a Unix LPR port.

It can be added under Add/Remove Windows Components-> Other Network File and Printing Services->Print Services for Unix.

Then when you go to Add Port there will be LRP Port listed along with the Standard TCP/IP, Local, etc...

This port seems to work better in environments where lag times or dropping print jobs is an issue.

Is there any practical difference between using the Unix LPR Port and the Standard TCP/IP Port in LPR mode? I often think of the two as doing the exact same thing in two different ways, but am I wrong in thinking that?

[D_L_P]

Unix LPR is RFC 1179 compliant (from the 1990's).
Standard TCP/IP is emulated LPR.

Probably the most significant difference is Unix LPR uses unidirectional communication, whereas the Standard TCP/IP LPR uses SNMP for status and error reporting. Which, if you are having trouble with a printer dropping jobs or falling off the network, a unidirectional communication that doesn't use SNMP might be a good thing.

Another difference has to do with the byte counting. The standard TCP/IP LPR by default doesn't use it and is faster. The byte counting can be enabled but it doesn't do it the same as the Unix LPR. The Unix LPR (RFC 1179 compliant) will spool every job 2x for an accurate byte count. If you run into a situation where you have to enable byte counting to print, you're better off using the Unix LPR.

Other minor differences are with source ports and timeout.

[jmaister]

Unix LPR is RFC 1179 compliant (from the 1990's).
Standard TCP/IP is emulated LPR.

Probably the most significant difference is Unix LPR uses unidirectional communication, whereas the Standard TCP/IP LPR uses SNMP for status and error reporting. Which, if you are having trouble with a printer dropping jobs or falling off the network, a unidirectional communication that doesn't use SNMP might be a good thing.

Another difference has to do with the byte counting. The standard TCP/IP LPR by default doesn't use it and is faster. The byte counting can be enabled but it doesn't do it the same as the Unix LPR. The Unix LPR (RFC 1179 compliant) will spool every job 2x for an accurate byte count. If you run into a situation where you have to enable byte counting to print, you're better off using the Unix LPR.

Other minor differences are with source ports and timeout.

Is it basically a protocal with parity? Will try out LPR

[Hansoon]

The Unix LPR (RFC 1179 compliant) will spool every job 2x for an accurate byte count.

Does that mean it increases the time for ripping a printjob? In other words: Will printing of certain PDF's will take even longer?

Hans

[D_L_P]

The unix lpr will be slightly slower, but it doesn't spool it 2x to the printer. It will rip the job once, spool one file in the system32\spool\printers to send to the printer, then spool a second temp file for an accurate file size. All this happens before it starts communicating to the printer. Also the unix lpr has a 4 minute timeout once it starts.

The standard tcp/ip lpr will rip a job and spool the file to the system32\spool\printers folder. Then send a made up huge byte count to get the job started, then disconnect after the job is done but before the printer finishes the byte count. It is bypassing the error checking for speed.