Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rotary Axis Travel Limits?
#1
In the Turbo PMAC for a high resolution rotary position axis operated in continuous motion, there are travel limits when using special lookahead would cause discontinuities in the rotary velocity due to apparent changes in velocity due to loss of LSB resolution in the floating point calculations. This occurred long before the reaching rollover of the binary position register. Does the Power PMAC have any similar issues?
Reply
#2
Floating-point representations, with fixed mantissa width, inherently lose resolution when the magnitude gets larger.

To illustrate with the decimal equivalent (that we call scientific notation):

1.234567 E0 has a resolution of one millionth of a unit, but 1.234567 E4 has a resolution of one hundredth of a unit.

Power PMAC uses 64-bit floating-point representations, with a 53-bit (52 + 1 implied) mantissa. The older Turbo PMAC uses 48-bit representations, with a 36-bit mantissa.

The additional 17 bits of the Power PMAC representation provide resolution 2^17 (131,072) times greater than the Turbo PMAC for any value. So you can go over 100,000 times further in Power PMAC before you reach the same issues. I don't think anyone has come close to noticing any issues like this in Power PMAC.
Reply
#3
Curt,

On a separate, but related issue. I am trying to figure out if I am working inside an edge case or if I need to look elsewhere with regards to a CK3E ethercat master device.

Setup: CK3E -> Copley BEL -> Rotary stage with 8419.5555555... cts/deg

In CSP Mode, everything seems to work generally 'fine' above the int32 limit of the target position PDO getting through several rollovers, but gets faults around 20 billion counts (~2.4M degrees).

I am assuming that in a buffer, the gcode target position in text form gets converted to a 64-bit float, multiplied by the target unit conversion, then cast into int32 to put in the PDO for the discrete encoder count target; with regard to rollover the Copley seems to auto-magically handle that without any issues. Is that correct or is the math sequence a little different?
Reply
#4
David:

You've got the sequence of calculations in the CK3E correct. The 32-bit rollover in the output of CSP mode is widely used successfully.

I do not know any of the details of how the Copley drive handles these values.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)