Polaris pixel shift problem

[VladCanada]

What type of interface card you use? PelBox? PixelBurst? Agfa UPAC?

[28-yr-AGFA-SE]

If you are correct about laser direction in Sample_A.jpg, then there is a data shift causing the pixel shifting on the plate. Therefore, it is unlikely that all 3 NewsDrives and all 3 Polaris' have the same problem. Are you using a single RIP and sending it's output to the 3 NewsDrives? If this is the case, and the RIP's preview does not show any problem, then there is an output problem with the RIP or a communication problem between the RIP and the NewsDrives.

[28-yr-AGFA-SE]

If you are incorrect as to laser direction in sample_A, and it is instead rotated by 90 degrees, then Vlad is probably correct. Sample_AA seems to show a large shift of image that is directly lined up on the plate. There is an alignment issue with the spin optics in this case. You will need an SE to correctly align.

[28-yr-AGFA-SE]

If you are correct about laser direction in Sample_A.jpg, then there is a data shift causing the pixel shifting on the plate. Therefore, it is unlikely that all 3 NewsDrives and all 3 Polaris' have the same problem. Are you using a single RIP and sending it's output to the 3 NewsDrives? If this is the case, and the RIP's preview does not show any problem, then there is an output problem with the RIP or a communication problem between the RIP and the NewsDrives.

[adatsui]

may be i mislead about laser direction . please check attach picture.

we've 3 workstation , there is 1 rip + 1 NewsDrive on each workstation.

As we working on 1 bit tiff. one rip for diffent NewsDrive don't work for us , we need to transfer dot size to get a accurate dot on the plate.


each time we have pixel-shirt , we check 1 bit tiff produce by our rip. may be next time we also check NewsDrive's Export data , NewsDrive save output image here. I hope it never happan again


> What type of interface card you use? PelBox? PixelBurst? Agfa UPAC?
don't know.

_sample_A_dir.jpg

[28-yr-AGFA-SE]

From your _sample_A_dir.jpg above the laser is really scanning vertically and the Polaris moves the plate horizontally. That means the "pixel offset" that you are seeing is in the direction of the spin optics rotation. From sample_AA above, I see that there is a corresponding clear area in the blue (ink) area where the laser is being offset causing the pixel shift. Doesn't always seem to be the case in sample_B and sample_BB. Suspect that you have 3 machines with similar, but not exactly the same, problem. As STSTech said above, there is possibly a single solution to all 3 problems. Must check anything that is common to all 3 units. This could also include temperature, humidity, AC power, etc. Less common cause could even be where the machines (Polaris') are located. They are supposed to be on a concrete floor rated at a minimum of 100 pounds per square inch. If they are on a lesser rated floor, then someone walking across the floor could, conceivably, cause physical shifts that would cause this type of error. Look really closely at all shared things between the machines and make sure that they are really having EXACTLY the same problem.

[maxon]

I agree with the above but I believe it must be electrical. It appears one single scanline is shifted at a time, we don't know if it contains the correct pixel data or is it garbage, the spinner itself seems stable there's no jitter or instability. VladCanada mentioned something interesting about the piezo facet correction but how can it happen on all three machines. In my humble opinion they have to look for single events, transients. Adatsui, collect several bad plates produced by each of your ctp's and compare them carefully, does the problem look exactly the same on all as 28-yr said ? Do your machines have proper grounding ? do you experience any power surges or brownouts ? Can you associate the bad plate exposure with starts/stops of offset machines, is there anything significant happening in the environment in the same time with pixel displacement ?

[Slammer]

If I remember correctly there was a issue with some older RIP's with the image size. It had to be dividable by eight, otherwise you got a pixel carry-over (Pixelübertrag?)