New rotary modulo axis feedback and testers wanted

  • grandixximo
  • grandixximo's Avatar Topic Author
  • Away
  • Elite Member
  • Elite Member
More
30 Apr 2026 13:17 - 30 Apr 2026 13:22 #346054 by grandixximo
Hi all. I have an open PR (#3969) that adds a new rotary axis behavior and would like input from people who actually use rotary axes. The problem it tackles is the long unwind: after a job that accumulates rotation, a simple G0 A0 takes minutes spinning back to zero. Related, CAM output of G1 A45 from A350 normally does the long way 305 degrees instead of the short 55, unless you use sign convention everywhere. WRAPPED_ROTARY exists but uses the input sign as direction, rejects values outside plus or minus 360, and does not wrap the DRO or 5423 to 5425 parameters, which some users find awkward.

The PR adds an INI flag, AXIS_x ROTARY_MODULO equals 1, mutually exclusive with WRAPPED_ROTARY. With it enabled the default mode is M26, where every absolute rotary move takes the shortest path. G0 A0 from any accumulated value goes the short way, no long unwind. There is also M27 which uses the sign of the input to pick direction and modulos values above 360. So A45 goes forward, A-45 backward, A720 becomes A0. DRO and 5423 to 5425 are wrapped to 0 up to 360. Internal motion-side position stays accumulated so stepgens, encoders and PID see no discontinuity. Multi-turn winding is done with G91 incremental, same idiom as Heidenhain IA+, Siemens, and Fanuc G91.

If you use rotary on commercial controls this should feel familiar. M26 default matches Fanuc rot_type 2 and Heidenhain M126 and Siemens DC. M27 matches Fanuc rot_type 1 and Heidenhain M127 default and Siemens ACP/ACN. The axis flag itself is the LinuxCNC equivalent of Fanuc parameter 1008 ROAx, Heidenhain shortestDistance, Siemens MODULO axis config.

What I want to hear: does this behavior fit how your CAM emits G-code, would M26 default plus plain absolute output Just Work for you or would you need M27 sections, are there kinematic configs (coupled 5-axis TCP, gantry rotary, weird mappings) where you think this would behave badly, and do you have test G-code you would like me to run through it before merge.

PR is at github.com/LinuxCNC/linuxcnc/pull/3969, original issue github.com/LinuxCNC/linuxcnc/issues/3902. Branch grandixximo/linuxcnc:rotary-modulo, builds clean against master. Happy to iterate on design if there are cases I am not covering. Thanks.
Last edit: 30 Apr 2026 13:22 by grandixximo.

Please Log in or Create an account to join the conversation.

Time to create page: 0.064 seconds
Powered by Kunena Forum