New rotary modulo axis feedback and testers wanted

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.

As the originator of this request, I've left my feedback in detail elsewhere, but let me summarize my request for this thread: After an hour or more of spiral carving with Fusion's linuxcnc postprocessor, I end up around A556200 (for example), then Fusion does G0 A0 to "reset" the rotary for the next op.  That takes many minutes of high speed spinning, and is totally unneeded.  I would like to skip this massive unwind.  This is a common complaint online, and the usual response is to use G10 to change the WCS offset before the G0 A0 but that has its own drawbacks.  Doing something similar in the G0 itself would be much more consistent across the machine's operation.  Yes, WRAPPED_ROTARY, but there are times when you don't want to use that.

tommylight wrote:

Did you try unhoming and then homing the A axis?

 

Tommy - 

Re-homing a 4th axis means losing the work offset for that axis, even if its really close.  Unless you've got an accurate high-resolution encoder directly on the rotary axis (not just the driving motor), there's always a bit of 'ish' until you indicate the rotary axis in.

I've got a moderate resolution encoder on my servo, the 4th homes to index, and it's using a name-brand zero-backlash harmonic reducer... but it's rarely perfect. The only way to get (mostly) perfect is to home then indicate the axis and set the A-axis work offset... and not shut the machine off or re-home the axis.

None of that matters if all you're doing is OP1 parts, but if you're doing OP2 (or later) parts and previous features have to line up with new ones, a dead-nuts A0 matters.

Fusion's LCNC standard post doesn't have a section for rotary-related M-codes, other than undefined clamp/unclamp.  Nor does it output incremental moves - appears everything is in G90.  So any rotary axis motion which requires switching between G90/91 won't be able to take advantage of ROTARY_MODULO = 1 without post modifications.

I looked at a few other Fanuc-based Fusion posts and none of them (including integrator specific posts) appear to have any M-codes or switch between type_1 and type_2 on the fly.  If newer controls are like my old Fanuc 21, you set the Type in the control and can't do anything on-the-fly.

I see you're still working on this in GH... I'll wait to comment more until the OP does some testing.

Drafted a new PR, this basically does the G10 for you automatically instead of spinning too many times, maybe this is better for real use cases without actually having to change gcode/post, rotary modulo is orthogonal to the need I'm seeing here, don't worry about the failures the building bot is temporarily broken cause of Ubuntu snap store is down.

github.com/LinuxCNC/linuxcnc/pull/3990

I think rotary module is an improvement over wrapped rotary, but if post changes are a no no, then interpretation has to change, although a smaller change, the interpretation inconsistency might get caught in some edge case. I try to catch all I could think of in the PR.

djdelorie wrote:

As the originator of this request, I've left my feedback in detail elsewhere, but let me summarize my request for this thread: After an hour or more of spiral carving with Fusion's linuxcnc postprocessor, I end up around A556200 (for example), then Fusion does G0 A0 to "reset" the rotary for the next op.  That takes many minutes of high speed spinning, and is totally unneeded.  I would like to skip this massive unwind.  This is a common complaint online, and the usual response is to use G10 to change the WCS offset before the G0 A0 but that has its own drawbacks.  Doing something similar in the G0 itself would be much more consistent across the machine's operation.  Yes, WRAPPED_ROTARY, but there are times when you don't want to use that.
 
 

Don't expect the standard LinuxCNC postprocessor in Fusion360 to be 100% compatible. It was created by people unfamiliar with LinuxCNC and who don't respond to error reports—this is a common problem with some basic HSM posts. This is especially true for the LinuxCNC post for turning—it's completely unusable without modification. 

To work with the WRAPPED_ROTARY function, the post needs to be modified so that the A-axis output is in the range 0-360 and the sign indicates the direction of rotation.
If you can't do this yourself, I can help with instructions later.

grandixximo post=346054 userid=3182
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.

Most CAM systems support any logic, but this needs to be configured in the post. This isn't done by default.
In any CAM, the postprocessor requires settings specific to the specific system. The fact that some users experienced problems with the rotary axis returning to 0 only means they didn't configure this setting and were using the wrong postprocessor. Having done this, there are no problems working with the current logic.

Regarding changes, I think the ideal change would be to simply add the ability for the WRAPPED_ROTARY function to automatically handle values ​​>360 in absolute mode.
However, giving users the option to toggle is also a good option.

But I don't understand the difference between m27 and the current wrapped rotary mode; as far as I understand, they are identical. Perhaps in this case, adding another INI line isn't necessary; adding wrapped_rotary=2 (type=2) will suffice, which will set the default mode for the rotary axis (m26 or m27).

I also believe that M27 is the primary mode for operation.
Reducing all transitions (in m26) is difficult to debug and lacks the ability to strictly define the direction of transitions >180.
Most 5-axis mechanisms don't have infinite rotation capability, and this is critical for them. Otherwise, additional functions have to be added to the post to separate movements >180 into two separate lines - that's an additional overhead.

Also, incremental mode is not recommended for use in CAM—it's prone to error accumulation during multiple short movements, which is what most programs consist of.

M27 is wrapped_rotary but allow values ​​>360 , on which modulo 360 is done.

M26 is just shortest path, have to split any rotation >=180

My reasoning to have M26 is default, was because gcode with short segments you can run them with less post processing tricks, I thought. Also other controllers seem to have this as the default.

I did not want to change wrapped_rotary because it's already an option that is in use, rotary_modulo was more descriptive of the functionality, and maybe in future this option could replace/supersede wrapped_rotary, wrapped_rotary=2 could work, but for a first draft and testing purposes I went for rotary_modulo.

I could have M27 as the default behavior, don't think it matters much, it's more about preference.

I understand that for who already has figured out wrapped_rotary then rotary_modulo doesn't add much, and for who does not want to touch the post, neither are viable, but I think if you were to start from scratch, and you were willing to tweak the post, you'd reach for rotary_modulo rather than wrapped_rotary, or I might just have wasted a bit of time, making an option no one wants, it happens...