Feed rate priority on rotary and linear axis?

15 Mar 2017 04:14 #89646 by nwimpney
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.

15 Mar 2017 12:44 - 15 Mar 2017 12:48 #89658 by Todd Zuercher
Yes, that is the expected behavior.

Maybe a better option to do what you are trying to, is to use G93 inverse time feed.
Last Edit: 15 Mar 2017 12:48 by Todd Zuercher.
15 Mar 2017 18:18 #89679 by nwimpney
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 by Todd Zuercher
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
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
Time to create page: 0.354 seconds
Powered by Kunena Forum