Lotem 800 issue

[G_Town]

I'm posting this for a friend, it appears that when imaging the one bit's it gets about an inch then starts repeating a portion of the inch just imaged over the rest off the plate.

It doesnt do it on every job (right now it appears to be doing it on layouts that are mainly CT data.

They are creating the 1 bits in Nexus and dropping them on a brisque that is driving the Lotem, sounds like some type of data underrun or transfer issue.

Anyway I looking for any ideas you can fling on the wall so he can try them (they don't have a support contract so Kodak aint breaking any speed records to help them).

So far the only thing he tried was turning off the compression on the 1 -bits, didn't help.

Thanks

[Joe]

Do the one-bit tiffs look okay when viewed? (They can be opened in Photoshop...takes awhile though)

If they look okay you can eliminate the Nexus part of it.

[G_Town]

Yea he said they looked fine.

Sounds like a communication error to me but not being there its hard to tell him what to try.

[David]

I'm assuming you have rebooted the Brisque??  (This can take awhile, big slow clunks, that they are
Reboot the Lotem as well.

[G_Town]

Yup already did.

[David]

check the queue and see if it's still on line?

[G_Town]

Yes it is as he can still plate some jobs fine.

[David]

so, is it just the one job that's coming over corrupted?

what's the difference with the ones that work and the ones that don't?
any special treatments, like high line screening or a lot of extremely high res images?



we've found on ours, that if we have a lot of higher res images (like 20 or 30 at res 50 or so), it will not RIP in correctly, like it times out and quits writing the file.

[G_Town]

Well I used to work there and the job he is refering to is mainly hi res images, the jobs that have more tints/vector art seem to work without issues.

[David]

have him check to see if some of the images are super hi-res.
Like if they were 300 ppi and placed at 10%, the effective output res is now jacked up to 3000 ppi (per image). So if you have say 10 of these guys, your imposition file would be around 30,000 ppi. This may take awhile to cross the network and then if it starts to RIP before it's finished writing, it will corrupt the file. And that is maybe what he's seeing at the setter.

[G_Town]

Right but he is driving the 800 with 1 bit tiffs @ 2540 so I'm not sure that is the issue + they do all of thier scanning internally and all images are at res 14.

Maybe I'll tell him to drop the res to 2400 and see if that makes a diff.

Update:

Nope they already tried that and still didn't work.

[David]

not sure, but it may be an issue with Brisque and an intermittent connection problem with the Lotem.

does this happen during a heavy workload or just whenever it wants too?

[G_Town]

They are telling me it happens on a certain line that uses a lot of images on the job, like 80% to 90% of the press form.

Other jobs that are working use like maybe 40% image coverage, now why it makes a difference (a tiffs a tiff right) I don't know. Or if like your saying the physical size of the file may be the issue?

Kodaks solution is to have them d/l updates for the brisque but they have been running like this for a year and a half which leads me to believe its some type of connectiviy problem, communication board or a scsi connection.

It's a stumper.

[David]

the difference in coverage (more versus less) could be the file with more coverage is not finished writing before the RIp starts.
Do they have these going to some sort of hot folder or are they manually released to the setter?

[G_Town]

To my knowledge they are just using the brisque as a tiff catcher. The tiff is generated out of nexus then dropped on the brisque to image. I'm guessing its set to image as soon as the file hits the folder.