Variable Data stalls on Fiery

[Bill Ward]

We are running a Canon ImagePress C8000VP with Fiery Command 6. We run quite a few variable data jobs with Print Shop Mail 6.1
We've never had a problem sending over variable data to print even with as many as 20,000 addresses - but for some reason, fairly recently, we have problems printing more than three or four thousand entries. Any more than that and the Fiery will stall. It processes the data all the way up to 99% and even prints about 100 sheets (give or take) but then it just sits there. We haven't changed anything in our workflow. It slows us down breaking up 30,000 entries into smaller batches and we find ourselves even having to restart the Fiery between runs. It's a pain.
Any ideas?

 

[donnied]

Honestly, the best answer is a complete reload of the Fiery. You can try running diagnostics, and checking for space on the drives, but all of that just leads to a reload anyway.

 

[Shawnd]

Is this on an ES83 or ES86?

 

[dugdoc]

Could it be that more RAM (memory) is required for the extended amount of data?

 

[Bill Ward]

Could it be that more RAM (memory) is required for the extended amount of data?

That will likely be our next step. Thank you. The confusion for us was that it dropped the ability to handle more records almost overnight, instead of gradually. From 30,000+ down to less than 5,000 all of a sudden.

 

[msaeger]

That will likely be our next step. Thank you. The confusion for us was that it dropped the ability to handle more records almost overnight, instead of gradually. From 30,000+ down to less than 5,000 all of a sudden.

Maybe a patch was automatically installed? You should be able to see the patch history under system updates.

 

[cqb1988]

we are using printshop mail 7, had some problems sometimes. usually, only happen to certain files. Did you send vdp file format as optimized postscript or fiery pplm. whenever I had this problem, i send file format as creo VPS. usually would work. or save the background file as jpeg if quality is not concerned, this would work 100%, but longer processing time.

 

[BurtSherry]

We are running a Canon ImagePress C8000VP with Fiery Command 6. We run quite a few variable data jobs with Print Shop Mail 6.1
We've never had a problem sending over variable data to print even with as many as 20,000 addresses - but for some reason, fairly recently, we have problems printing more than three or four thousand entries. Any more than that and the Fiery will stall. It processes the data all the way up to 99% and even prints about 100 sheets (give or take) but then it just sits there. We haven't changed anything in our workflow. It slows us down breaking up 30,000 entries into smaller batches and we find ourselves even having to restart the Fiery between runs. It's a pain.
Any ideas?

Bill, we are also running a ImagePress C8000VP with Command Workstation 6, but I am using Print Shop Mail 7.2.4.
I have been having the same issue for the past two years or so.
Do your "trays" disappear from Command Workstation when your Fiery "stalls"?
When our ImagePress was new, I never had this problem. My technicians kinda laugh at me when I mention this problem, like its really not a problem, just deal with it.
My current fix, is to reboot the Fiery and start wherever the job left off printing again.
I do have some jobs that I do weekly, that always "fail". What I do with the one is print in groups of 10 and it usually works fine. Only problem is, this is a "1up" job so its not a big deal.
I have also "chunked" into groups of 4000 records, I print to file in groups of 4000 records, distill and then drop them into Command Workstation. 6x9 postcard 4up, and without a stacker, it switches from the bottom output tray to the top tray, at this point I empty the bottom tray, and then when the first 4000 finishes, it goes back to the bottom tray. Keeps everything in order if you can keep up with emptying the trays, considering your not running around like a chicken with your read cut off like I am most of the time. Only problem with this is cutting the job and keeping it in order. If you do the 4000 records and then the next 4000 records, its not a problem.
As far as a actual fix, I have 0 idea, and like I said, my tech's laugh at me indicating this really should not be a problem, just break the job up.
I print most things optimized post script, some Fiery Free Form 2, but it doesn't seam to make a difference.
One of the most frustrating things for us is, we paid more the big Fiery server, B5000.
I wish you all the best resolving this problem. Over two years and I have not got anywhere!
If you do figure it out, please share.

 

[Bill Ward]

we are using printshop mail 7, had some problems sometimes. usually, only happen to certain files. Did you send vdp file format as optimized postscript or fiery pplm. whenever I had this problem, i send file format as creo VPS. usually would work. or save the background file as jpeg if quality is not concerned, this would work 100%, but longer processing time.

We send as optimized postscript. ppml won't work for us for some reason. Sending as ppml creates a .zip file (apparently) but then we can't locate the .zip file to import it into Fiery Command. It's confusing. We may have to move up to PSM 7 or PSM Connect and see if that helps. (Although, I hear our old files won't migrate to a newer version)

 

[Bill Ward]

Bill, we are also running a ImagePress C8000VP with Command Workstation 6, but I am using Print Shop Mail 7.2.4.
I have been having the same issue for the past two years or so.
Do your "trays" disappear from Command Workstation when your Fiery "stalls"?
When our ImagePress was new, I never had this problem. My technicians kinda laugh at me when I mention this problem, like its really not a problem, just deal with it.
My current fix, is to reboot the Fiery and start wherever the job left off printing again.
I do have some jobs that I do weekly, that always "fail". What I do with the one is print in groups of 10 and it usually works fine. Only problem is, this is a "1up" job so its not a big deal.
I have also "chunked" into groups of 4000 records, I print to file in groups of 4000 records, distill and then drop them into Command Workstation. 6x9 postcard 4up, and without a stacker, it switches from the bottom output tray to the top tray, at this point I empty the bottom tray, and then when the first 4000 finishes, it goes back to the bottom tray. Keeps everything in order if you can keep up with emptying the trays, considering your not running around like a chicken with your read cut off like I am most of the time. Only problem with this is cutting the job and keeping it in order. If you do the 4000 records and then the next 4000 records, its not a problem.
As far as a actual fix, I have 0 idea, and like I said, my tech's laugh at me indicating this really should not be a problem, just break the job up.
I print most things optimized post script, some Fiery Free Form 2, but it doesn't seam to make a difference.
One of the most frustrating things for us is, we paid more the big Fiery server, B5000.
I wish you all the best resolving this problem. Over two years and I have not got anywhere!
If you do figure it out, please share.

Thanks for the info. Our trays do not disappear (although I could see the ImagePress doing something like that, lol). Our techs have been chasing this problem for us as well to no avail. Adding more RAM seems like their best fix but of course, there's no guarantee that will fix it. I think our frustration is that it happened so quickly. One week we were running 30,000+ records and then the next week the machine was stalling out. We have to split up the jobs into smaller runs now and reboot as well which probably doubles the production time. Could be one of those things where you never get back to "like new" performance.

 

[donnied]

Thanks for the info. Our trays do not disappear (although I could see the ImagePress doing something like that, lol). Our techs have been chasing this problem for us as well to no avail. Adding more RAM seems like their best fix but of course, there's no guarantee that will fix it. I think our frustration is that it happened so quickly. One week we were running 30,000+ records and then the next week the machine was stalling out. We have to split up the jobs into smaller runs now and reboot as well which probably doubles the production time. Could be one of those things where you never get back to "like new" performance.

Have the techs tried to do a fresh install? Often with Fiery's the accumulated errors end up corrupting the system. Of course you can't overlook hardware failures, like a hard drive failing or a CPU overheating. But the first step is a reload.

 

[Bill Ward]

Have the techs tried to do a fresh install? Often with Fiery's the accumulated errors end up corrupting the system. Of course you can't overlook hardware failures, like a hard drive failing or a CPU overheating. But the first step is a reload.

We're considering an upgrade to Print Shop Mail since converting to ppml doesn't see to be supported in PSM6.1 although another user here has a similar issue and they are running 7.2.4
We might consider a Fiery re-install although there is disagreement among our staff as to whether that will make a difference. (It could provide a temporary solution. I am voting for a Fiery re-install)
Our techs don't think adding more RAM will solve the problem.

 

[Shawnd]

Are you monitoring the memory usage in taskmgr?

 

[donnied]

If nothing changed in the file type or size, and it happens with similar files, then it can't be a lack of RAM or other hardware, because that didn't change (unless you removed some RAM!).

 

[Craig]

That will likely be our next step. Thank you. The confusion for us was that it dropped the ability to handle more records almost overnight, instead of gradually. From 30,000+ down to less than 5,000 all of a sudden.

The last time I bought RAM for a Fiery you have to buy proprietary RAM or it doesn't work. Very expensive.

 

[Bill Ward]

If nothing changed in the file type or size, and it happens with similar files, then it can't be a lack of RAM or other hardware, because that didn't change (unless you removed some RAM!).

If it's not RAM then why does a restart of the Fiery help the issue? (even though it's only temporary)

 

[Bill Ward]

The last time I bought RAM for a Fiery you have to buy proprietary RAM or it doesn't work. Very expensive.

Yeah, we got the specs for the RAM from Canon. There is disagreement form Canon about whether adding more RAM will help but we're going that route for now. We'll see.

 

[bill kahny]

I assume you or the techs tried a clear server within the fiery? If the loss seemed to occur "over night" I would check for updates and patches that may have occurred at that time. Look at the workstations where the files are being created also because default save to or export settings may have been changed and not noticed. As a test reprint a job you know worked correctly if it gets past your 100 or so sheets it would rule out machine problem and it becomes a file issue.

Let us know

 

[Craig]

Go to a windows explorer screen (The file folder icon) and type %temp% in the search bar. Everything that shows up delete. Those are temp files that need removed. Next, look at the partition size EFI gives you. Almost nothing compared on your working side that needs space for ripping a job. Completely lopsided. Have your software output a different file other than pdf, like ppml. It will rip 10 times faster. Just check a single sheet before you print the entire job. When we were using Fusion Pro we had issues with transparency and ppml. Also if using pdf make sure it is pdf\vt they tend to rip faster..... Sometimes!

 

[Craig]

One more thing. If you are doing a lot of variable data, consider staying away from Fusion Pro. It has some nice features but is SLOW when composing the output files. Look at PSL Page Builder, it takes some time to get used to but runs circles around Marcoms products. We have a 100,000 record job we regularly print that took hours to compose on Fusion Pro that literally took 12 minutes with PSL.