Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: jpike10 on October 16, 2011, 06:53:42 PM
-
I have a question about cutter comp in mach3.
I wrote a test program to cut a 1" circle with a .5 endmill
Useing centerline of the tool. So I should not need Any comp,
Only to add or subtract from the tool diameter. So under tool 1 in the tool
Table it was all zeros. It cut a 1.5" diameter hole. So I comp'd
It .250 and it cut the 1" hole. I should not have to put any comp in.
Here is the program I used, its pretty simple.
G90G54G0x.12y0.0
Z.5g43h01
Z.1
G94 g1 z-.1f10
G41 x.25D01
G17G3 I-.25 J0.0
G40 x.125
G0z.5
M30
Should I add a g40 at the top to cancel any comp??
-
If you program for the tool centre then you need to compensate for its radius.
I think your problem is in the X start position:
G0 x.12 y0.0
Change that to:
G0 x0 y0
And you should get a 1" hole with:
G3 I-.25 J0
Dan
-
Cutter comp requires a lead-in move in order for it to know what direction the tool path is moving . . in order to determine which side to offset to.
The lead-in has to be of sufficient length (one diameter or one radius, I don't recall which) or you will get an error.
Once the direction is established, you can then get on with your cut. In the case of a small hole or a hole you want to cut by spiralling down, youcan make the lead-in move above the part and then go down in Z to make your cuts.
I would advise that you put all of your setup G-codes (G17, etc) early and not spread them thru your code. Have them done before you enter cutter comp. I would think you need a diameter in the tool table for whatever tool you are compensating for. If you have a 'tool path' (meaning the path has a specific tool size already taken into account), then the tool table diameter would be the amount of adjustment you want and not the actual tool size . . . or more accurately twice the adjustment since it assumes a radius adjust and not diameter . . . if all that makes any sense . . .
I have had the best luck by putting cutter comp on the same line with the lead-in move. Lastly, cutter comp can behave erratically if you have any axis scales set to -1 for mirroring a part.
-
The leadin move is to allow MACH room to physically comp the actual comp value. G41/42 sets the direction to comp on the move. The direction required depends on where you are in relation to the direction needed when you start the move.
Just a thought, (;-) TP
-
Symantics at work here. G41/42 does not set direction, it chooses compensation on the right side or left side of the path. I suspect that is what you meant by 'direction'? Mach needs the lead in to determine direction so that it can determine left from right . . . because that is relative to the direction of travel . . . and it needs to know that before the first actual toolpath move so that the comp can be in place by then . . . . so the comp cannot be calculated until direction is established . . . by the lead-in . . . . so that Mach knows which side to offset on . . . . . based on the choice dictated by G41 or 42 . . . . or at least so sayeth the Mach documentation.
The actual comp value is taken from the tool diam in the tool table of whatever tool is active or chosen by the 'D' parameter unless the other parameter (I think it's 'P') is used to over-ride the tool table entry.
However, the length of the lead-in could be required for the reason you mentioned. You will get and error if the lead in is not long enough. The message seems to change depending of if the lead-in is a straight line, an arc, or if it is Thursday . . . . ;)
I try not to use G41/42 in Mach if possible as it seems a little unpredictable . . often switching sides in the middle of the toolpath . . usually at long arcs . . . . or if it is Tuesday.
-
SO IF I did a lead in away from the part instead of into the part Mach would get it wrong?? So far as I can tell Mach does not care about the direction of the leadin it just needs room to actually do the move. AND it some cases it WILL go out of its way to acutally do the required move in order to get it correct, Arcs in general (bad form to use arcs as leadins).
Your mileage may vary, (;-) TP
-
Hmm....
Mach cutter comp is supposed to work as described by Smid in his programming books. ;)
Sorry can't read, so only look at the pictures in his book.......... :D
RICH
-
I try not to use G41/42 in Mach if possible as it seems a little unpredictable . . often switching sides in the middle of the toolpath . . usually at long arcs . . . .
I use comp for just almost everything I cut, and have never seen it switch sides. But I have seen a bug where the tool just takes off out into space, but it wasn't my part, and it was a profile made up of many short segments, which comp doesn't like.
The message seems to change depending of if the lead-in is a straight line, an arc,
According to the test version Brian posted a few years ago previewing the V4 comp, leadins will no longer be allowed to be arcs. So you might want to stop using that practice now. :)
Mach cutter comp is supposed to work as described by Smid in his programming books.
I don't have the book, but I know that comp works the way I use it. ;)
-
SO IF I did a lead in away from the part instead of into the part Mach would get it wrong?? So far as I can tell Mach does not care about the direction of the leadin it just needs room to actually do the move. AND it some cases it WILL go out of its way to actually do the required move in order to get it correct, Arcs in general (bad form to use arcs as leadins).
I don't see how you would conclude that from anything that I said. It would not matter if your lead in was away from the part, in fact that would not even be unusual. By your logic, there would be no reason for both G41 and G42. Think of a simple square hole that you want cutter comp to enlarge by ,010. If you start off going up the left side of the square with G41 (comp to the left), then you will get a larger hole, however, if you start from the top and move down (i.e. a different DIRECTION), the comp will STILL be to the left and you will get a smaller hole. That's how it works. A detailed description of how and why Mach accomplishes cutter comp is well detailed in MACH's own documentation. I suggest giving that a read.
-
I use comp for just almost everything I cut, and have never seen it switch sides. But I have seen a bug where the tool just takes off out into space, but it wasn't my part, and it was a profile made up of many short segments, which comp doesn't like.
I made the point in an earlier post that the erratic behavior occurs if one or more scales are set to -1 to mirror a part. The I commented again and genralized. Sorry for the confusion.
As to arcs, Mach itself puts arcs in the comped toolpath. And I seem to recall (although I wold not swear to it) that MAch has also put arcs at the beginning. Again, this behavior is not 'normal', but occurs if for example two arcs are not attached to each other and this would be imperceptible during a normal cut, but cutter comp calculates unpredictable results . . like sticking a tiny arc in between the end of one arc and the begining of the unattached arc . . and switching sides.
Never the less, I shal henceforth never use arc intentionally as lead-ins since it is apparently 'illegal' . . . that is on the rare occation that I woudl need to use cutter comp at all.
Good discussion.
-
it IS not ILLEGAL AS IS. Unless that was changed, just not the best idea. Art had it working well in most respects. The real problems are deep in subs where it gets totally lost .
People also don't understand it is not an auto function it has to be planned for and sooner or later the comp has to be unwound from the process OR it mysteriously shows up elsewhere when you are not looking (;-).
Years ago I beat the dog snot out of the COMP testing it in ways I would NEVER even program it just because someone might(;-).
The last series of comp code I tested was really nice. Don't know if it made it to the M3 versions or was held for Mv4.
If you have an example of the comp code switching sides I would love to see it. It would make a good test sample for future testing.
(;-) TP
-
If you have an example of the comp code switching sides I would love to see it. It would make a good test sample for future testing.
I ran these on my office computer which just got updated to XX.50 yesterday and it looks like there have been some fingers in the cookie jar. Comp is even more bizarre now! Now it is switching sides even on connected arcs. This example shows how MACH inserts tiny arcs . . a bonus. Another new behavior is that there is no separation between the original and comp toolpaths, Note the tool diameter and also note the scales. First screen shot is with both axis at -1 scale. Second screen shot only one axis at -1 . . BOOM! That is opposite of what it was doing in the earlier version in the shop. The behavior in the earlier version is also different in that the comp arc started on one side and endied on the other side of one of the long arcs that make up the sides of this part. If I changed the scale from -1 to -.999, it still switched sides, but at a different location on the tool path where I could live with it, so I did that and got the parts cut. As I siad, I do not use comp much at all, but typically, I find that comp seems to work OK on simple unscaled toolpaths, especially closed paths, but if you go 'outside the box' . . . it can get ugly.
I cannot release the G-code on this part. If this occurs on releasable code, I will be happy to provide the code. I understand it is difficult to debug without a repeatable example, sorry. I just came in to add some new video links to my 'mini machining center' thread and thought I'd poke around a bit and see if I could be useful, however I am unsubsribing now. I hope my comments were helpfull, but just do not have time to participate in-depth on forums. :(
(http://www.thecubestudio.com/pictures/CutterComp01.jpg)
(http://www.thecubestudio.com/pictures/CutterComp02.jpg)
-
Without seeing the code, it's impossible to say what's going on, but here's a few things.
1) Setting the scale to -1 doesn't work properly in all version of Mach3 even without comp. Only in the last year has this been fixed to work without comp.
2) From the looks of your toolpath, I'd say that you have duplicate lines of code at your transition points, or very, very small segments at those points that are messing up the comp. I saw this the other day, and it was due to bad g-code, and not comp's fault.