Machsupport Forum
G-Code, CAD, and CAM => G-Code, CAD, and CAM discussions => Topic started by: rgsparber on February 23, 2016, 09:17:06 AM
-
If you need to debug software generated G-code or create code by hand, understanding the arc command may be necessary. At first glance, it can be confusing. This article attempts to explain the arc command. It also documents an old Mach3 bug associated with drawing arcs on the XZ plane plus offers a work-around.
If you are interested, please see
http://rick.sparber.org/ARC.pdf
Thanks,
Rick
-
A very clear and concise description with easy to grip explanations.
Very well done Rick, thanks for posting.
Would be a valuable addition to our "toolbox".
Kind regards,
Russ
-
If you have a G90 and G91.1 on the same line, whichever one is first is ignored.
You might want to change that in your pdf.
-
The G90 followed by G91.1 was generated by CamBam and I assumed that it meant I was using absolute mode except for IJ where it is incremental. Is that wrong?
Rick
-
G90 is absolute and G91.1 is incremental arcs.
But the way cambam is doing it is wrong.
Run this code, and watch the mode in the status bar. It will never change to G91. And if you were in G91 mode when you started, it won't change to G90.
G90 G91.1
G4 P2
G91 G90.1
G4 P2
G90 G91.1
G4 P2
G91 G90.1
-
Excellent work Rick, thanks for sharing.
Tweakie.
-
Nice one Rick - never knew that.
Hmmmm - that G90 G91.1 thing is a bit of a doozy. Functionally there's NO reason for them to be in the same modal group (at least as far as I can see but happy to be corrected by the gcode gurus).
I'm wondering if they've ended up in the same group for no other reason than they share major numbers.
BTW - Am I right in thinking 90.1 and 91.1 are a purely Mach3 thing?
-
Yes, a Mach3 (and 4) thing. I noticed in the Mach4 manual that they are in different groups in Mach4.
-
What you may be seeing in G18 is the difference in settings for turn ?? where G2/G3 can be reversed.
Also in Radius mode you MUST be carefull about the amount of arc swing when doing arcs approaching 180 degs as there are situations where teh Radius format will create a WRONG arc based on teh code. That is WHY IJ mode was created it fixed the math problems that are associated with Radius mode arcs.
Just a thought, (;-) TP
-
BTW - Am I right in thinking 90.1 and 91.1 are a purely Mach3 thing?
They are both used in LinuxCNC as well.
Tweakie.
-
Two things have me confused about the G90 and G91.1 commands. I see these parameters are set in Mach3 using Config|General Config... It is my understanding that these parameters are superseded by the G-code. So if I leave out either of these commands, wouldn't Mach3 just default to the Config page?
I'm also still confused about the difference between G90 and G91.1. It appears they do different things so are not in conflict. G90 is for axis movement. G91.1 is for IJK movement.
Help!
Rick
-
So if I leave out either of these commands, wouldn't Mach3 just default to the Config page?
Yes. But if your code is expecting something other than what's in the config page, then what Mach3 cuts won't be what you were expecting.
It appears they do different things so are not in conflict.
They are in the same modal group, so the g-code interpreter only reads on of them per line. It's not that they confict, but rather, one of them is ignored. If they are on separate lines, they work fine.
G90
G91.1
Works fine.
G90 G91.1
does not.
-
They are both used in LinuxCNC as well.
Again - happy to be corrected but I think I'm right in saying that Mach3 and LinuxCNC share some of the same code base (particularly I think - the interpreter) so that's probably why.
I'm also still confused about the difference between G90 and G91.1. It appears they do different things so are not in conflict. G90 is for axis movement. G91.1 is for IJK movement.
This is what I was trying to get at in Reply #6. I think it's just a Mach3 (and possibly LinuxCNC) cockup. i.e. they've ended up in the same modal group but they shouldn't be.
Gerry's mention that they are NOT in the same group in Mach4 would tend to back this up.
-
HIYA Rick You also need to understand that the G90.1 and G91.1 are modal . If you set it once it will stay there until you reset it . The config page values are just for startup modes so that MACH# will startup in a preconfigured mode as you define it to be.
A cam or OP can program arcs in many different ways so WHen you DO you also have to specifc to MAch3 in Gcode teh Modes you used to do teh arc be it INC or ABS or Inc IJ or Abs IJ or any combination of teh mentioned modes. When you program the arc YOU also have to tell teh control HOW you did it so it understands how to MOVE as you intended.
As long as you never CALL to change it it will always be the same as config. But once you call it in a program it switches to the Called mode as they are modal calls.
The problem with G90 G91.1 is there were BOTH internally placed in teh same modal GROUP. This was actual a BUG that was never fixed. So that being you cannot call both on the same line as one will be ignored.
(;-) TP
-
I'm a bit slow on the uptake, but now do understand the concept of Modal. I also proved to myself that with G90 and G91.1 in the same block, G90 causes Distance Mode to be set Absolute but then it is put back to the default value when Mach3 finds G91.1. Since my default values were Distance Mode: Absolute and IJ Mode: Incremental, it all worked for the wrong reason. I'm correctly the article now and will publish the update soon.
Thanks to all that helped me understand this bowl of spaghetti!
Rick
-
OK, I have updated the article. Please let me know if I got anything wrong.
Thanks!
Rick
http://rick.sparber.org/ARC.pdf
-
If I may make a comment when you write gcode as an example it is always best to define teh values in teh normal format and order. Yes it is OLD school AND some controller can ONLY take a certain format but it does read much better in my opinion.
Now teh controller will load in Line elements in the order it was programmed to do so to IT order does not mean much But for reading purposes it makes it more clear.
You articles are very good by the way. And will be very helpful to new users.
G02 X0.000 Y0.000 I0.000 J0.000 F123
Instead of
G2 X0 Y0 I0 J0 F123
Just a thought, (;-) TP
-
Not saying its wrong, but .....
Mach3 doesn't put it anywhere. Its skipped over and left in whichever state it is currently in. Could be the default, but not necessarily.
Absolute, or Incremental because that is its current state
-
Hopefully I am moving closer to the truth. Here is the corrected text: http://rick.sparber.org/ARC.pdf
Thanks,
Rick
-
I continue to learn about arcs and now see that there is NOT a bug in Mach3 related to the XZ plane. See page 3 of http://rick.sparber.org/ARC.pdf for details.
Rick
-
Curl the fingers of your right hand into a fist with your thumb pointing out (like the Fonz). If you point your thumb in the positive direction of an axis, your fingers point in the direction of positive rotation.
-
I am popping the corn right now (;-)
(;-) TP
-
If I may make a comment when you write gcode as an example it is always best to define teh values in teh normal format and order. Yes it is OLD school AND some controller can ONLY take a certain format but it does read much better in my opinion.
Now teh controller will load in Line elements in the order it was programmed to do so to IT order does not mean much But for reading purposes it makes it more clear.
You articles are very good by the way. And will be very helpful to new users.
G02 X0.000 Y0.000 I0.000 J0.000 F123
Instead of
G2 X0 Y0 I0 J0 F123
Just a thought, (;-) TP
Sorry I missed your suggestion. It is a good one and I will make the changes now.
Thanks,
Rick
-
LOL - I don't mind admitting you had me convinced it was a bug and now you have me convinced it isn't.
-
rgsparber,
Added your article in Member's Docs called Arc Command - Mill here is the link:
http://www.machsupport.com/forum/index.php/topic,32004.msg222697.html#msg222697
There is an existing thread about arc's for the Lathe, thus wanted to distinguish between the two threads.
For Turn see this link:
http://www.machsupport.com/forum/index.php/topic,11932.msg76353.html#msg76353
RICH
-
Trying to explain G18,G19 arc orintation can be confusing . Even Smid makes it very confusing in teh 2nd edition page 240 (;-). His pictures LOOK good until you realise his axis orintation is NOT what you see standing in front of the machine. You would have to flip and rotate his picture for it to fit a normal machine for G18,G19.
Best way to figure it out for yourself is to stand in front of your machine then program it both ways and SEE for yourself where is goes. THEN write it down, draw yourself a picture.
I would refrain from doing an explaination based on standing behind teh machine. Give your examples as standing in front of the machine assuming teh Right Hand rule.
(;-) TP
-
People learn in many different ways. Some click with the right hand rule so I have added that explanation. But I, for example, prefer having a consistent viewpoint. In this case, looking in the -Y direction.
Thanks,
Rick
-
IF you only look in teh Y- direction you cannot define G18 arcs as the arc is inline with your veiw.
Here is how I look at it. Always start by standing in front of teh machine. In G18 teh Z+ is up and teh X= is right. ( For Quadrant #1 that is, but Quads are a different chapter.) Program a G2 andG3 and see where they go. Draw a picture or write it down.
NOW for G19 assuming a right hand approach MOVE to teh right hand side of teh machine and veiw it. Z+ is UP and Y+ is right. Program a G2 and G3 and note the motions
THen when you are creating 3d Gcode ( and few ever do by hand) refer to the Example veiws.
Trying to explain it in a way that is not based on a standard gets very confusing as everyone has a different approach and some are backwards to others.
Not saying any way is wrong as long as you get the idea. Kinda like drawing in CAD there are dozens of ways to draw a simple part. And the finished part will look the same.
BUT IF you are going to explain it you need to reference a KNOWN standard that is defined by the general CNC world.
(;-) TP
-
NOW according to SMID The arc swing is a mathematical reference NOT a machine plane reference. (;-)
2nd edition Page 240
(;-) TP
-
I certainly agree that the XYZ axes and associated rotational movements are defined by math. In all cases clockwise (i.e. positive) rotation is defined by looking in the negative direction along the axis that is not part of the plane. No exceptions. As commonly defined on mills, the Y axis points away from the operator and towards the column. Looking along the Y axis towards the XZ plane puts you behind the mill. Can't help that...
Rick
-
YEs it is math based BUT that does not help you one bit IF you are standing in front of the machine and have to constantly turn the machine upside down in your brain to program it. I have always taught the total right hand move format and it makes good sense when standing in front of the machine punching in Gcode. AND yes teh Arc motion for G2/G3 in G18 , G19 are backwards to each other BUT it has always been that way for about 45 years now.
But I guess it all depends on HOW you what to learn it. I learned it by standing in front of a machine with a blueprint in my hand punching in code.
Just my opinion, Your mileage may vary due to local conditions (;-) TP
-
All is well if we both turn out the same code. I'm more comfortable with math than machining. Code generation takes place in my den.
Rick