Printing Mystery Please Solve

[jmoore284]

For the past year or so I have been experiencing an issue with drawings not printing as they should. It happens at random times and only when I batch print drawings. When checking over drawings I just printed I find random lines, pieces of text, and/or blocks which did not print. It is not always a complete item that does not print, and sometimes is only a portion of the block and/or item that did not print.

Here is a list of things I have looked into so far:

I use ACAD 2004 and can create this problem while using the batch plot utility.

I used ACAD Electrical 2007 for a couple months and was able to create the problem using the publish command.

I then upgraded to ACAD Electrical 2008 and can again re-create the issue.

I am running Windows XP and have this issue when using the following printers: HP 8000DN, HP 2200, and an HP 2200 with a duplex feature.

I have uninstalled and reinstalled all versions of ACAD.

I have reformatted my machine and then reinstalled ACAD.

We have purchased 16 megs of additional ram for the HP 8000 in the past month.

No error messages are present. Also no errors are listed in the services on either my local machine or on the server which is home to the printers on our network.

It is completely random and only the issue itself can be recreated. It never fails to print the same item on the same sheet more than once. The first time I batch print a set of drawings a part of the first drawing could be missing, the next time all drawings are correct, and a couple times later another drawing will be missing data.

Any ideas would be greatly appreciated as I cannot pass drawings on to a customer which can possibly be missing data. I have already invested money and a great deal of time. PLEASE HELP!!!

[steve.ashton]

Sounds like you've tried the obvious things.

I have a HP 8000DN used with 2002, 2006 & 2007 but never seen similar problems in 4-5 years. I don't normally use publish, I use Simple Batch Processor for batch plotting with scripts.

You say the printer is on a network, have you tried printing from another computer to isolate if it is a computer or printer/network problem.

Checked the autodesk knowledge base and there is a note of problems with large or slow printing files starting to print before all the file is received. They suggest changing the printer properties (Advanced tab) to start printing after the last page is spooled.


Steve

[irneb]

Try printing to something else. I'd sugest print to PDF to check if AutoCAD's creating the problem. If not, then it's the printer / printer driver / windows / network.

Most probably it's the printer / driver - those HP's always use HPGL which is vector based. Now while that's good for keeping network traffic down, it means that the printer it self has to convert those lines to dots. You've mentioned 16MB RAM on the printer - maybe that's still not enough. HP doesn't tell you that it's run out of RAM like other printers do - it simply disregards anything that didn't fit.

If this is the case, then you need to find a method of printing using HP-RTL instead. Some of the drivers have an option to switch to calculate on PC (as opposed to calculate on Printer). It then sends a much larger raster file to the printer - but it prints irrespective of how much RAM you've got in the Printer. If this doesn't work, try the print to PDF method and then print from PDF. If it still doesn't work, try printing to a BMP then to the printer.

A few years back we had an HP DesignJet 750C with 256MB RAM and constantly got this when the drawing became complex. Sending the print through went quickly - then the printer calculates for about half an hour - and spews out only portions of the drawing. Then someone decided to get a cheap EnCAD CadJet 2 (second hand) with a measly 8MB RAM - when using it's raster driver it prints perfectly, and the calculation on PC for that same drawing only takes 10sec - then the print starts immediately.

That said, the company I work for now is slightly larger - we use an Océ Laser Plotter between 60 people. This has it's own PC as a RIP Server (which basically changes those HPGL plot files to the plotter's native Raster language).

[robert.1.hall72202]

That said, the company I work for now is slightly larger - we use an Océ Laser Plotter between 60 people. This has it's own PC as a RIP Server (which basically changes those HPGL plot files to the plotter's native Raster language).

I have a similar setup. Everyone keeps asking me about the computer.
All those engineers and their data!

[irneb]

Yep, they see a PC standing empty with no-one in front of it and ask: "Where's he off to?" ... the answer ... "In the wires!"

[Kevin.Sturmer]

Sounds a lot like what happens when PUBLISHCOLLATE is set to 1 in CAD2008 when not creating a PDF. The entire batch plot job would plot electronically - storing all the sheets until the last one was sent electronically - only then would it be sent to the output plotter/printer. This would clog up some of the plotters resulting in missing information. When PUBLISHCOLLATE is set to 0 each sheet would be sent to the plotter (and start to come out on paper) without delay.

When you send several sheets, do they all wait in for the whole job or start to print sheet by sheet?

[robert.smith3065161104]

I am also having this problem. Trying to batch plot from AutoCAD to a plotter is fine, but when I batch plot to PDF using the Sheet Set Manager, I also get random missing linework. Using AutoCAD 2008 & Acrobat 8 Pro. This has become a big problem. It is not local to my machine, I have tried it on 4 different machines. All running xp pro, DC & Core 2 Duo processors 2.66 & Faster with at least 3GB memory. Totally random dropout. I can post some examples if this would help. I can create multi-page PDF's back to back, on the same machine and get dropouts at different places. Any thoughts? Any help would be greatly appreciated.

[irneb]

For multi-page PDF's the only sure fire way (I've found) is to 1st make a multi page DWF, then print from there to the PDF. For some or other reason AutoCAD just doesn't handle PDFs too well. Sometimes it doesn't print all the linework (especially if using the AutoDesk DWG to PDF driver) other times it shifts the output on the page, and sometimes it doesn't respect the selected page size.

[jim.dozorec]

Hi, All

I have the same problem with an HP LaserJet 5200 PCL 6 printer that has 64 MB of on board system memory which is on a network. I am using Acad 2005. The missing data on the prints is not always the same for the same drawing printed at different times.There is no DIMM installed in the printer. Do you think that I would need to add some more memory?

Regards, Jim

[irneb]

That may be because of HP's problem of disregarding any geometry that don't fit into the printer's RAM. Apart from the AC problem with PDFs AC sends the line data in HPGL format to the printer, which then calculates the actual dots to place on the paper. Now if the printer's RAM is a lot less than the amount of lines - then not all can be placed on a virtual page before the printer starts printing. The random effect is because AC sometimes "sorts" the lines different from the previous plot, therefore you get a different set of lines printed first (throwback from the old pen plotters). You may need to:

Upgrade the DIMMS in your printer to at least 3x larger than the largest HPGL file when printing the same, but save to file. The more RAM the less chance of this happening.
Print to some type of image file first then send that to the printer. The problem with vector based HPGL (or HPGL2) is that the printer has to calulate the entire page before it can start printing. Once it starts printing the top of the page is already on paper, so it's no good trying to place another line there - i.e. it needs to go through all the lines (because they can happen all over the page). When printing from an image, this is already done.
Get a different driver (HPRTL) for the printer which then calculates the dots on the PC and sends the "image" to the printer -= this way option 2 is basically done automatically.