# Feed rate priority on rotary and linear axis?

15 Mar 2017 04:14 #89646 by nwimpney
nwimpney created the topic: Feed rate priority on rotary and linear axis?
I have recently added a rotary table set up as a 4th axis on my machine and I noticed that the feed rate on the rotary axis is not limited by the F term in a simultaneous Z and A move.

If I do a G1 A100 F100, I get the expected 100 degrees at 100 degrees/min (The move takes 1 min)

If I do a G1 Z10 F100, I get the expected 10mm move over 6 seconds.

If I do G1 Z10 A100 F100, I would expect it to scale to the slowest move, and take 1 min, but instead it runs the rotary table at 1000deg/s to match the 6 seconds of the Z move.

Is this how it's supposed to work, or is it a bug?

I am pretty new to writing g-code, so I may be doing some things strangely because don't know any better.

In this particular instance, I was planning to cut a 200mm circle at 200mm/min while ramping down at a rate of 2mm per rotation of the table.
It seems very strange to have to call for a feed rate of 6.2mm/min to get a feed of 200ish at the cutter, but I can't actually think of any other way to do a large helix at that speed.

-Nick
15 Mar 2017 12:44 - 15 Mar 2017 12:48 #89658
Todd Zuercher replied the topic: Feed rate priority on rotary and linear axis?
Yes, that is the expected behavior.
linuxcnc.org/docs/html/gcode/machining-c...r.html#sub:feed-rate

Maybe a better option to do what you are trying to, is to use G93 inverse time feed.
linuxcnc.org/docs/html/gcode/g-code.html#gcode:g93-g94-g95
Last Edit: 15 Mar 2017 12:48 by Todd Zuercher.
15 Mar 2017 18:18 #89679 by nwimpney
nwimpney replied the topic: Feed rate priority on rotary and linear axis?
Cool, thanks for the link, and the suggestion.

Inverse time saves the last step in the math, but I can't see the point in switching to inverse time for one move. By the time I've calculated how long I need the rotation to take to give me the needed feed rate at the tool, it's not that much of an extra step to calculate the feed rate which will make the Z move take that full length of time.

It seems like that even though it's documented, that behaviour doesn't make much sense. I think the ideal would be to calculate the speed based on the position relative to the axis of rotation, but barring that I would think that scaling down the speed relative to the requested F word in deg/s would be best. (at least it would lead to more slower than expected moves, as opposed to crashes)

Does anyone know if this is any sort of "standard"? I've been using that axis mostly for indexing, rather than continuous moves, but I'm curious what would be generated by most 4 axis cam software in my test case.

Any thoughts?
15 Mar 2017 18:48 #89682
Todd Zuercher replied the topic: Feed rate priority on rotary and linear axis?
Part of the problem is that the planner has no method for knowing the distance the tool tip is from the center of rotation. And you would then need to keep track of which move is slower the linear or rotary move. It is far simpler just to always use the rule if there is a linear move the feed is distance/time, and only degrees/time for exclusively rotary moves.

Does anyone else know how other CNC controls handle distance vs rotary vs mixed feed rates? I don't have any real experience with the subject.
15 Mar 2017 21:04 #89688 by nwimpney
nwimpney replied the topic: Feed rate priority on rotary and linear axis?
Yes, I expect the "ideal" I suggested above would be hard to implement reasonably since you would need a way to give it coordinates of the rotary axis. It wouldn't be that hard to do technically, but if it doesn't match up with the way everyone else does it, none of the cam software will take advantage of it anyway.
In reality, it's probably easiest to let the cam do the math for coordinated speeds, which will also be non-linear in many cases.
I still don't see where there would be a downside to scaling to the slower move, whether deg/s or mm/s. There's a lot less weird exception cases, and the ones I can think of would result in relatively small feed rate changes.
With the current way it's interpreted there are a lot of moves which require some pretty goofy math to even make them work.
Consider weirdness like this:
G1 A360 F360 will turn in 1 min.
G1 X0.001 A360 F360 will spin the axis as fast as it's capable of.
16 Mar 2017 12:13 #89738 by comjon
comjon replied the topic: Feed rate priority on rotary and linear axis?
Time to create page: 0.078 seconds