Help - Search - Members - Calendar
Full Version: xmpie_opi_rip_time
Digital Print Forums > Variable Data Printing > Variable Development Tools
jim
Howdy Everyone

We use Xmpie, DocuSP 2.4 ( the big Sun box ) iGEN3.
We have a big project we are working, here is the info.
Xmpie/Indesign on a PC using opi on the DocuSP for static images and layers for vipp in Indesign
There are about 200 layers in Indesign.
This is for about 75.000 records 2 sided pages vipp on both sides printing 12x18 sheet size.
We are rendering dbf files in 500 record batches.
Those 500 record batches are 800MB to 1GB in size.

The issue is it takes about 30 to 45 min to rip a batch on the DocuSP.
We print the batch faster than DocuSP is ripping. We can’t have more than one batch in active jobs until
the file is riped, Then we can allow to put one more batch in active jobs for ripping. If we do put more
than one a better chance of having issues. Ripping slower, locking up or lost files.
We can only put 2 to 3 batches in inactive jobs or the DocuSP will start having the same issues.
The DocuSP will also dump the previous printed dbf file. Nothing in completed jobs.
No a big deal if there are no issues with the printed batch, Or you are trying to keep everything in order.
We all know that never happens. LOL

Disk space on the DocuSP
root 57.47 available used 4.84gb free 52.05 9% used
user data 67gb available used 39.52 free 27.13 58% used
After the DocuSP slows too much or locks up we will do a fsck -y and then restart using
reboot -- -r command this will get us to 50% or lower free user data. And seems to help
in ripping time for a bit. But we are back to 58% after 1 or 2 batches.
We figured about 70+ hours ripping and printing for this project. But at this rate this project may take 100+ hours.

The questions
Just how much desk space will the DocuSP use to rip vipp files of this size,
2,3,4,10x the size of the dbf file?
Anybody have suggestions how to get a project of this size to rip faster than this?
Anyone experience a project of this size?
Are these normal ripping times for a project of this size?

Any help or comments will be appreciated.
Thank You
Igen Jim
sad.gif
rugby148
wow, that has got to be frustrating. i must really not understand xmpie's implementation of vipp. having coded vipp by hand this seems ridiculous. if i were coding this by hand i would load all of my resources on the rip (each of my images). I would cache the most appropriate images as i use them. i would only submit a data file per batch. i have never experienced properly coded vipp ripping more slowly than print, even with large designs with numerous images / resources.

what are the output options from xmpie?

additionally, i would validate that all my images are properly sized and the resolutions are appropriate. you might find that a single resource (or small handful) are through your size out of whack.
dgould78
If you are using projects with your VIPP the below might help.

When I am creating VIPP files from XMPie under the Advanced tab in the Dynamic Print dialog I always turn off Assets and Resources. Then I make sure extract reusable content is checked and then I give it a project name instead of the default. When naming the project make sure it is at least eight characters long. I have had problems with XMPie renaming the projects when they are shorter.

After this is done you can copy all of the files created to a projects folder on the DocuSP with the name you gave it in the Advanced tab of XMPie. Also copy any art that you have linked in the InDesign file to the same location. By doing this you should not have to use OPI and it should be faster.

I don't do files with so many layers buit with in them, but I do create multiup postcard files using a few layers with about 8000 names to a group and they seem to run fine. I had the same problems until I figured this out. Usally I let XMPie also figure out the step and repeat for the sheet size I am running.

Hope this helps.
jbeck101
Here are a few helpful tips.

Set your queue to run images at 1/2 resolution. This will be found at the Queue level under PDL settings. The only time this will cause problems is when text is layered on a raster image. DocuSP must rasterize the text forcing in to become jagged because of the half resolution. You will seldom see any problems with images. This will make a dramatic difference in RIP time!

We recently had two compression boards that were not being recoganized by DocuSP. You would think that the machine would not boot properly, but it does. When your tech ar analysist is out have them check all are working.

Lastly make sure that you do not have any transparency layers in your InDesign file. DocuSP cannot cashe the transparency and will cause your file size and RIP time to explode.

Hope this is helpful.
joramal
if you are using imposition and are using xmpie cropmarks
try to make the cropmarks in the masterfile (dont let xmpie generate them)
and see if you get a faster ripping time.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2012 Invision Power Services, Inc.