Jump to content
OMRON Forums

Rotary Axis Travel Limits?


Recommended Posts

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?
Link to comment
Share on other sites

  • Replies 3
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
Share on other sites

  • 1 year later...



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?

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...