RIP only rips one of three color plates

Started by jculler, June 18, 2008, 06:18:34 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jculler

 Hey it's me again.
 
 I'm having a puzzling problem with our Torrent RIP.

 Our editorial system sends a CMYK composite ps file to our
 output system which then multiplexes the job to one
 of four rips.

 The problem is the RIP sometimes only rips the first plate
 Cyan and sends it to our Imager and just goes on to the next job
 as if nothing was wrong. No errors in the log. There no
 pattern I can tell that would lead to the cause.

 The weird thing is that I can resubmit the same ps job to same
 RIP and it rips all three color plates.

 I can not track it down to any one RIP.

 We use a network protocol called OrbitLink to do our multiplexing.

 Does this sound like a RIP issue ?
 Where abouts would I look if it is a RIP issue.

 thanks
 

tapdn

How big are those PS files? Sounds like maybe a memory issue to me.
usually fried mate - sometimes pickled - often scrambled - never beaten
~ Sir B. Monsteaure
No, he's well within his rights to diss cake. Pie, on the other hand, is waaaayyyy off limits.
~Youston
I'm just a stupid printer WTF do I know
~Farabomb

jculler


   Memory could the issue.


    But as I mentioned we are using a TCP protocol call OrbitLink on
    our RIPs, Outmanger and Imagers. It's job is to coordinate the multiplexing
    of jobs.

   It looks like when two composite pages are being sent to the same Imager
   from two different RIPs one page is imaged and one put on hold.

   The one that is paused, until the first page is finished  imaging is the page
   that only outputs one of the three plates..
 
    Has anyone heard of or use this Orbitlink ?

Ear

No experience with Orbitlink but back in the days of film, my Harlequin would do that from time to time. Upping the Memory, as Tap noted, seemed to help. RAM is cheap in the scheme of things, I would max it out!
"... profile says he's a seven-foot tall ex-basketball pro, Hindu guru drag queen alien." ~Jet Black

hagar_uk

Quote from: jculler on June 18, 2008, 06:18:34 PMHey it's me again.
 
 I'm having a puzzling problem with our Torrent RIP.

 Our editorial system sends a CMYK composite ps file to our
 output system which then multiplexes the job to one
 of four rips.

 The problem is the RIP sometimes only rips the first plate
 Cyan and sends it to our Imager and just goes on to the next job
 as if nothing was wrong. No errors in the log. There no
 pattern I can tell that would lead to the cause.

 The weird thing is that I can resubmit the same ps job to same
 RIP and it rips all three color plates.

 I can not track it down to any one RIP.

 We use a network protocol called OrbitLink to do our multiplexing.

 Does this sound like a RIP issue ?
 Where abouts would I look if it is a RIP issue.

 thanks
 

It sounds very odd, if the problem can not be created when sending manually it would lead to front end system IMHO. The reason I say this is if the RIP was the issue  you would expect to see some hint in the logs.

When you say no plates are produced can you tell from the logs what happens? ie do you see at what stage the issue happens? Does it fail in interpretation or in output? You don't say what device your driving, but guessing it might be TIFF? If so could it be that the TIFF catcher is causing issues? The tiff plugin does not put jobs as TIFF but outputs to either a .TMP, OOT, OOT1 (depending on version) and then renames once complete.  Some TIFF catcher might have a short stabilzer time and seeing this odd file try to process and fail.

Otherwise it may worth trying to flush the cache via a pagefeature for each job