1.       Resources Required - Printers provide no option to automatically reject or resize jobs that are the wrong size.  Rather, the printers hold the jobs and throw the counter-intuitive message “Resources are unavailable for this job.  Load the required resources to continue.”

o   Students mistakenly (but understandably) believe the printer is out of paper and avoid it or call the hotline for help.

o   Sometimes, the offending job can be identified from the web interface and deleted.

§  However, occasionally the offending job isn’t marked on the web interface, or the error message doesn’t go away when you delete the offending job, or there are no jobs on the web interface at all.

o   If the offending job can’t be identified remotely, we must reboot the printer or travel to the site.  For WC6755 printers, printer rebooting is a 7-minute ordeal.

o   Consider the following scenario and its implications, which I encounter frequently:

§   Professor scans page from a textbook.  Depending on scanning software, PDF may be created with improper dimensions (say, 8.5” x 11.1” instead of the standard 8.5” x 11”)

§  Professor distributes PDF to his students.

§  Students attempt to print from CAEN labs, using default settings.

§  Printers don’t have 8.5” x 11.1” paper, so they complain about resources required.

§  Hotline staff/lab inspectors frantically clear errors as fast as they can, but if the document is widely dispersed (lower-level courses that everyone takes) we cannot keep up.

§  The workaround is for users to choose “fit document to paper size” in PDF options, but this is not automatic.

2.       WCP255’s remember old documents for no reason – Random documents get stuck with the status “deleted” after users are done printing them, but they are still on the active job list.

o   The presence of these jobs slows down the user interface.

o   They are often not detectable from the web interface (or they have a different or unintuitive status, like “printing” or “terminating”).

o   They occasionally print again for no particular reason (happens more frequently after clearing jams or rebooting the printer for some other reason)

§  This could be a privacy violation – I believe we explicitly state that we do not store users’ submitted jobs.  In one extreme example last year, a student’s tax returns began printing after I rebooted the printer for an unrelated incident.

o   Clearing these jobs requires at least one (sometimes more) machine reboots, and can only be confirmed by standing at the machine itself.

3.       Job statuses are not intuitive – Typical statuses include “pending,” “processing,” “formatting,” “waiting to print,” “queued,” “paused,” “overwriting,” “terminating,” “printing,” “scheduling,” “deleting”

o   I have personally developed a heuristic sense of what each of these means (mainly, which ones indicate a broken printer and which ones don’t), but there is no intrinsic meaning behind each of these terms.  This makes it difficult for users to determine what is a problem and what isn’t.

4.       Job queues occasionally clog for no apparent reason – Printers will occasionally stop printing jobs.  Newly-released jobs will have the status “pending” and never get anywhere.  When I encounter this, there is nothing physically wrong with the machine, nor can I determine a particular job that is the source of the problem.

o    When a printer is broken like this, there is no error code thrown – we cannot determine there is a problem unless a user calls or a lab inspector happens to visit the lab.

o   The solution is to reboot the printer.

5.       No way to clear a long list of jobs – if a printer is offline or disabled for some reason, it will accumulate jobs submitted by users.  If the network controller is down, the jobs will be queued on workstations and then sent to the printer as soon as it comes back online.  There is no way to delete a lot of jobs at once.

o   When a printer comes back online after a long period of downtime, I have seen it with up to 40 pages of jobs.  This takes about 15-20 minutes for a lab inspector to clear.

o   If a printer is rebooted because the queue was clogged with lots of “pending” jobs (see #4), these will immediately start printing as soon as the machine is rebooted and the first unsuspecting user swipes his/her M-Card, unless you delete them all manually before rebooting.

6.       Printers cannot recover from photocopying or e-mail scanning jams – If a machine jams during a scanning job, it does not provide any meaningful status about what happened to that job.  Occasionally the experience of jamming will render the machine unable to process any further scanning or copying jobs until it is rebooted (sometimes related to issue #7, but occasionally will claim it is processing the job but never actually makes any progress).  Printer does not throw an error code when this happens – requires a user to call and complain, or a lab inspector to visit.

7.       WC5632’s occasionally stop photocopying for no reason – The photocopying service will just die.  Sometimes as a result of #6 above, but sometimes for no reason (in the middle of someone’s photocopying session).  When you attempt to photocopy, the machine will make two beeps, give no error conditions, and fail to do anything.  Printer must be rebooted to fix the issue.  Printer does not throw any error codes when broken.  Seems to affect only WC5632’s.

8.       WC7655’s die on scan-to-email jobs – The job will scan successfully, but get stuck “processing” forever, and never make it to “transferring.”  Happens at random.  This clogs the entire system –cannot photocopy or print any jobs when it happens.  Requires printer reboot to fix.  Does not throw any error codes.

9.       Trays 1 and 2 on WC5632 and WCP255 printers are nearly worthless – Any paper put in these will yellow and wrinkle within two weeks because of the natural heat cycles of the fuser (located directly above the trays).  This causes excessive jamming in the event these trays ever need to be used.  Current workaround is to rotate paper between trays.  This often triggers problem #10 below.

10.   Trays 1 and 2 on WC5632 and WCP255 are sensitive to the touch – Sometimes merely touching them causes the dreaded “Tray <x> out of alignment” error.  This error monopolizes the screen and scares away users.  Fixing it requires jiggling the tray, adjusting the paper, tapping the side of the machine in just the right spot, and occasionally rebooting the printer.  Seems to happen at even the slightest nudge or bump.

11.   No ability to wear-level between trays – The top sheets from the infrequently-used trays (especially trays 1 and 2…see problem #9 above) get wrinkled and yellowed with infrequent use.  There is no way to make the printer occasionally exercise these trays.  Similarly to starting your generator every two weeks to make sure it will run in case of emergency and to lubricate the engine, we need a way to exercise these trays on a regular basis.  Most jams are a result of a failure in feeding the first sheet of a backup tray.

12.   No ability to disable the bypass tray – We have chosen to discourage its use, however we cannot disable it.  This means anyone could insert foreign materials into the printer and break it.  It also throws a persistent error code (luckily, in the background) that annoys us and could confuse a well-meaning user who views the error list from the user interface.

13.   WC7655 software glitch prevents registering tray 4 as dedicated paper size – All paper trays are either “dedicated” or “user-adjustable” for their paper requirements.  We set them all to “dedicated” to avoid a confirmation screen every time we load them with paper (this confirmation screen, if not acknowledged, prevents users from printing).  Due to a software glitch we cannot change this setting for tray 4 – it immediately changes back.

14.   Printers do not acknowledge daylight savings time – we use job submission time to track errors – twice a year we must manually correct every printer.  For some reason, changing the printer time also requires a system reboot.

15.   User interface communication fault on WC7655 for no reason – Occasionally this error is thrown for no reason.  It renders the machine completely inoperable, and cannot be fixed with a remote reboot.  Must journey to the lab and manually reboot the printer.  I have not found evidence of any loose connections whenever I go to fix this error.

16.   WCP255’s forget that they have paper trays – All trays will show up as “not available” and the printer won’t print anything.  Must reboot to fix.

17.   User interface becomes painful to scroll through when many pages of jobs – the interface gets slower the more jobs you have.  During busy times, this is a problem when it takes someone a long time to find their job

18.   “Release” button is really small on WC5632, WC5655, WCP255 – The button is very small, smaller than the tip of your finger.  On touchscreens with horrible sensitivity (and no way to calibrate), and it is hard to push the button.

19.   Image adjustments are not possible except by Xerox technicians – Every tray has a set of adjustments to make sure the image is right in the center.  Xerox technicians can set this, but we cannot.  They refuse to show me how to access the offset configuration screen.  This means we live with mis-aligned images until we have another excuse to call Xerox.  This is purely a software configuration, and it would be very simple to fix if they would let us.  This is currently plaguing the new Duderstadt machines, but many of the old ones have also drifted out of alignment.

20.   Web Printing allows uploading of arbitrary documents, fails to print most – You can upload any file type and the interface says it was successful.  However, when you release the job, it will fail (after hanging for a minute or two) if the file type is not supported or the job is too complex (for example, we claim to support .doc, but some .doc files with fancy formatting will cause problems).

21.   Web Printing does not allow paper size scaling – Jobs uploaded through the web interface cannot be forced to scale to a paper size (see problem #1).

22.   WC7655 occasionally stops recording completed jobs – I use the “completed jobs” section as an indicator of whether the machine is broken or not.  Sometimes this model just stops recording them for some reason.  You have to reboot it to fix the problem.

23.   Document feeders report phantom jams – Sometimes a document feeder will claim it is jammed, when there’s really no paper stuck in it.  You have to open and close it to make it work again.

24.   Printers report paper path jams when there are none – Sometimes printers will claim there is a jam, but in reality there is no paper anywhere in the paper path.  You just have to open/close all the doors to make it work again.

25.   Printers start sucking a piece of paper in about 2 inches, then proclaim there is a jam – this isn’t really a jam, it just decided to stop feeding the paper for some reason.  You have to clear the paper.  This is frustrating because it usually happens within locked trays.

26.   Printers forget their paper level when you reboot them, and sometimes for no apparent reason – This affects our iPod interface (queries the paper for tray status), and the error codes that the printer throws (Tray <x> is low on paper, etc…).  The printer won’t remember the status until you open/close the trays.  This makes it hard to track supply status.

27.   WC5632/WC5655/WCP255 printers forget their toner levels – Printers will randomly decide to disable the toner gauge.  We then can’t track the status until the toner bottle is completely empty, at which point we must follow a ritual to re-enable the gauge and synchronize it with a full toner bottle.  The WC7655’s don’t have this problem.

28.   WC7655’s claim the color drums last much longer than they really do – I rarely encounter satisfactory print quality on a color drum that is below about 20%.

29.   WC7655’s fuser status often sticks at 5% indefinitely – Many of our printers claim 5%, then just stick there until the quality starts getting bad and I notice that there’s a problem.

30.   Print jobs sometimes take a really long time to do anything when you release them – Randomly happens.  People think the printers are broken and try again or use another machine.  Sometimes they end up printing after a minute of thinking.

31.   Network controllers sometimes crash for no apparent reason – Sometimes they will just die.  Then you have to manually power down/power up the printer to get it working again.  See #32 below.

32.   Some pathological jobs can completely crash printers – We have a quarantine of these jobs up on Sharepoint.

o   Failure method #1: releasing a job will cause the network controller to enter an infinite reboot loop.  Must unplug network, reboot printer, delete job, re-plug network, then reboot printer again to fix.

o   Failure method #2: releasing a job will cause it to stick at “processing” indefinitely, and it cannot be rebooted.  This clogs the queue similarly to what is mentioned in error #4 above. To fix, need to delete all other jobs, then reboot the printer 3 times (at 7 minutes per reboot, this is a terrible condition on the WC7655’s).  At this point the job finally disappears.

33.   WC5632/WC5655/WC7655’s randomly have internal software glitches that cannot be recovered from without a manual reboot – Some common ones include “SMTP service failed to register” and “Reprint saved jobs feature failed to register”

34.   WC5655’s fax non-volatile memory error – sometimes these printers throw this code for no particular reason.  It doesn’t seem to impact the machine’s operation, but it doesn’t look good.

35.   WC5655’s can’t access main web interface – this means we can’t remote reboot them, or view error codes.  Xerox tier 2 support is supposedly looking at this issue.

36.   There is no way to schedule a reboot – since there are so many failure conditions that are fixed with a printer reboot, it would save us a lot of trouble (and credibility with annoyed users) if we could make the machines reboot late at night to clear out any errors (especially those that don’t throw error codes).  However, there is no way to schedule a reboot.

o   I sometimes reboot all the printers manually if I have the sense that there are a lot of problems (basically, if it has been a few days since I last worked).  This takes about half an hour because we have to log into each one with the admin user/pass, and the web interface is very slow.

37.   Can’t change many printer settings from web interface – For example, I wish I could change tray priority and settings remotely, or confirm random dialog boxes that pop up all the time and require physical visits (resource required, guides out of alignment, confirm paper size, etc…)

38.   WC7655 “Failed to Register with Xerox Smart Communication Server” error – happens every now and then.  Is fixed with a reboot, but users see this message and think something is wrong.

39.   Printers will stop accepting any new jobs from users, even though the network is fine – Newly-submitted jobs just don’t show up on the list.  Rebooting the printer fixes the problem, but this doesn’t throw an error code so the only way to tell is to try and print a job from every lab (tedious).

40.   Computers poll the printers every <x> minutes, if they don’t receive a response they list the printer as “offline” until the next poll – so if I have to take a printer offline to run diagnostics, or if I’m rebooting it or something, a computer might fail in its attempt to poll.  When the printer gets listed as “offline” in Windows, you can’t submit any new jobs (from any login), and even rebooting doesn’t fix the problem.  You can’t force a new poll, because that requires administrator privileges on the machines.  You just have to wait it out.  This is a Xerox driver issue.