Feed rate priority on rotary and linear axis?
15 Mar 2017 04:14 #89646
by nwimpney
Feed rate priority on rotary and linear axis? was created 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.
-Nick
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
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 4981
- Thank you received: 1378
15 Mar 2017 12:44 - 15 Mar 2017 12:48 #89658
by Todd Zuercher
Replied by Todd Zuercher on 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
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.
Please Log in or Create an account to join the conversation.
15 Mar 2017 18:18 #89679
by nwimpney
Replied by nwimpney on 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?
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?
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 4981
- Thank you received: 1378
15 Mar 2017 18:48 #89682
by Todd Zuercher
Replied by Todd Zuercher on 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.
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.
Please Log in or Create an account to join the conversation.
15 Mar 2017 21:04 #89688
by nwimpney
Replied by nwimpney on 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.
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.
Please Log in or Create an account to join the conversation.
16 Mar 2017 12:13 #89738
by comjon
Replied by comjon on topic Feed rate priority on rotary and linear axis?
You might be interested in this topic:
forum.linuxcnc.org/38-general-linuxcnc-q...-machining-feed-rate
forum.linuxcnc.org/38-general-linuxcnc-q...-machining-feed-rate
Please Log in or Create an account to join the conversation.
21 Oct 2018 15:36 - 22 Oct 2018 19:29 #119166
by 858PSJ
Replied by 858PSJ on topic Feed rate priority on rotary and linear axis?
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.
Last edit: 22 Oct 2018 19:29 by 858PSJ. Reason: silly math error, had divisor and division sign in the wrong place
Please Log in or Create an account to join the conversation.
Time to create page: 0.075 seconds