Hello Guest it is March 28, 2024, 07:16:14 AM

Author Topic: Problem with G42 cutter radius compensation  (Read 24298 times)

0 Members and 1 Guest are viewing this topic.

Problem with G42 cutter radius compensation
« on: December 17, 2013, 12:31:53 AM »
I am trying out Mach3 to see how it runs and I have a very puzzling problem with a simple program I wrote to test circular iterpolation (G2, G3) and cutter radius compensation (G41, G42).
 
Tool 1 is in the tool table with a diameter of .250" and a length compensation (offset) value. (I have tried reducing the cutter diameter to .125" but it makes no difference.)

The program (Below) runs perfectly without any radius compensation call. Cutter length compensation/offset (G44) functions just as I would expect.
(See the attached picture.)

With a rad comp call (G42) inserted in block N140 as shown, the program executes perfectly down to block N120 but then, instead of feeding in to the first side cutting alignment as I would expect, it wants to move off to a point somewhere around X 13.000 Y6.500 showing a trace on the tool path screen in a colour that looks like grey - which in itself is confusing as it's not any colour designated for a move.

At this point I have to abort the execution of the program.

According to the tool path screen, it then moves back to the end of the first side (X-.550 Y.850), again in the grey colour. After that I can't tell what it wants to do as a whole lot of large interconnected arcs or loops appear on the plot in white (The 'Enhanced' colour (?) I have no idea what 'enhanced' means and I can't find any documentation about it.).

Does anyone have any clues as to what is happening?

N10 (PROFILE PROGRAM)
N20 G90 G70 (ABS, INCH PROGRAMMING)
N15 T1 M06 (CALL AND SET TOOL 1)
N30 G00 X5.000 Y1.550 (X,Y OFFSET VALUES OF START POINT)
N40 G92 X0 Y0 (RESET ORIGIN TO PART ZERO)
N50 G44 G00 X-.550 Y.225 Z.050 (MOVE TO 1ST HOLE POSN)
N60 G01 Z-0.250 F3.0 M3 (DRILL FIRST HOLE)
N70 G00 Z.050 (CLEAR CUTTER)
N80 X5.750 (MOVE TO 2ND HOLE POSN)
N90 G01 Z-0.250(DRILL SECOND HOLE)
N100 G00 Z.050 (CLEAR CUTTER)
N110 X6.000 Y1.200 (SAFE POSITION TO START PROFILE)
N120 G01 Z-.200 (MILL TO DEPTH)
N140 G42 Y.850 F6 (CUT TO SIDE WITH RAD COMP)
N150 X-.550 (CUT 1ST SIDE)
N160 Y.675 (CUT TO START OF 1ST ARC)
N180 G3 Y-.225 I0 J-.425 (CUT ARC)
N190 G01Y-.400 (CUT TO 2ND SIDE ALIGNMENT)
N200 X5.750 (CUT 2ND SIDE)
N210 Y-.225 (CUT TO START OF 2ND ARC)
N220 G3 Y.675 I0 J.425 (CUT 2ND ARC)
N230 G00 Y1.200 (CUT OUT TO SAFE POSN)
N240 Z.050 M5 (LIFT CUTTER, TURN OFF SPINDLE)
N250 G40 G49 (CANCEL RAD AND LENGTH COMP)
N260 G92.1 (RESET COORDINATES TO MACHINE)
N270 G00 X0 Y0 Z0 (MOVE TO MC ZERO POSN)
N280 M30 (END, REWIND)


Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Problem with G42 cutter radius compensation
« Reply #1 on: December 19, 2013, 12:39:44 PM »
Try it this way.

N10 (PROFILE PROGRAM)
N20 G90 G91.1 G20 (ABS, INCH PROGRAMMING)
N30 G00 X-.950 Y-.400 (Move to Point of Origin lower left of object)
N40 T1M6 (Tool #1 = .125)
N50  G00 X-.550 Y.225 Z.050 (MOVE TO 1ST HOLE POSN)
N60 G01 Z-0.250 F133.0 M3 (DRILL FIRST HOLE)
N70 G00 Z.050 (CLEAR CUTTER)
N80 X5.750 (MOVE TO 2ND HOLE POSN)
N90 G01 Z-0.250(DRILL SECOND HOLE)
N100 G00 Z0.050 (CLEAR CUTTER)
N110 X6.000 Y1.200 (SAFE POSITION TO START PROFILE)
N120 G01 Z-.200 (MILL TO DEPTH)
N140  G42 Y.850  D1 F160 (CUT TO SIDE WITH RAD COMP)
N150 X-.550 (CUT 1ST SIDE)
N160 Y.675 (CUT TO START OF 1ST ARC)
N180 G3 Y-.225 I0 J-.425 (CUT ARC)
N190 G01Y-.400 (CUT TO 2ND SIDE ALIGNMENT)
N200 X5.750 (CUT 2ND SIDE)
N210 Y-.225 (CUT TO START OF 2ND ARC)
N220 G3 Y.675 I0 J.425 (CUT 2ND ARC)
N230 G01 Y1.200 (CUT clear of object with comp)
N240 Z.050 M5 (LIFT CUTTER, TURN OFF SPINDLE)
N250 G40 G49 (CANCEL RAD AND LENGTH COMP)
N270 G00 X-.950 Y-.400 Y0 Z0 (MOVE TO Point of Origin)
N280 M30 (END, REWIND)
Re: Problem with G42 cutter radius compensation
« Reply #2 on: December 20, 2013, 03:42:54 AM »
Many thanks for your reply and I have good news and more questions. First the good news: When loaded and the tool path is generated it showed a normal trace with a blue line for the actual part profile and a white line just outside that - which I take to be the compensated path (?)
So far so good.
(There was a doubled up Y statement on block N270 on the first try but once I deleted one of them it did the above.)
When I tried a physical run it forced an Estop. As far as I can see that was because N30 wants to send both the X and Y axes to a negative position when starting with the coordinate system set to machine zero. Obviously it can’t physically do that it caused an Estop.  I guess you are assuming that the coordinate system has previously been manually set to the workpiece zero? Once I offset the DROs to a position somewhere in the middle of the machine envelope, it ran fine.

Just a comment, I’m a bit puzzled by the initial XY values you used in N30 as I can’t work out what these values represent or how you arrived at them.

You’ve moved the tool call a couple of lines down to N40. Is this re-ordering significant?

In N20 you changed G70 to G20. As far as I have read, these are interchangeable but G70, according to the manual, is the preferred usage. Is this change significant?

You also added G91.1 which sets the I and J values of a G2/G3 call to incremental. I already have that set in the General Logic Configuration dialogue as the default condition. Is it necessary to restate it in the program or were you just being safe? Certainly the basic program without any G42 runs perfectly.

I notice it says in the manual in that section that, ”Incorrect settings of this mode will generally result in large incorrectly oriented arcs in the tool path display.” Which is certainly what I have been seeing.  I’m still wondering why they are traced in white and just what that means.

You’ve also specified a diameter of .125” for Tool #1 when there is enough approach to allow a diameter of up to .250”. Is this a maximum allowable diameter in your view or did you just follow what I wrote in my post?

In N140 you have inserted a D value. This where I find Mach3 very poorly documented. The whole tool table, tooling numbering, ‘D’, ‘H’ and ‘P’ words, ‘slot’ numbers, etc. explanation is very vague and confusing. I am not at all clear whether, after calling a tool, you still have to program a D value, or alternatively, a P value. I’ve see other posts querying this too. It seems you don’t have to program an H value for length compensation to operate though. Or do you?

I am used to a language (Fagor controls) that, once you’ve called a tool, immediately uses the length and diameter of that tool when any compensation is invoked.  This is without a tool changer. With a tool changer the programmed tool values aren’t used until an M6 is programmed. This is what Mach3 seems to do which is OK as long as you know. Is this correct?

Is a programmed D value essential for rad. comp. to operate? I did try this myself before but it didn’t seem to help. Does it need to be in the same block as the T# call or maybe the G42/41 call?

One last thing, out of curiosity, you changed the feed rates dramatically. Was this deliberate?
All in all you’ve given me something to work on so thank you for that. And thanks in advance if you are able to help with some of my further questions.

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Problem with G42 cutter radius compensation
« Reply #3 on: December 20, 2013, 10:26:34 AM »
The G91.1 in the safety b;lock of the program is to make SURE that inc IJs are set correctly. IF the last program you ran set it to ABS then it wouls still be active as ABS mach3 does NOT change it back for you at end of program. When programming you should ALWAYS have ALL  the safety code in the block in order to makes SURE Mach3 is set correctly and there are NO surprises when it runs.  Failing to do this is MOST of the problem one sees with crashes "Improper modes still set".

G20 is a habit and is more common than G70.

N30 is to establish a point of origin for setup propose. Not required but sdoes give one a point of reference to align the machine to the part to be cut. NOT required.

T#1 is just a number I picked based on what I see you had programmed. Normally one would leave some wiggle room for changing out to a different tool diam if needed. IF your approach is too close then you cannot go larger on tool sizes.

Also you have to program the tool radius so that it does not go larger that the smallest inside radius of the part or else it will GOUGE and normally mach3 would not let it run. It would error on loading the program.

The D parameter sets the OFFSET based on Tool #. In this case Tool#1 AND the tool MUST be setup in the tool table.  The P value wouls set the tool radius based on a number value  P0.125  would mean a  .125" tool .

IF you leave those parameters off then Mach3 will use the LAST known tool # call.

Rule of reason says don't take the chance that something is wrong just  use the parameter calls with G42/3 SAME with G43 use the H call.

All parameters SHOULD be used at the time of the G42/G41/G43 calls   G41 D14  ,   G43 H3 etc

Overveiw,

D paramter sets the TC based on the Tool#   D1  = Tool #1
P parameter stes the TC based on the value of P   P.0125 = Tool value of 0.125"
NONE = Uses the last known Tool# values
H sets the Height based on the Tool #

The feedrate change came after a calculation that it would take all day to review that code running at such a slow feedrate (;-)

(;-) TP
« Last Edit: December 20, 2013, 10:32:54 AM by BR549 »
Re: Problem with G42 cutter radius compensation
« Reply #4 on: December 21, 2013, 07:12:52 AM »
Once again, many thanks for your detailed reply. My background is one of production engineering although I’ve been retired for quite few years now. I’m now getting back into playing with a CNC router/mill I built as a hobby.

My main experience was with various models of Fagor controls and over the course of the years I have written over 500 production programs - all manually programmed- so I have a pretty fair idea of how G code commands should be executed. Or at least I used to and naturally, mainly as Fagor decreed how things should work.
Right now I’m trying to work some of the rust out of my CNC skills.

Obviously different controls have their own way of doing things within the general ISO standard, which is to be expected. I am trying to work out Mach3’s and what has surprised me so far is the lack of detailed documentation of the various functions so it seems that this is going to take me a fair bit of time.

I understand what you are saying about ‘safety programming’ and now I have learned a new thing and that is;
Mach3 doesn’t reset all the parameters to the default values on loading a new program.
Whether this is good or bad is debateable but now I know this, I can program accordingly. I’ve sort of worked out that tool selection is persistent from part program to part program so I’ll have to watch that.

I also am used to using G20 but used G70 because the Mach3 docs said it was preferred.

Understand your comment re the values in N30. More or less what I assumed.

I’d allowed enough (plus a small margin) to allow the use of a .250” dia. tool and in fact when I ran your code that is what T1 was set to and there was no problem.

Fair enough with the feed rate change. I’m kicking myself for not deleting the drilling part before I submitted the program listing as it’s not relevant to the issue and just takes more time.

I know what you are saying about always using the parameter calls to be sure but I guess I’m a bit obstinate and don’t want to do this - even if it’s no great problem to include them. Computers are logical things and their programs should be too. This is where I’m really frustrated in the documentation. The programmers should be telling us exactly what the software expects, not leaving the users to work it out or to come up with workarounds. It should be a case of: The parameters either MUST be programmed or they don’t need to be. No ‘should’ or ‘best to’.

Thanks for the overview section. I have studied the “Mach 2 G and M Code Language Reference” section of the “Using Mach3 Mill” guide (A confusing mismatch of versions here to start with.) and I get the idea of using the various D, P and  H ‘words’.
In fact, I fully appreciate that having the functionality of these words can give you a great deal of flexibility in programming. However, when an example is given in the “Cutter Compensation” section (9.2.1) none of these words are used and there is not even a tool call. It also refers to a diagram number that doesn’t exist so this explanation doesn’t really give much help on the finer details of invoking rad. comp.
Sorry for being so critical but I’m just making the point that with the documentation the way is, it’s a hard slog to work stuff out by yourself. I’d still like to know why my program behaves the way it does and with the ideas you’ve given me, I’ll work my way through it until I do.

For now, I’m going away for Christmas tomorrow and won’t be back for a week or two so I’ll have to leave that pleasure for a little while.

Thank you again for your help and I hope you have a happy and healthy Christmas and New Year.

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Problem with G42 cutter radius compensation
« Reply #5 on: December 21, 2013, 07:30:46 AM »
I think the G20/21 is the preferred one rather than the G70/71.
Or at least that is the way I read it
"See also G20/G21 which are synonymous and preferred"

Hood

Offline ger21

*
  • *
  •  6,295 6,295
    • View Profile
    • The CNC Woodworker
Re: Problem with G42 cutter radius compensation
« Reply #6 on: December 21, 2013, 09:22:04 AM »
Comp in Mach3 has several bugs. Based on your code, it appears that it doesn't like G92 (or G52)
I'm not sure if any of the bugs are actually documented anywhere. The only ones I've ever really encountered where with specific geometry that the comp just wouldn't deal with.
Basically, if you do a proper lead in and lead out, it works about 99% of the time.

As for the manual, (and Mach3 to an extent), it is what it is. The manual was written by a third party many years ago, and is woefully out of date. I believe that the comp section was taken directly from the LinuxCNC Manual (LinuxCNC was the basis for mach3's trajectory planner)
The manual has never been updated, and never will be. Mach3 is currently in a similar state. Over the years, it evolved into such a complex package that bug fixes become nearly impossible to do without adding more bugs. For the last few years, the programmers have been working on Mach4, which is a complete re-write.

One thing about the G91.1 that most people don't realize.
It MUST be on a separate line from G90 or G91. They are in the same modal group, and if they are both on the same line, the first one will be ignored. Try this as a test, using MDI.

Type G91 and hit enter.
Type G90.1 and hit enter.
Type G90 G91.1 and hit enter.
You'll notice that you're still in G91 (incremental) mode.
Gerry

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

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Problem with G42 cutter radius compensation
« Reply #7 on: December 21, 2013, 09:35:26 AM »
AH the great thing about Gcode standards is that there are SO MANY of them to choose from.

The point I was making about the Parameter calls IS if you include them in the Gcode there is NO guessing what was meant from the operators standpoint. It is clearly defined.

IF you leave them out then from the operators view it is a guessing game and THEY HAVE TO HOPE all is well and just push the green button. Operators can be very valuable in fine tuning the written Gcode . THEY are the ones that SEE the interaction of code and motion first hand. AND sometimes the CRASH that follows(;-). 

Fagor also had its pitfalls (;-) and bad habits. It all seems normal when that is what you are programming in. 

Been THere done that,

Good catch Gerry(;-)

(;-) TP
Re: Problem with G42 cutter radius compensation
« Reply #8 on: December 21, 2013, 09:52:18 AM »
Mach3 tries (though does not always succeed 100%) to adhere to the G-code usage as defined in this book:

http://www.amazon.com/CNC-Programming-Handbook-Third-Edition/dp/0831133473/ref=sr_1_1?ie=UTF8&qid=1387637394&sr=8-1&keywords=Smid+CNC+Programming

This book is what the Mach3 (and v4) authors treat as their "bible" when it comes to G-code usage and machine behavior.

Regards,
Ray L.
Regards,
Ray L.

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Problem with G42 cutter radius compensation
« Reply #9 on: December 21, 2013, 10:31:54 AM »
Gerry testing HERE from the MDI and GCODE program

G90 G90.1  switches to Abs IJ

G90 G91.1 switches to Inc IJ

(;-) TP