Hello Guest it is April 24, 2024, 09:29:54 PM

Author Topic: 4 axis feedrate coordination  (Read 13206 times)

0 Members and 1 Guest are viewing this topic.

4 axis feedrate coordination
« 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?

Offline ger21

*
  • *
  •  6,295 6,295
    • View Profile
    • The CNC Woodworker
Re: 4 axis feedrate coordination
« Reply #1 on: January 19, 2014, 02:17:20 PM »
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.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html
Re: 4 axis feedrate coordination
« Reply #2 on: January 19, 2014, 02:21:00 PM »
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.
Re: 4 axis feedrate coordination
« Reply #3 on: January 19, 2014, 06:06:01 PM »
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.

Offline Greolt

*
  •  956 956
    • View Profile
Re: 4 axis feedrate coordination
« Reply #4 on: January 20, 2014, 01:44:07 AM »
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
« Last Edit: January 20, 2014, 01:46:06 AM by Greolt »
Re: 4 axis feedrate coordination
« Reply #5 on: January 21, 2014, 10:39:59 AM »
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
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

Offline ger21

*
  • *
  •  6,295 6,295
    • View Profile
    • The CNC Woodworker
Re: 4 axis feedrate coordination
« Reply #6 on: January 21, 2014, 10:47:11 AM »
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.
Gerry

2010 Screenset
http://www.thecncwoodworker.com/2010.html

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html
Re: 4 axis feedrate coordination
« Reply #7 on: January 21, 2014, 03:38:35 PM »
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?

Offline Greolt

*
  •  956 956
    • View Profile
Re: 4 axis feedrate coordination
« Reply #8 on: January 21, 2014, 04:39:05 PM »
Here`s some sample code made using RhinoCam, feedrate is 800mm/min.
4 axis sample code.gc -  150 KB
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

Offline Greolt

*
  •  956 956
    • View Profile
Re: 4 axis feedrate coordination
« Reply #9 on: January 21, 2014, 05:05:36 PM »
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.