Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: wincastle 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)
-
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)
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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.
-
Gerry testing HERE from the MDI and GCODE program
G90 G90.1 switches to Abs IJ
G90 G91.1 switches to Inc IJ
(;-) TP
-
Ray , Mach4 " may " get close but Mach3 can be miles away from matching Smids examples.
Just a thought, (;-) TP
-
Gerry testing HERE from the MDI and GCODE program
G90 G90.1 switches to Abs IJ
G90 G91.1 switches to Inc IJ
(;-) TP
Try this
G90 G90.1
G91 G91.1
And you'll end up in G90 G91.1. Not what you're expecting.
-
AH BUT if you do it this way it works fine here
G91.1 G91
G90.1 G90
I say BUG, (;-) TP
-
No, it doesn't.
Do this:
G91.1
G91
G90.1 G90
You'll end up in G91.1 and G90.
It's not a bug. They are all in the same modal group, and when more than one are on the same line, only the last one on the line is read.
-
AH I see what you mean I was just looking at the mode indicators which are not complete .
BUT it is still a bug as it SHOULD error IF it cannot complete the instruction as programmed.
(;-) TP
-
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
You are right. I had it back to front.
-
Comp in Mach3 has several bugs. Based on your code, it appears that it doesn't like G92 (or G52)
I've been carefully reading the maual to see if I can make sense of this problem and maybe it's contained in the first paragraph regarding G92 Offsets.
10.7.27 G92 Offsets - G92, G92.1, G92.2, G92.3
See the chapter on coordinate systems for full details. You are strongly advised not to use
this legacy feature on any axis where there is another offset applied.
Is it that because I used G92 to reset the origin values, and then applied G42, which is another offset, that the system throws a wobbly? It sounds like it is as rad. comp worked fine with BR529's program without G92.
It also would explain why tool length comp works without a problem in my original program as the Z axis was not offset.
If the above is the case then it's a pretty big bug indeed.
You mentioned G52 although I didn't use it. As far as I can work out, G52 seems to be similar to G92 but uses relative values instead of absolute.
Is this right or have I misunderstood this?
I'll have to experiment with it to see if it is compatible with G41/42 codes although it's less convenient than using absolute values as with G92.
Maybe G42 will work with fixture offsets? (G54 - G59) There is a warning in the manual not to call these while cutter compensation is active but is silent regarding the reverse situation.
I take on board your comments regarding the state of Mach3.
They don't exactly make me very enthusiastic to part with money for what is apparently a legacy program.
-
You are strongly advised not to use this legacy feature on any axis where there is another offset applied
Smid says the same and in his book talks about about it but one must read a number of pages. He suggests use of of G52 which replaced
the lagacy / old command. The G52 provides a local coordinate system associated with the active work offset ( G5x).
So not sure it's realy a bug but rather one can create problems if not used correctly.
FWIW ......by an unsharpened tack :) on gcode,
RICH
-
I think I have kind of sorted out the radius compensation problem and the following may help others.
To sum up what I have learned - or think I have learned.
Radius compensation (G41, G42) will not work with either G92 or G52 active.
Both give the same result and that is, the cutter path goes berserk with rad. comp active.
G92 allows the resetting of the current position to new coordinate values.
G52 does more or less the same in a slightly different way.
There is a warning in the G92 section about not using other offsets in conjunction with it but there is no such warning for G52.
However, the manual does say, “G52 and G92 use common mechanisms in Mach3 and may not be used together.”
From these two statements it seems logical that if you can’t use rad.comp. with G92 then you can’t use it with G52 either and this is what I found.
What does work is using Work Offsets ( G54, G55, G56, G57, G58, G59).
The use of these doesn’t seem to upset rad. comp. and all works as you would expect.
There is a caution not to call a Work Offset code while rad. comp. is active but that’s not hard to avoid.
By entering the offset values for your machining reference point (part zero) into the Work Offsets table and calling the relevant code, you can offset the coordinate system to part zero.
By leaving Fixture #1 (G54) with all its axis values at zero, it can then be used to reset the coord. system back to the machine values.
The program below seems to work with rad. comp. without a problem and leaves the machine at the home position with all DRO’s reading zero.
Fixture #2 has the “part zero” X and Y offset values entered into it.
Fixture #1 effectively cancels the offsets, restoring the coordinate system to machine values.
In this case the Z offset is handled by cutter length compensation (G44) but it could be handled by the Work Offset function.
N10 (PROFILE PROGRAM USING FIXTURE OFFSETS)
N20 G90 G91.1 G20 (ABS, IJ RELATIVE, INCH PROGRAMMING)
N40 G55 (SET OFFSET TO FIXTURE #2)
N50 T1 M06 (CALL AND SET TOOL 1)
N110 G0 X6.000 Y1.200 (GOTO POSITION TO START PROFILE)
N120 G44 Z.100 M3 (LOWER TOOL, START SPINDLE)
N130 G01 Z-.200 F6 (MILL TO DEPTH)
N140 G42 Y.850 F60 (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 OUT TO SAFE POSN)
N240 G00 Z.050 M5 (LIFT CUTTER, TURN OFF SPINDLE)
N250 G40 G49 (CANCEL RAD AND LENGTH COMP)
N260 G54 (SET OFFSET TO FIXTURE #1=X0 Y0 Z0)
N270 G00 X0 Y0 Z0 (MOVE TO MC ZERO POSN)
N280 M30 (END, REWIND)
Thanks to all that have contributed.
-
Further to my last - or what I though twas my last - post, I have spent a lot of time tryig to get cutter radius compensation (G42/G41) working reliably. I though that I had it sorted and that radcomp would work with fixture offsets (G54 ... G59).
Radcomp worked sometimes, but not others with the identical setting in the offset tables. It appears that there is some problem with registers or parameters not resetting the way they are supposed to. This is what I have noticed in some of the comments, that radcomp works, "Most of the time." and it does
There is a rather cryptic comment in the Mach3 G Code Ref document under the Work Offset Coodinate System section which says,
" It is an error if: One of the these G-Codes is used while cutter radius compensation is on."
This is a bit ambiguous but it seems, in the light of what Ii have experienced, that it's pointing to the fact that radcomp is incompatible with fixture (or work) offsets.
After many hours of experimentation, I have come to the conclusion that radcomp will not work in conjunction with ANY of the Mach3 offset functions.
I have found that the only way to use radcomp with Mach3 is to manually reset the DRO's to the origin (zero) point that you want to use and then it works perfectly.
-
I have found that the only way to use radcomp with Mach3 is to manually reset the DRO's to the origin (zero) point that you want to use and then it works perfectly.
I use comp all the time, and I can tell you that it doesn't work ALL the time. You may run across cases where comp won't work with specific geometry. It's rare, but I've seen it happen 2 or 3 times. In one case I had mirrored profile cuts, and comp worked on one, but not the mirrored one.
-
I use comp all the time, and I can tell you that it doesn't work ALL the time.
[/quote]
When you say "comp", I'm assuming you mean radius compensation.
What offsets, if any, do you use in conjunction with radcomp?
-
Yes, G41/G42.
I only work in G54.
-
I only work in G54.
Sorry to keep asking questions but when you say you 'only work in G54', which is the start-up default, do you mean that you don't use offsets at all and just leave the control at the default or:
Do you you assign offset values to G54 and use this code to offset the origin?
If you assign values:
Do you use G10 to pass the values to the offset table or do you enter them directly into it?
How do you the cancel the offset to return to machine coordinates?
-
Yes, I don't use offsets at all. I have a router, which has two fences along X zero and Y zero. Most of my work gets mounted at the origin. The fences are machined after homing the machine, so they are in a repeatable position. My X and Y offsets are always left at zero, so you could say that I actually am always working in Machine coordinates for the X and Y axis.
My table also has a grid of threaded inserts, and I have the layout of my table saved as a template in AutoCAD. If I want to cut a part at a location other than the origin, I can draw it exactly where I want to cut it. Occasionally, I'll mount my stock at the origin and drill mounting holes, then mount it at another location on the table to machine it.
I have occasionally mounted a fixture for special projects, and then actually do use the G54 offset, but very rarely. When finished, I just reset the X and Y offsets to zero.
-
Thanks for the detailed reply.
I also have my table with threaded inserts in a grid and I have sometimes used simple XY fences as a quick and easy work location method so I’m with you on that.
From the gist of what you are saying, even when you have used G54 to offset the origin, you may not have used radcomp for those jobs so the problem may not have arisen(?)
Even if you did, it occurs to me that it’s a possibility that G54 is a bit of an exception in terms of offset clashes. Up until now I have only used G54 to reset the X and Y offsets to zero after using G55, etc. to offset the origin.
I will try using G54 to actually offset the origin and see what happens with radcomp.
In general, it seems likely to me that when Mach3 was first written, tool radius compensation was not on the ‘to do’ list but was added at a later date, or at least was a bit of an afterthought - even a bit of a 'slam dunk'. The aberration you found when using mirrored programming is another indication of this.
This makes sense when you consider that a lot of CAM packages don’t require the use of radcomp but do use length compensation (length offset) which in Mach3 works without a hitch.
-
G41/G42 work fine while in G54, regardless of what the offsets are. I think this is because G54 is the default coordinate system, so there is less going on internally.
Even when I'm working away from the origin, I still use G41/G42 most of the time. It's just what I'm used to. I program and run big industrial routers in my day job, and we use radius comp 100% of the time. We get tools sharpened, and never really know what size tool might be in the machine. With radius comp, it doesn't matter. I can pro0gram a part tomorrow, and cut it next year, and it will cut correctly regardless of what size too is in the machine.
Up until now I have only used G54 to reset the X and Y offsets to zero after using G55, etc. to offset the origin.
Not exactly what you mean here. Going from G55 to G54 doesn't "reset" anything, it changes to a different coordinate system with a different origin.
The aberration you found when using mirrored programming is another indication of this.
I wasn't using mirrored programming. I was creating gcode from mirrored geometry in my CAD program. Basically two mirror image identical profiles. Since both were conventional cut, it was as if the direction was reversed on one profile. For whatever reason, the G42 worked fine on one, but didn't work on the mirror image part.. I ended up offsetting the profile in my CAD program and not using G42 for this one part.. Not sure if you follow me, as it's a bit difficult to explain.
I've seen another instance where the toolpath just veered off and traveled away from the part in a very large arc.
In both cases, it seems that Mach3 had trouble calculating the offset at transitions between certain segments. In my case, the geometry was all tangent arcs and lines, and should have been a simple case. But it just wouldn't work.
But as I said, I still use it all the time, and it almost always works fine for me.
-
G41/G42 work fine while in G54, regardless of what the offsets are. I think this is because G54 is the default coordinate system, so there is less going on internally.
This is what I was theorising so I'll have to give it a go.
We get tools sharpened, and never really know what size tool might be in the machine. With radius comp, it doesn't matter. I can pro0gram a part tomorrow, and cut it next year, and it will cut correctly regardless of what size too is in the machine.
If you look back at my history, that is my experience too. I was working with fairly high precsion metal parts and radcomp could be used to get the final bit of accuracy as well as allowing the use of resharpens without having to reprogram.
Going from G55 to G54 doesn't "reset" anything, it changes to a different coordinate system with a different origin.
My undersatnding us that by programming "G55 X5 Y3" these two values are stored in parameters 5242 and 5243 respectively and this condition becomes current.
Thus, when programming a block such as "G0 X10 Y10" the control adds these stored values to the commands such that it moves to a machine coordinate 'real world' position of X15 Y13. The DRO's show X5 Y3.
What I have been doing is, at the end of the program, programming G54 (which has values of X0,Y0 in parameters 5222 and 5223) to return programming to, effectively, machine coords and in my terminolgy, resetting the coordinate system to machine coordinates. Certainly G54 appears on the status line ( as it does when you first load Mach3) and the DRO's show machine values again. With G54 current, no offset values are added to the axis commands, or at least a value of zero is added so it amounts to the same thing.
Can you see a problem here?
Not sure if you follow me, as it's a bit difficult to explain.
Sort of but in any case, in a robust program, it shouldn't happen. I have had a kind of similar experience in that I machined a simple rectangle using origin offsets and radcomp and it ran perfectly but the next job ran once and then went crazy.
I've seen another instance where the toolpath just veered off and traveled away from the part in a very large arc.
This is what I've been getting - lots of big loopy arcs in white which make no sense whatever that I can see.
Also when it worked properly the 'crosshairs' which show the origin behaved as expected but when it played up, the crosshairs were at a point way off the table at a negative X and Y position while it was drawing a 'shadow' version* of the part at a position in a positive X and Y position with big loops around it.
I say 'shadow' because this part outline was in grey which I think is the compensated path colour(?) None of it made much sense.
*This was after showing a part in the correct position in blue - before radcomp was invoked.