Jump to content
OMRON Forums

Position Comp for velocity loop


JeffLowe

Recommended Posts

I have a spindle with some encoder eccentricity that is not possible to mechanically adjust out. A compensation table in large measure reduces this error, but there is some residual error remaining because the velocity loop does not use the comp table. I'd like to set up an encoder conversion entry to look at the compensated position from the position loop and use that as a velocity loop feedback entry. Does the Actual Position register at D:$000x8B/0B include the compensation, or will it be necessary to add a second ECT entry for D:$000x90/10 and sum in the compensation position correction before using the combined entries for the velocity feedback source?
Link to comment
Share on other sites

  • Replies 2
  • Created
  • Last Reply

Top Posters In This Topic

No, the actual position register at $8B (etc) does not include the compensation. In Turbo PMAC, compensation corrections are added to the desired position.

 

To make this work, there are a couple of things you need to consider. The first is scaling. You will only be able to combine the correction with the encoder if they are scaled the same, so Ixx08 must be set to 1 for the motor, so the compensation correction register at $90 (etc) is in the same units of 1/32 of a motor count that the result of the processed encoder value is. If Ixx08 is not already set to 1, you will need to change servo gains when you change Ixx08.

 

You will be combining the correction with the result of the converted encoder entry (not the motor actual position) and using the combined value for the velocity loop. Since the compensation correction is added to desired position, you must subtract the value from an actual position value, not add it.

Link to comment
Share on other sites

  • 2 months later...
Jeff, have you actually looked at the difference in the estimated velocity versus the actual velocity (assuming perfect encoder)?. I.e. perfect encoder would estimate velocity as deltaTheta/deltaT and the actual encoder would estimate it as (deltaTheta+errorTheta)/deltaT. It would surprise me that this would make a significant difference unless the encoder was terrible. This is because the error from count to count grows smaller and smaller as the resolution goes up. My hunch is that the effect of time and space quantization of the position signal once put through the difference equation is just as bad as the ripple due to the noise in position. If you have data on this it would be interesting to see.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...