Major Problem - "Waiting to Print" on iRC5180/iRC5185 - Please Help!

[phorts]

Yourownfree,

I really do appreciate your time and everyone who has replied. The only reason I keep referring to the fact that it's a new machine is because this is the SECOND brand new machine doing the EXACT same thing. In my experience..never have two machines in a row (brand new aside) have the exact same problem back to back in the same environment..never. The likelihood that both machines have the same failure is pretty close to 0%.... but like i've said..i wont rule anything out.

As far as what you're suggesting. You may not have read my entire post here... it is long, so i'll reiterate it here in more detail.

I've used EVERY driver from UFRII, to PCL and PS. Both machines were loaded with all print options. We even placed a colorpass on the 5185...and yes, used the correct drivers.

The problem is not narrowed to one machine, nor is it to one application or file type. I've seen it happen in Word, Excel, Adobe their Business OS, IE, etc. It's happened on Windows XP and 2K. So far the drivers have all been setup directly from each workstation, but currently we've installed the drivers on the server and are sharing the printer out (Using the latest PCL)

All drivers I used were downloaded directly from Canon's website.

So far, no hangups w/ the shared printer scenario... hopefully this continues..

[blackcat4866]

I haven't worked on Canons in a while, but I have a few ideas.

I like the idea of Host Buffer size. I don't know how it adjusts on the Canon, but I'd like to see 32MB at least, preferably 64MB.

Also what sort of applications are you're customers printing from? The red flag I'm looking for is enterprise applications like Unix. They use the driver as a pass-through. That is, the application does all the translating to PCL or PS, then the driver just passes it along to the appropriate port. A creative IT person could send just about any data to one of these pass through drivers. Most of the time nothing happens, but you may be unlucky enough to get data that the machine interprets as printer commands.

This would explain why you cannot reproduce the problem. Why would someone send unprocessed raw data through a pass-through driver directly to a printer? (My customers!)

[Canuck]

2 new machines doing the same thing...its not the copier. Use the canon LPR2 port instead of tcp/ip...Make sure the lan cable is not running thru any filters,etc. I've had machines hang up when network cable is plugged into "power bar surge supressors"..they do some unnecessary filtering. How big are the files that they are printing..PDF's?..variable data? This sounds more like an IT problem than a copier problem

[phorts]

I haven't worked on Canons in a while, but I have a few ideas.

I like the idea of Host Buffer size. I don't know how it adjusts on the Canon, but I'd like to see 32MB at least, preferably 64MB.

Also what sort of applications are you're customers printing from? The red flag I'm looking for is enterprise applications like Unix. They use the driver as a pass-through. That is, the application does all the translating to PCL or PS, then the driver just passes it along to the appropriate port. A creative IT person could send just about any data to one of these pass through drivers. Most of the time nothing happens, but you may be unlucky enough to get data that the machine interprets as printer commands.

This would explain why you cannot reproduce the problem. Why would someone send unprocessed raw data through a pass-through driver directly to a printer? (My customers!)

They may have a UNIX based OS, but the drivers were setup direct from each workstation via TCP/IP to the copier. THey are having the problem when printing from a bunch of different apps including Excel, Word, IE, Acrobat and their Business OS (which i beleive is a client/server App running on Unix)....

That's good info to know for the future though..thank you! And I feel your pain... the most dangerous customer is one that "kinda knows computers"... yeah... it usually goes something like "Yeah, well, Bob from accounting does our computers".. To which I respond "That's sick.. Keep Bob away from your computers....for many reasons".

Update today is good, no Waiting to Print issues...

[phorts]

2 new machines doing the same thing...its not the copier. Use the canon LPR2 port instead of tcp/ip...Make sure the lan cable is not running thru any filters,etc. I've had machines hang up when network cable is plugged into "power bar surge supressors"..they do some unnecessary filtering. How big are the files that they are printing..PDF's?..variable data? This sounds more like an IT problem than a copier problem

Exactly.. if it were just one copier then i'd be focusing on the copier..but it just can't be.

One major hurdle is that, not only is it not my network, but it's a huge infrastructure and trying to track down stuff is an all day event. So to eliminate the possibility of bad wiring, bad switch, etc..we moved it to a different location on the same floor, as well as a different floor entirely. Both locations had the same problem. No locations are using any filters that I know of, at least not at the switch level or at the copier.. so my guess is they are not in use. Good thinking though.

So far the server share is working as advertised, but this isnt the first time a solution has worked for a few days and then crapped out. If it does, I will certainly try the LPR2 port instead of TCP/IP.

Can you explain why this might help, after all, it's still going over an IP Port?

[11x17]

I know you have UPGRADED the software but have you thought of DOWNGRADING the software? I have had issues with the v2 software connecting up with a network. Just a thought and good luck.



Dan

[phantomtech]

Hi,

Can you please give me the serial numbers of both machines.There is an issue of SDRAM having a "W" mark on the top left hand side. The problem most probably is coming from SDRAM on sub boards.

<Symptom>
A sub board (SJ-A, PDRM-EF-A, or R-A) used for the iRC3380s, iRC5180s, iRC4580s, and iRC3880s may cause
a faulty image (P-1), or an endless copier engine operation. In particular, an error code "E747" (main controller PCB
error) with one of the following detail codes can be indicated when the SJ-A board is faulty.

This is from a service bulettin from Canon. I had problems like yours on an iRC3380 and solved by replacing the MN CONT to the new type with part number FM2-6807-010. The old P/N was FM2-6807-000.

I hope this works out for you... Good luck.

[phorts]

Thanks for yoru reply phantom,

Unfortunately for me and my peace of mind, we ended up removing the machine from the customer's location and replacing it with a 3380 since the one we had put in was working fine. We now have the 5180 in another location and working flawlessly.

I will keep this in mind for future issues (hopefully I won't need to revert back to this!). But do you think this faulty SDRAM could be causing the "Waiting to Print" issue and not just the continous engine running? It was our belief that the "waiting to print" status of the machine was causing the machine to remain in high rotate thinking it was about to receive a print job.

Thanks for your input...

Hi,

Can you please give me the serial numbers of both machines.There is an issue of SDRAM having a "W" mark on the top left hand side. The problem most probably is coming from SDRAM on sub boards.

<Symptom>
A sub board (SJ-A, PDRM-EF-A, or R-A) used for the iRC3380s, iRC5180s, iRC4580s, and iRC3880s may cause
a faulty image (P-1), or an endless copier engine operation. In particular, an error code "E747" (main controller PCB
error) with one of the following detail codes can be indicated when the SJ-A board is faulty.

This is from a service bulettin from Canon. I had problems like yours on an iRC3380 and solved by replacing the MN CONT to the new type with part number FM2-6807-010. The old P/N was FM2-6807-000.

I hope this works out for you... Good luck.