Print Shop Mail & Ricoh C900

[fourpaula]

I use Print Shop Mail a lot with my C900 & I am having an unbelieveably slow rip time. I have a file that is 1400 sheets 13X19 sheets or 4200 postcards. If I send the file all together it locks up the Fiery attached to my C900. I had to send the job in 5 batches to allow it to process. Each batch took 45 minutes to an hour just to process. The printer actually printed batches faster than it processed them. This happens with all the VDP jobs we process. We also use Direct Smile which doubles the processing time. I have a few jobs that are 10K pieces which I know will take more than a day at that rate.
Anyone know a way to speedup processing?

 

[impression]

Check to make sure you have VDP Technology set to Optimized Postscript and not standard.

 

[fourpaula]

It is set to Optimized. Getting is from print shop mail to the printer normally doesn't take that much time. Ocassionally it will take some time. It is when the Fiery on my C900 rips the file normally.

 

[FlikP]

Simple swap your Fiery RIP for a Creo C80 controller as this RIP is designed for Variable Data work using both VPS/PPML/OPS/OPDF etc and there loads of case studies out there!

It not only works great with VDP but the overall colour stabbility and speed is very impressive - go and kick Ricoh and mention its not fit for purpose.

 

[Bo3b]

Would have to agree that the Creo rips handle VDP jobs better than any other rip on the market - for any printer supplier!
However I am surprised that the Fiery is taking so long on these jobs. Perhaps it has something to do with the way the VDP jobs are being created? I'm more familiar with PSMail for the Mac than for PC - shame that Objective Lune seem to have abandoned the Mac version - PSMail was a Mac program long before it ever appeared on a PC when Atlas were making it.
Some things to remember…
If you have any variable text, try to get it in as small a text box as you can. If you put variable text in a big text block then the whole text block becomes variable so cacheing won't help ripping performnace.
In PS mail if you can set the background colour of any element to white instead of the default transparent, then the program doesn't have to workout if any object are to be visible or not - obviously you can only do this if the background to these objects is white.
Make sure you check any/every option that mentions using the rips cacheing ability - I've seen even properly designed jobs (on a Creo no less)
take 3-4 hours to rip around 300 records with cacheing not enabled - turning on cacheing and the entire 20,000 record job ripped within 10 minutes

I'm fairly certain that the later Fiery rips handle VPS as well as PPML, both of which should give better ripping performance than optimised PostScript. I don't think their VPS implementation is as good as Creos however - VPS is a Creo invention after all

 

[FlikP]

Bob,

Agree with your comments however dont forget that EFI reverse engineered VPS support for their RIPS!!

 

[MIBUK]

Have you tried sending the file as PPML, which the Fiery supports? Also, the Fiery has something called Freeform where the static form is held on the Fiery...which means only the variable data is sent. This is supported by PrintShop Mail.

Try the above options to see what results you get

 

[FlikP]

EFI is an office RIP and not a 'true' production RIP - you will stuggle with PPML too even though its supported.

 

[fourpaula]

This card had a 300 resolution PDF for the front & back with a 3X1 text box & a .75X.25 text box. The 2 boxes did have transparent backgrounds. Making the background white made no difference at all. Cache didn't seem to make a difference either. I'm working on the free form still. I'm not as familiar with that feature.
I looked at the memory in my Fiery & is has 512MG I thought that was pretty low for a computer that processes graphics. My Ikon tech told me that we can't put more memory in it because the program will not recognize it. Could anyone with this machine tell me how much memory they have?

 

[JayDA]

EFI is an office RIP and not a 'true' production RIP - you will stuggle with PPML too even though its supported.

I call BS, please provide something to substantiate this. I run 5 color machines, every one of them with a Fiery, and I put VDP work through them all day without any problems. Someone asks for help with their Fiery, and your answer is "buy a Creo"...really?

OP, email or PM me, we use PrintShopMail and PlanetPress to do VDP runs all day...I would be happy to help if I can.

 

[Happyprinter]

We to run VDP thru our Fiery almost everyday to our 901. No problems at all.

 

[Shaja]

I work for an independent Konica Minolta dealer and we sell and support PrintShop Mail to clients in our territory. I've actively used PrintShop Mail as part of my job for 8 years. We used to be a Ricoh dealer at one time, so I've run my own PSM jobs on a good variety of machines from both manufacturers.

My go-to work-around for slow ripping was taught to me by an Atlas PrintShop Mail technician many years ago (pre Atlas/Objectif Lune merger). He told me to print the job as a pdf, then send the pdf to the printer. Granted, that defeats PSM's minimizing network traffic feature, but his tip reliably works for me.

You also may want to visit Objectif Lune's PrintShop Mail forum and post your question there. OL staff are pretty good about answering questions promptly, and they can help if you need to open a support ticket. Objectif Lune Tech Support Self Help - Forums powered by UBB.threads™

 

[Digital Press Guy]

Paula, I think you may be confusing RIP speed with merge speed.

Any VDP application needs to first merge all records before they can be ripped. Objectif Lune products have never been known for being overly speedy in the merge department.

Certainly you can optimize the data stream sent to the RIP to speed the RIP process. However, without a VDP job being first completely processed there is no way to insure there are no data errors.

As for running high volume of Direct Smile files, good luck with that. If you don't have a huge number of variables you might want to simply consider generating the different images, saving and calling them as variable graphics.

Good luck.

 

[msaeger]

Do you know if your Fiery is up to date on system software and all the patches?

 

[msaeger]

Here are the specs for the standard Fiery for the c900.

Fiery System Version Fiery System 8 Release 2
CPU Intel Core 2 Duo 2.16GHz
Memory 2GB(1GBx2)
HDD 500GB (250GB x 2/ RAID 0)
CD-ROM Drive Not Supported
Operating System Windows XP

Where are you seeing how much RAM you have?

 

[fourpaula]

Interesting. If I look under "My Computer" on the fiery it says 2GB BUT if I look within the software (Command Workstation 5) it says 512mg. I was told that if the system had more memory it wouldn't recognize it anyway.
We went through 4 months of craziness with updates both software & hardware when we first got our C900. Last patch was done about 6 months ago.
I spoke with Print Shop Mail about the sending it to the printer issue. It was suggested that I try making the file into a PDF first & try to reduce the image size. A 2500 page PDf doesn't seem practical but I'll have to test it. I was also informed that I'll have to use good "Time Management". The most irritating part is being unable to do anything else with my computer while it is sending these jobs over to the printer. Even opening outlook while PSM is sending jobs to the printer crashes my computer.
My computer more than beat the minimum requirements for the software.
So basically we are dealing with 2 issues that may or may not be related.
#1 going from computer to printer
#2 RIP at the printer.

 

[msaeger]

Yeah I don't know what portion of the memory is used for what just that it comes with a total of 2 GB. I would guess adding more would screw up something.

If you print out the Fiery config page it should have 4.0 for the system software version and list a bunch of patches.

Maybe someone on the official EFI forum could help. http://fieryforums.efi.com/

 

[Bo3b]

from memory the fierys usually partition ram for the system and for the rip. Usually it;s the rip that gets the extra ram.
I am going back a bit so this might not apply to the newer rips, but on the C: partition (I think) there used to be a boot.ini file which had a setting in it called maxram. This was the amount of memory that the OS would use - put as much ram in the system as you want and the system would not use any more ram than the maxram setting.
What I used to do was add more ram and double the maxram setting (used to be 256, changed to 512) this would give the os more ram and the rip more ram. usually helped the performance but only up to a point. It got a point where adding more ram made no difference to the performance of the rip or os.
Faster hard drives would probably help as the fierys rip to memory - compress - save to hard disk - then read from hard disk - decompress to ram then print from ram. so the faster you can get the data to/from the hard drive and the faster you can compress/decompress (remembering that with more memory there is less compression needed) then the better the performance. Obviously a faster processor would also help.

The boot.ini tip only works for rips that are running windows - the bustled fiery rips run a form of Linux so things are obviously different.