Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: DAlgie on May 29, 2009, 12:11:09 AM
-
It was suggested to override a feed speed problem in Turn that you use the R value instead of using I and K arc centers. I like the R value because it is faster to hand code, as I do that a lot. However, with the R value I don't seem to be able to control the arc Major or minor and seem to always end up with the major arcs. I looked through it all and I bet I'm missing something simple, but how do you force Mach Turn to differentiate between major and minor arcs? Thanks.
DaveA.
-
Anyone? Surely this is a problem that someone else has had to deal with.
-
What is major and minor arcs?
-
Not sure what you are meaning as well, wondering though if it is the Reversed Arcs in Front Toolpost setting you need to change, its on Ports and Pins , Turn Options page.
Hood
-
Sorry, I should have been more descriptive. If you fit an arc between two points without a signed centre, it can go two different paths and still be a G2 clockwise or G3 counterclockwise. One path is a minor arc, the shorter of the two, and the other is the major, the longer path of the two. One will blend in smoothly with the rest of the geometry, and the other will be abrupt, but the control will still agree with it. An Accurite CNC mill I use has a soft key to let you choose between the two. Mach turn seems to always go for the major, the longer arc if you use an R value instead of a signed centre point.
-
I'm going out on a limb here.
Have you tried to use a negative value for the R? What happens then?
-
Can you attach a screenshot of ewhat you are meaning please.
Hood
-
If its like this then it is the Reverse Arcs in Front Post that you want to change as mentioned earlier.
Hood
-
Hood, just out of curiosity, if you want one major arc and one minor arc on the same work piece, how do you do it then?
-
I am atrocious at G Code but would imagine you would code your arc in two segments.
Hood
Edit
Is it something like this you are meaning?
G1X100.4Z-209.85F0.3
G3X103.6Z-206.65R1.6
G3X102Z-211.45R1.6
-
DaveA,
Could you post an example or some code, of what you are talking about. I took a look at my Smid book looking for some preferences in the interpretation but couldn't find anything specific. Just trying to learn something.
Thanks,
RICH
-
Yes, you have it there at that last post. The arc is still the same direction, but the unsigned centre is on the opposite side of where you want, so the arc is theoretically correct in direction, but just like that last screenshot you have. Somebody told me that this problem only shows up with either G3 or G2 but can't remember which, my lathe is not here so I will have to go check more and get a screenshot, but it will look a lot like what you got there.
DaveA.
-
have never seen that, only way I got that was to code in 2 parts, wonder why you are seeing it?
Can you attach the code and your xml and I will see if I can reproduce here, also are you using an old version of Mach as I seem to recall that there was an issue similar waaaaaaaayyyyyyyyyyyyy back, but that was before I had a lathe so it didn't register in the old grey matter :)
Hood
-
Here's a couple of screenshots that melee got with his testing
-
What is the code for these screenshots?
Hood
-
DaveA,
Since you struck my curious side,
Pic #1 shows some info about using R values for arcs and was wondering if that is were you are comng from?
Pic #2 shows a simple arc on the end of a shaft using the R value ( + or - ) differently along with the effect of Reversed Arcs checked, BTW this is for a lathe. The only difference in the code is the + or - R value. The first capture in the picture does the ball cut wanted.
RICH
-
I was apparently into something in this reply: http://www.machsupport.com/forum/index.php/topic,11674.msg74443.html#msg74443
-
SteinarN,
How about using this as an example.
RICH
-
I think I should buy a book explaining how to make g-codes.
One question, is it required to use I/K codes instead of R codes when making a part with arcs which would require both checked and unchecked Reversed Arcs in R codes?
-
The above shows a G2 and a G3 arc, wouldnt matter whether it was IK or R.
Looks like the + or - with the R defines minor or major , having none on my system makes it a minor, wonder if Dave has a - in his code?
Hood
-
I have never used a sign with R, but will try it and see if it works. Might make sense since I always get major arcs, which is the larger of the two, well, not a larger radius but larger circumference. I used to use R with a Fanuc turning center and the Fanuc has no way to define major or minor arcs, yet always seemed to be the right one. Fanuc must have some kind of intelligent logic to it's arc definition I guess.
-
Can you please post your code so that I can test here. I never use + or - but always get what I am after, would be interesting to see what I get with your code.
Hood
-
Hi All,
Certainly a novice at Gcode on my end. Using R in G2 or G3 or for that matter I,J,K seems straight
forward. Who's advice do you want to follow? ( BTW, not mine )
NITS came out with a standard on programing a long time ago. Different machining centers and manufactures, programs, post processors, etc........ seems like over time it's been implemented differently in use. Then you have folks out there that have written articles to clarify ARC coding and books by different authors. Many users, myself included, will just click the reverse arc's box, the arc problem ( crop circles ) goes away, SOMETIMES, and life is good. Just look at postings from different programs and what happens when "interpreted" by MACH. The Smid book dosn't even talk about the "R" that i could find.
So you may ask " should i do something and it will always turn out correct". I don't know, because it's not as simple as one may think based on the post processor, the programs interpretation of the code, a math error, dia / rad mode, incremental / absolute, the plane your working in, how you inialize Mach, etc.........
May I remark, that sometimes a simple question or problem is "loaded" and if a little code was provided it sure can make it easier in trying to help. The R stuff i posted was from something saved some time ago and don't even remember where i got it. Here is some more for reading pleasure......
RICH
THIS FOLLOWING IS A LINK TO THE NIST RS274/NGC LANGUAGE
http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_33a.html
The following info was extracted from the handbook.
3.5.3.1 Radius Format Arc
In the radius format, the coordinates of the end point of the arc in the selected plane are specified along with the radius of the arc. Program G2 X- Y- Z- A- B- C- R- (or use G3 instead of G2). R is the radius. The axis words are all optional except that at least one of the two words for the axes in the selected plane must be used. The R number is the radius. A positive radius indicates that the arc turns through 180 degrees or less, while a negative radius indicates a turn of 180 degrees to 359.999 degrees. If the arc is helical, the value of the end point of the arc on the coordinate axis parallel to the axis of the helix is also specified.
It is an error if:
· both of the axis words for the axes of the selected plane are omitted,
· the end point of the arc is the same as the current point.
It is not good practice to program radius format arcs that are nearly full circles or are semicircles (or nearly semicircles) because a small change in the location of the end point will produce a much larger change in the location of the center of the circle (and, hence, the middle of the arc). The magnification effect is large enough that rounding error in a number can produce out-of-tolerance cuts. Nearly full circles are outrageously bad, semicircles (and nearly so) are only very bad. Other size arcs (in the range tiny to 165 degrees or 195 to 345 degrees) are OK.
Here is an example of a radius format command to mill an arc: G17 G2 x 10 y 15 r 20 z 5.
That means to make a clockwise (as viewed from the positive Z-axis) circular or helical arc whose axis is parallel to the Z-axis, ending where X=10, Y=15, and Z=5, with a radius of 20. If the starting value of Z is 5, this is an arc of a circle parallel to the XY-plane; otherwise it is a helical arc.
----------------------------------------------------------------
3.5.3.2 Center Format Arc
In the center format, the coordinates of the end point of the arc in the selected plane are specified along with the offsets of the center of the arc from the current location. In this format, it is OK if the end point of the arc is the same as the current point. It is an error if:
· when the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than 0.0002 inch (if inches are being used) or 0.002 millimeter (if millimeters are being used).
When the XY-plane is selected, program G2 X- Y- Z- A- B- C- I- J- (or use G3 instead of G2). The axis words are all optional except that at least one of X and Y must be used. I and J are the offsets from the current location (in the X and Y directions, respectively) of the center of the circle. I and J are optional except that at least one of the two must be used. It is an error if:
· X and Y are both omitted,
· I and J are both omitted.
When the XZ-plane is selected, program G2 X- Y- Z- A- B- C- I- K- (or use G3 instead of G2). The axis words are all optional except that at least one of X and Z must be used. I and K are the offsets from the current location (in the X and Z directions, respectively) of the center of the circle. I and K are optional except that at least one of the two must be used. It is an error if:
· X and Z are both omitted,
· I and K are both omitted.
When the YZ-plane is selected, program G2 X- Y- Z- A- B- C- J- K- (or use G3 instead of G2). The axis words are all optional except that at least one of Y and Z must be used. J and K are the offsets from the current location (in the Y and Z directions, respectively) of the center of the circle. J and K are optional except that at least one of the two must be used. It is an error if:
· Y and Z are both omitted,
· J and K are both omitted.
Here is an example of a center format command to mill an arc: G17 G2 x 10 y 16 i 3 j 4 z 9.
That means to make a clockwise (as viewed from the positive z-axis) circular or helical arc whose axis is parallel to the Z-axis, ending where X=10, Y=16, and Z=9, with its center offset in the X direction by 3 units from the current X location and offset in the Y direction by 4 units from the current Y location. If the current location has X=7, Y=7 at the outset, the center will be at X=10, Y=11. If the starting value of Z is 9, this is a circular arc; otherwise it is a helical arc. The radius of this arc would be 5.
In the center format, the radius of the arc is not specified, but it may be found easily as the distance from the center of the circle to either the current point or the end poi
-
Hi Dave and All
I have been following this, because I know what you are referring to and have seen it myself.
I have at last had the time to sit down and eliminate exactly what settings etc seem to give rise to this.
The answer is a combination of the replies from several members on this post.
The 'problem' is indeed the 'Reversed Arcs in Front toolpost' setting and from what I have seen Daves lathe is front toolpost, so this is undoubtably set.
This whole subject only arose because Dave and I found that Mach speeded up in cutting G2 / G3arcs. Hood found that this only occurred when using I and K to define arcs so Dave started experimenting with R.
I used to have problems with R defined arcs, to the extent that I stopped using it altogether and just used I and K.
I now realise that at the time my lathe was set on the default of 'Reversed Arcs in Front toolpost' in the configuration.
Because G2 and G3 gave me the opposite of what I required, I later discovered this option and de-selected it, to properly fit my lathe, which is slant bed 'right hand co-ordinates' ie. X values decrease as the tool moves toward the spindle from the rear, G2 is CW and G3 is CCW.
In my trials what I found, was that with 'Reversed Arcs in Front toolpost' DE-SELECTED, both methods worked properly and produced the desired arc.
However, when I selected this 'Reversed Arcs in Front toolpost' option I found that parameters I and K still worked properly but R threw up 'major arcs, in the image generation.
The R values are not signed so by default should be positive, 0 - 180 degrees according to the linuxcnc bible entry. However everything is relative, which cartesian co-ordinates system is the standard referring to, right hand or left hand?
Sure enough, if you sign the radius as negative, you produce the desired arcs again using R
I have taken screen shots of the same piece of code using both positive and negative R values with 'Reversed Arcs..' set
The code is in the screenshot so I won't repeat it.
Incidentally, re
I used to use R with a Fanuc turning center and the Fanuc has no way to define major or minor arcs, yet always seemed to be the right one. Fanuc must have some kind of intelligent logic to it's arc definition I guess.
According to my Operators Manual, Fanuc O series controllers at least, will not allow an arc which exceeds 180 degrees in a single code block when using R, so it looks as if it will always picks the 'minor arc' path. It may throw an error if it approaches 180 also.
Thank you all for your contributions, on the basis that hard gained knowledge stays with you the longest, I don't anticipate any future confusion on my part over programming arcs under Mach!
regards
Melee
-
Melee,
Thanks for posting additional clarifications. What is important is understanding what the controller,
in this case Mach, will do with posted code. Like any language you have dialect which can create interpretation
problems. There will be times, were multiple arc's are present and no "single click"of a setting will do the fix. When that happens, there may be no choice except to modify the code. Hopefully this thread will provide for addressing the issue. I will make another posting about the R value which was written by Smid.
RICH
-
I've come very late to this post, but the answer is to use +R or -R depending on which way you want the arc to go.
If somebody hase already come up with this, I apologise, I haven't read right through.
-
I unchecked the "Reversed arcs in front toolpost" box and it all changed. The arcs, signed with an R, are all minor arcs now, less than 180 degrees. And, funny enough, the G2/G3 directions now are correct. Before when hand coding I always got the arc direction wrong the first time and had to switch it from clockwise to anti etc.
DaveA.
-
DaveA,
I, just like you, was not satisfied with the replies given in here. There will be a tutorial on arc programing for the lathe that will be posted in the Members Doc section.
RICH
-
DaveA,
I took some time and wrote a some info on arc motion. Have a look, here is the link:
http://www.machsupport.com/forum/index.php/topic,11932.msg76353.html#msg76353
Feel free to comment, good / bad / ugly ;D
RICH
-
Very nice Rich, you have it covered very well. Odd, I would think that the front toolpost would be typical for most Mach lathe conversions, yet for that setup you have to have reversed arcs in front toolpost checkd for the arcs to be the correct direction, i.e. G2 is clockwise etc. It tripped me up for a long time until this whole arc issue came up and it was answered. Anyway, thanks again Rich.