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

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

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?

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.

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.

You might be interested in this topic:

forum.linuxcnc.org/38-general-linuxcnc-q...-machining-feed-rate

A Sherline rotary table takes 160 clocks for each degree or 57600 clocks per revolution. if you have a fixed diameter cylinder you're trying to mill, then (1inch / circumference ) equals (scale /57600). or (scale ) equal (57600 / circumference). Run stepconf and make a new 4 axis config. edit the .ini file and enter the scale determined above and change the A-axis from ANGULAR to LINEAR, also change A acc and velocity to whaterever you're using for X axis. The A axis will now take inches for input instead of degrees. I have an old text program which outputs offsets in inches for x and y. I edit the text output file with a macro editor and change all y's to a to get text characters that "wrap around" the cylinder or change all x's to a and then change the y's to x to get words that "wrap around" the cylinder . Not sure how this will help with a spiral but believe the formula spiral (length) equals (3.14159265 times rings times (D + d) / 2 )) will be needed. I'm running 12.04 linuxcnc and it doesn't display the rotarys at all but it mills the text nicely.