WildPointer

If you are at 95 rpm this would equate to 95 rpm / 60 seconds * 360 Degrees / 1000 ms/sec = 0.57 Degrees /Millisecond. Therefore a 10 degree error is 17 ms of lag. I believe that your encoder signal will only update at your "coarse update rate". You might want to look at this. ( Property Of Motion Group ) Also have you checked the RPI of your output card. ( Property of your output card ) Just a couple suggestions.

I guess I'm a little confused with the Coarse Updates/Trajectories. The Coarse Update Period is defined as: Selects the periodic rate at which the motion task executes to compute the servo commanded position, velocity, and accelerations to be sent to the 1756-M02AE or 1756-M08SE modules when executing motion instructions. So my take on it was that it is the rate at which we exchange data/instructions/trajectories between the PLC CPU and the Motion CPU. Once a "Persistent " or "Continuous " Cam is loaded into the motion CPU is it not now independent of the PLC CPU ? Does not the motion CPU update to the drive now at a very high rate much quicker than the Coarse Update Period ? I thought that all the trajectory information would be held internally on the motion CPU after executing the Cam instruction once.

Try moving a 3 into the ST15:0.LEN at the same time you are moving the integer values in to ST15:1.DATA[0-2] and see if this helps.

Donovanr...... her is a CompactLogix/Kinetic PLC program that demonstrates a flying cutter application as another option. This project ran 400mm + long Punch_Cutter.ACDparts ( Part length set on MMI ) at 30 meters/min.... roughly a part every 1/2 second. Make sure to open the graphic camming curve on the MAPC instruction. Good Luck hey !

Donovanr.... don't discount a pure Contollogix/Motion Card/Kinetix Drive solution. It's really a simple application with the external encoder wired to the Kinetix drive auxiliary input and a MAPC instruction cued up in the motion controller waiting to execute based on position.