to DeskProto home page
Contact  
looking glass icon
to DeskProto Facebook page
to DeskProto Google Plus page
to DeskProto Youtube page

Forum menu:

DeskProto user forum

Forum: communicate with other users.


Forum home page main
Forum:
Thread:
A axis feed rates
You’re logged in as:guest
Online users:0
Online guests:203
 

page 1 of 2


teg
2013-06-08
21:07 CEST

Lex,

I found somebody who makes an adapter tooling plate for my X3 and Sherline 3700 rotary table. So I have my 4th axis finally mounted!!!

I followed your tutorial to do the A axis cutting for Venus De Milo. I produced the g-code and everything looked great. I put machinable wax on and started the program. It appears to run correctly and this may be in my setup and not your software but the A axis rotation is painfully slow. When I inspect the g-code the command being used is either F9.4 or F15.0 which I take as the "inches per minute" since I configured everything to inches.

So, is there something I can change in DeskProto I can change to alter the A axis rotation speed? When I do a manual jog on the A axis it rips really fast in LinuxCNC! It's like scary speed times a 1000! But, when the program runs those commands its like watching the grass grow. You literally can't see it move.

Sadly, not many people use my setup out on the other forums so I'm not getting much help on this one.

As to the included picture. This is my first successful cut where I didn't collide with anything. It was done with standard 3 axis. I used a 1/16" Ball Nose with a 1" cutting length at 30 degrees slope on the flutes, 4 flutes. I was so scared I was going to break it (like my first one) because it takes Amazon 1-2 months to get them in stock that I set the depth to 0.0625" which took forever! I finally had to shut it down which is why I didn't get to the finishing pass. For scale purposes she is 3" in the X, 2" in the Y and 1" in the Z.

I just want to take some time to thank you for offering the Hobby version of your software. I wish more companies would since there are some of us who want to learn these things and they just simply price it so out of reach that its silly.

Anyways! A axis rotation speeds! Thanks in advance for your help and I apologize in advance if its a LinuxCNC config problem ;-)


teg

teg
2013-06-08
22:43 CEST
Lex,

I should also add that while I want to increase the feed rate of the A axis, I do't want to increase all of the feed rates as the Z and X seem just fine.

Also, if you look in the background you will see my other failed attempts at cutting Venus. My two boys joked that Venus looked more like Georgia Washington when I was losing steps in the Z axis from colliding with the sides.

teg

teg
2013-06-09
04:46 CEST
Actually, its almost like 15 degrees per minute rather than 15 inches per minute. The rapids are perfect speed. Everything else runs at full tilt... just not the A axis!

Any ideas at what I've got wrong?

teg
2013-06-09
04:47 CEST
Sample of the G-Code;

G1 A360.0000 F15.0
G1 X0.0123 F15.0
G1 A0.0000 F15.0
G1 X0.0368 F15.0
G1 A360.0000 F15.0
G1 X0.0613 F15.0
G1 A0.0000 F15.0
G1 X0.0858 F15.0
G1 A360.0000 F15.0
G1 X0.1103 F15.0
G1 A151.1688 F15.0

Lex
2013-06-10
10:43 CEST
Hi Teg,

Feedrate for rotation axis toolpaths is a difficult issue.
In standard G-code the Feedrate is defined only in linear speed units (like mm/sec, inches/min, etc). The G-code definition does not supply a rotation speed command. This means that the controller needs to calculate the correct rotation speed that is needed to reach the prescribed linear feedrate: the closer to the rotation axis, the higher the rotation speed that is needed.
Unfortunately many controllers do not conform to the ISO G-code specifications in this matter.

For an example see forum issue Rotation axis speed in Mach3.

teg
2013-06-10
14:31 CEST
Thanks, Lex!

Some searching has pointed me to the HAL setup (HAL is the "Hardware Abstraction Layer" in LinuxCNC) so I will give that a shot tonight.

If I find anything out I will be sure to post the fix back here so you have a future reference.

teg
2013-06-13
00:18 CEST
Lex,

I have asked the guys over at Sherline, Probotix.com and done a lot of digging on this subject.

From what I now know, LinuxCNC takes the A axis and B axis F command as degrees per minute.

I did find where some more expensive controllers for other machines are set up to interpret the F command as a feed rate in inches or millimeters per minute or the like, calculated at the tip of the end mill.

That makes sense as it is a very nice feature to have. Sadly, that is not something LinuxCNC does for you.

Would know you of a RegEx or something where I could so a search and replace to bump this to degrees?

thanks...

teg
2013-06-13
06:18 CEST
As you can see, I'm still researching this. From the LinuxCNC Manual updated sometime in April of 2013;

ANGULAR_UNITS = <units> - Specifies the machine units for rotational axes. Possible choices are deg, degree (360 per circle), rad, radian (2pi per circle), grad, or gon (400 per circle). This does not affect the angular units of NC code. In RS274NGC, A-, B- and C- words are always expressed in degrees.

So, now I know I'm working in RS274NGC which found life here;
www.nist.gov/manuscript-publication-search.cfm?pub_id=823374

I'm sure that there is an ISO somewhere that will contradict this but LinuxCNC began life as an NIST project and adheres to NIST standards. NIST adopted the original NC specifications from MIT but after that I don't know what happened with the rest of the world. If MPEG 4 is any indication of how g-code has progressed in the ISO then its all over and we might as well go home ;-)

Can you find it in your heart to support the RS274NGC use of degrees in rotational axis? It certainly would make me send you more of my money! At this point, I really have no other options other than to spend thousands that I don't have.

The linuxCNC manual page is here for your entertainment; www.linuxcnc.org/docs/devel/html/config/ini_config.html



Lex
2013-06-13
10:23 CEST
Hi Teg,
Thanks for this researching, this is an absolutely interesting issue to sort out.

The report "NIST RS274NGC Interpreter - Version 3" that you linked to (NIST stands for the US National Institute of Standards and Technology) indeed mentions (in section 2.1.2.5):
A. For motion involving one or more of the X, Y, and Z axes (with or without simultaneous rotational axis motion), the feed rate means length units per minute along the
programmed XYZ path, as if the rotational axes were not moving.
B. For motion of one rotational axis with X, Y, and Z axes not moving, the feed rate means degrees per minute rotation of the rotational axis.


This is exactly like you say, and can be dealt with by writing a new Feedrade into the NC file when switching between linear moves and pure rotation moves.

In my view the problem is the mixed moves (so a new A-position combined with a new X Y or Z-position in one G1 or G0 movement command. Here the NIST definition sucks, as for (say) a 1 mm Z-increment combined with a full 360 degree rotation this would result in an actual speed that is FAR too high. And I wonder how these combined movements in fact have been implemented.

This being said: still a problem is present here that we need to address in DeskProto. Some special option for rotation axis feedrates needs to be added. This is not a simple fix though. I will put it on our ideas list for a next version of DeskProto.

Lex.

teg
2013-06-13
17:22 CEST
Thanks, Lex!

I guess in the end DeskProto becomes more robust but you gain a few more grey hairs, right?

If you need a beta tester, you are in luck! Whatever I can do to help, consider me available.


page 1 of 2