Machsupport Forum
G-Code, CAD, and CAM => G-Code, CAD, and CAM discussions => Topic started by: Mirko KD on January 19, 2014, 02:14:00 PM
-
Hi,
I have a question about 4 axis feedrate coordination. I checked "Use radius for feedrate", selected the proper Axis of Rotation (Y in my case) and entered the value (12.5mm) for radius in Settings tab.
Now the problem that i have is that the actual cutting feed is significantly slower than the feed value defined in the g-code? To test this i increased the feed rate from 300 mm/min to 600 mm/min in my g-code, but it made no impact on total machining time. What could be the reason for this?
-
The "Radius" setting is actually the distance of Z zero from the center of rotation. If Z zero is the center of rotation, set the "radius" value to zero.
-
Z zero in my case is on the outside diameter of a part with 25mm diameter, so i entered 12.5mm for radius in Settings tab.
-
Just to make sure, i made another g-code with Z zero in the center of rotation, set the radius value to zero in Settings tab, but unfortunately the result is still the same. I really have no idea what could be the problem. I used RhinoCam for generating paths and Mach3 MM post.
-
There is a bug in Mach that turns the whole "rotary axis feedrate compensation" off, if the "Rotation Radius" DRO has a value of zero.
The work around for this is, when the correct value is zero (Z origin at centre of rotation) then enter a very small value. EG, 0.001
I am sure I remember Brian sending me a version where this bug was fixed, but it never seemed to make it into general release.
This may or may not be the issue you are having.
Remember that the maximum velocity of the rotary axis, as set in motor tuning, is never exceeded even if the feedrate compensation system wants it to.
Post some example code and I will try it out here.
Greolt
-
I am aware of the bug in Mach if the "Rotation Radius" DRO has a value of zero, so i was entering 0.001 as advised. What i`m getting is that the axes are working in coordination with each other so the work piece comes out with correct geometry, but the problem is that Mach works with the feedrate slower that the one specified in the code.
Here`s some sample code made using RhinoCam, feedrate is 800mm/min.
4 axis sample code.gc - 150 KB (http://fileom.com/s5k4zjsjq8zk/4_axis_sample_code.gc.html)
Z zero is on the outside diameter of the part - 12.5mm distance from rotation center. According to RhinoCam`s calculations, total machining time should be 4:29 mins at feed rate 800mm/min, but Mach actualy needs 10:53 mins to complete. Funny thing, when i change the feedrate to 1600mm/min, it should take 2:15 mins for completion, but Mach steel needs 10:53 mins. So if RhinoCam`s time calculations are wright, it appears that Mach is always using feedrate aprox. 330mm/min.
In motor tuning i have the following values:
(Native units are milimeters, steppers are Nema23)
X axis: Steps:80 Velocity: 3199.8 Acceleration: 400 Step pulse: 1 Dir pulse: 3
Y axis: Steps:80 Velocity: 3199.8 Acceleration: 400 Step pulse: 1 Dir pulse: 3
Z axis: Steps:160 Velocity: 1800 Acceleration: 280 Step pulse: 1 Dir pulse: 3
A axis: Steps:111.111112 Velocity: 3600 Acceleration: 400 Step pulse: 1 Dir pulse: 3
-
Someone correct me if I'm wrong, But Isn't the velocity for a rotarty axis in degrees/min, rather then mm/min? Try increasing the A axis velocity (a lot) and see if it makes a difference.
-
I increased the velocity for A axis to 18000 which is the highest value i can enter at 35k kernel speed, and total time was 10:20 - not a big difference. Then i increased the acceleration to 4725 (maximum value) and now total time dropped to 7:14. I guess i would have to increase the kernel speed in order to set higher values for velocity and acceleration?
-
Here`s some sample code made using RhinoCam, feedrate is 800mm/min.
4 axis sample code.gc - 150 KB (http://fileom.com/s5k4zjsjq8zk/4_axis_sample_code.gc.html)
You will need to upload your code directly to the forum.
That download site wants me to open an exe file disguised as your code file. No way. ::)
Greot
-
I increased the velocity for A axis to 18000 which is the highest value i can enter at 35k kernel speed, and total time was 10:20 - not a big difference. Then i increased the acceleration to 4725 (maximum value) and now total time dropped to 7:14. I guess i would have to increase the kernel speed in order to set higher values for velocity and acceleration?
Are talking about actual cutting time or estimated?
Most CAM programs that I have seen have an time estimation feature but also have a scaling factor that needs to be set to get that estimation somewhere near actual. Machine acceleration and other factors are unknowns.
-
Sorry about that, i just realized there are additional post options :-[
-
I increased the velocity for A axis to 18000 which is the highest value i can enter at 35k kernel speed, and total time was 10:20 - not a big difference. Then i increased the acceleration to 4725 (maximum value) and now total time dropped to 7:14. I guess i would have to increase the kernel speed in order to set higher values for velocity and acceleration?
Are talking about actual cutting time or estimated?
Most CAM programs that I have seen have an time estimation feature but also have a scaling factor that needs to be set to get that estimation somewhere near actual. Machine acceleration and other factors are unknowns.
I was talking about actual cutting time.
In RhinoCam, to my knowledge there is no option to set scaling factor for time estimation, but from other users` experiences the actual cutting time is somewhere at 1.2 x estimated time.
-
I intended to run your code on my machine to see long it took.
However a quick calculation of F800 at 25mm dia. works out at approx 3700 degrees/min of the rotary axis.
My rotary max's out at 3000 degrees/min. So it would not give a proper comparison of time taken.
I assume that finishing toolpath is done with a ballnose cutter. Why not run "along axis" rather than "across axis" ? Much less demanding of rotary axis feedrate.
Greolt
-
Cycle time is 2:17 with " A Rotations Enabled " unchecked in ==> Config ==> Toolpath.
Alex
-
I intended to run your code on my machine to see long it took.
However a quick calculation of F800 at 25mm dia. works out at approx 3700 degrees/min of the rotary axis.
My rotary max's out at 3000 degrees/min. So it would not give a proper comparison of time taken.
I assume that finishing toolpath is done with a ballnose cutter. Why not run "along axis" rather than "across axis" ? Much less demanding of rotary axis feedrate.
Greolt
My calculation was the same as yours. In motor tuning for rotary axis i have 4000 degrees/min velocity (which should be sufficient) and 400 for acceleration, so it seems that acceleration is the limiting factor here. When milling across axis on very small objects, rotary axis makes hundreds of tiny turns, accelerates and decelerates in short intervals, so unless the acceleration/deceleration is instantaneous, the actual feed never reaches the projected value. That`s just my guess.
Why not run "along axis" rather than "across axis"? Well i was thinking the same thing, it is much less demanding of rotary axis, but unfortunately there is a downside - for finishing toolpath the total machining time is 3 to 4 times longer than with "across axis" (and i `m really trying to cut the milling time as much as possible). At least this is the case with RhinoCam, i haven`t tried any other CAM software yet.
-
Cycle time is 2:17 with " A Rotations Enabled " unchecked in ==> Config ==> Toolpath.
Alex
What do you mean by "Cycle time is 2:17"?
-
Hi,
forget what I said, I am stupid. ;D ::)
Yes the limiting factor is the acceleration and a bit the A velocity.
With Velocity at 8000 and acceleration at 10G your attached G-Code runs in 2 minutes and 20 seconds.
You can change the acceleration by typing the value you want into the acceleration field and klick Save Axis Settings.
Doen't klick on the acceleration slider after that.
Alex
-
Hi,
forget what I said, I am stupid. ;D ::)
Yes the limiting factor is the acceleration and a bit the A velocity.
With Velocity at 8000 and acceleration at 10G your attached G-Code runs in 2 minutes and 20 seconds.
You can change the acceleration by typing the value you want into the acceleration field and klick Save Axis Settings.
Doen't klick on the acceleration slider after that.
Alex
Hi Alex,
I entered 8000 for velocity and 10000 for acceleration as you suggested, but i get total run time of 7:14 mins. I have no idea what could be the problem.
Could you please send me your Mach profile (xml file) so i could compare all the settings to my current profile?
-
In addition to getting Mach set up correctly (already being addressed by others), you might take a look at using the G93 federate, provided your CAM supports Inverse Time.
It seems that if you identify A as rotary and that the steps per degree is correct, Mach will ignore everything else and calculate the correct 4th axis federate for a move using G93 (provided you have the bandwidth - rotary axis pulse rates can get very high in a hurry).
-
Mach will ignore everything else and calculate the correct 4th axis federate for a move using G93 (provided you have the bandwidth - rotary axis pulse rates can get very high in a hurry).
I have never used G93, my CAM does not support it.
However I assume Mach will still honour the maximum velocity as set in motor tuning. (normal rapid speed) If so, then why will pulse rates go beyond normal levels ?
Greolt
-
Mirco,
if you put in 10.000 as you said, that's only 1G you need at least 5G ( 50.000) to see a reasonable different. I tested with 10G ( 100.000 )
Whether it will work or not depends on your A-Axis mechanism. ( what diameter, what mass, friction, transmission, transmission ratio, and motor)
At least you can test it.
Alex
-
Alex,
I entered 100.000 but unfortunately the result is still the same.
-
Ad a G64 to your G-Code.
Alex
-
Added G64, still no difference.
-
Did you increase the feedrate to F8000 in your G-Code ?
Alex
-
Mach will ignore everything else and calculate the correct 4th axis federate for a move using G93 (provided you have the bandwidth - rotary axis pulse rates can get very high in a hurry).
I have never used G93, my CAM does not support it.
However I assume Mach will still honour the maximum velocity as set in motor tuning. (normal rapid speed) If so, then why will pulse rates go beyond normal levels ?
Greolt
My comment about bandwidth was only to point out that Rotary axii require very high pulse rates compared to linear. So much so that often on first exposure, users think there is something wrong when actually the system (particularly if using a PP) is maxed out and the rotary axis is not 'spinning' as expected.
However, you raise an very good point about the set maximums being honored. Clipping an excessive rate would have to come after the G93 calculation determines the rate, and I don't know if Mach does that or not. It is certainly a good question and one that should be answered/tested. I just moved my shop and my machines are down or I would have done that before posting back. Perhaps somebody can MDI a super fast G93 and post the result. It would be very good info to have.
I would think that the CAM software would specify the federate in the G93, so normally an 'overspeed' condition that would not be a problem.
To your specific question, I am not sure what you mean by 'normal' levels, but if you mean the global F setting, then yes, a G93 federate will go beyond. The F setting and all of the parameters that effect it (except probably accel) seem to be ignored when G93 is active.