Messages

1

G-Code, CAD, and CAM discussions / Re: More Problems with Radius Compensation G42 / G41

« on: May 10, 2014, 07:29:44 AM »

I've been using G41/G42 from my CAM software for over 15 years. With our router, we rarely use new bits, so we don't usually know what the diameter of the sharpened bit will be when we program the parts. With G41/G42, you don't need to know the diameter, you just need to put it in the tool table.

BR549 seemed fairly definite that radcomp and subroutines are incompatible in Mach3.
So, as you are using CAM to generate your programs does this mean that you aren't using subroutines?

Out of interest, does your CAM also handle the lead-ins and lead-outs required with rad comp or do you have to add these by hand?

2

G-Code, CAD, and CAM discussions / Re: More Problems with Radius Compensation G42 / G41

« on: May 08, 2014, 08:51:12 AM »

The problems with Tool Comp and SUBS are well known in Mach3 AND there is to be NO fix in MACH3.
Mach4 appears to have fixed that problem so far as it CAN run things that make you scratch your head in disbelief.

Thanks for your reply which made things clear. It seems that I had misremembered using rad comp with subs before - I hadn’t. I had used length comp with subs but, as I said, length comp seems pretty bulletproof.

I’ve now made it into one long, simple program and it runs OK.


However, I must tell you that I found your characterisation of the problems with radcomp in Mach3 being “well known” rather surprising. I’m not sure who it’s “well known” to but certainly not to me. I’ve had to work it out myself - and still am by the look of it.

If you read the documentation, which is what you do when you start off, there is no mention of the fact that radcomp is virtually unusable in any reasonable programming way. Quite the opposite. There’s a whole section devoted to how it works with only a couple of vague warnings that it’s not fully implemented.

Again, I’ve spent many hours reading the forums and I’ve never found anyone who was able to state the limitations of radcomp in any kind of authoritive way. I it’s “well known” to anyone, they’ve kept very quiet about it.

Probably the most frustrating thing is that there has been no guidance from the authors of the code themselves. Presumably it’s well known to them but they haven’t bothered to tell the users which would have saved many wasted hours - and no doubt scrapped parts too.

It’s lovely that Mach4 will fix all these problems but its not much use to someone with a problem right now. I’m still using the free demo version and so have no real right to complain but Mach3 is still being offered for sale with no warnings as to its limitations. I find this a bit concerning as I’d be very, very, annoyed if I’d rushed in and paid for a full copy without being warned that a major CNC machining function was virtually unusable.

Imagine buying a car advertised as having a six speed auto only to find later on that it stayed in one gear except on wet days.

This is no question that Mach3 is a unique piece of software at an incredibly low price - and the business model of releasing it in demo mode is fantastic - but for me the experience has been let down by poor documentation and the lack of any kind of factory support. The real worry about all this is that; will the lines of communication from Artsoft be any better with Mach4? I certainly hope they are.

Anyway, until Mach4 is available I’ll just have to program without using subroutines where I need radius compensation but at least now I know that.

3

G-Code, CAD, and CAM discussions / Re: More Problems with Radius Compensation G42 / G41

« on: May 07, 2014, 09:11:25 AM »

Forget using subs and make it into 1 long program and it will work, for some reason cutter comp and subs are not stable.

Even more bad news for radcomp?
I have used programs with subs before with radcomp, obeying all my origin offset protocols that I mentioned, and it ran happily. A nuisance that you can't use work offsets but it did work.

It's really weird, what this is doing. It's as it it's retaining the cordinates in block N100 as some sort of origin position from which to to initiate radcomp but how or why it would do this is rather a mystery

However, I haven't used nested subs before so I'll try getting rid of that first and see how it goes.
I'll let you know how it runs.

I have to say it's very disappointing that such a basic bread-and-butter function as radcomp is so poorly implemented in Mach3. I wouldn't have though that the math involved would be so difficult to get right.

4

G-Code, CAD, and CAM discussions / More Problems with Radius Compensation G42 / G41

« on: May 07, 2014, 03:00:22 AM »

I thought I had radius compensation sorted in Mach3, having successfully run several jobs using radius and length compensation - even along with a G18 interpolation plane change to the XZ plane - without a hitch. What I thought I’d worked out is that as long as you don’t use any other form of offset code (G55–9, G52, G92 etc.) radius compensation would work reliably.

The only offset I now use is a set of XY values manually entered into the DRO’s to offset the machining origin point. Once entered, these values appear, by default, in the G54 offset table in the Offsets screen. I found that entering them into the G54 table on the Offsets page seemed to not be as reliable. I even make sure that I enter these values directly into the axis DRO’s while the machine is at its zero, or home, position rather than moving the tool position to the machining origin point and simply zeroing them.
I use the tool table and length offset (G43/44) to handle the Z axis.

I thought I had it made - until the following program.

I am making a keypad for Mach 3 and this program is to cut the holes in the panel to let the switches poke through. The structure is fairly simple.
The main program positions on the centre of each hole and calls subroutine 2222.
 It lowers the tool and calls subroutine 2224 to mill a ‘lap’ of the hole.
Control passes back to 2222 which lowers the tool and calls 2224 again.
It does this five times and then goes back to the main program which moves the tool to a safe position and ends the program.

With a single hole position programmed and using radius compensation, it works perfectly.
With all hole positions, but with G42 deleted from block N510, it works perfectly.
(This is how I produced the panel shown in the photo. It’s also why the apertures are one tool radius too big all round.)
Here we get to the weird bit. If I load the program as is it produces a graphic in the tool path display which reproduces the hole pattern and programmed path perfectly (in blue.). However, there is also a white line leading from the centre point of each hole to the centre point of the very first hole.
On actual physical execution, the first hole machines perfectly, the tool moves to the centre point of the next hole to be machined, and then ...... on the execution of block N510, the tool returns to the centre point of the FIRST HOLE AGAIN, (X.708 Y.737) and machines it all over again. It does this for every other hole.


Anyone have any ideas?

As a comment, radius compensation in Mach3 is extremely flaky and this seems to be borne out by numerous plaintive posts where you can almost hear the heads being scratched over its behaviour. In stark comparison, length compensation seems to be very robust.

PS:
By selecting the ‘Block Delete’ button (Block Skip actually.) the program will execute with just one hole.
Without Block Delete on, delete G42 from block N510 to see the difference it makes.


N10 (CNC CONTROL PANEL SWITCH MASK)
N20              (VERSION 3.1)
N20 (NOTES: TOOL LENGTH OFFSET TO WORK SURFACE)
N30 (X DATUM - L/H EDGE OF PANEL BLANK)
N40 (Y DATUM - BOTTOM EDGE OF PANEL BLANK)
N50
N60 G0 G90 G20 T1 M6    (ABSOLUTE, INCH, TOOL 1, SELECT)

N100 G0 G44 X.708 Y.737 Z.080 (MOVE TO 1ST SWITCH HOLE POSN, INVOKE L/COMP)
N105 #201=-.250 #202=.500   (SET PARAMETER VAUES FOR SUB 2224- SMALL HOLE)
N110 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N120 G0 X1.609 Y.737   (MOVE TO 2ND SWITCH POSN.)
/N130 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N140 G0 X1.609 Y1.537   (MOVE TO 3RD SWITCH POSN.)
/N150 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N160 G0 X.708 Y1.537   (MOVE TO 4TH SWITCH POSN.)
/N170 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N180 G0 X.708 Y2.338   (MOVE TO 5TH SWITCH POSN.)
/N190 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N200 G0 X1.609 Y2.338   (MOVE TO 6TH SWITCH POSN.)
/N210 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N220 G0 X.958 Y3.139   (MOVE TO 7TH SWITCH POSN.)
/N225 #201=-.500 #202=1.000   (SET PARAMETER VALUES FOR SUB 2224 - LARGE HOLE)
/N230 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N240 G0 X2.609 Y1.437   (MOVE TO 8TH SWITCH POSN.)
/N245 #201=-.250 #202=.500   (SET PARAMETER VAUES FOR SUB 2224 - SMALL HOLE)
/N250 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N260 G0 X3.210 Y2.038   (MOVE TO 9TH SWITCH POSN.)
/N270 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N280 G0 X3.210 Y.837   (MOVE TO 10TH SWITCH POSN.)
/N290 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N260 G0 X3.810 Y1.437   (MOVE TO 11TH SWITCH POSN.)
/N270 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N280 G0 X4.711 Y1.838   (MOVE TO 12TH SWITCH POSN.)
/N290 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)
/N280 G0 X4.711 Y1.037   (MOVE TO 13TH SWITCH POSN.)
/N290 M98 P2222   (CALL CUTOUT MILLING SUBROUTINE)

N400 G0 G49 X0 Y0 Z-2.000 M5 (LIFT TOOL, CANCEL LENGTH OFFSET, STOP SPINDLE)
(MOVE TO RELOAD POSN)
N410 M30 (END PROGRAM, REWIND)

O2222   (LABEL SUBROUTINE)
N510 G91 G42 Y-.250 M3(MOVE TO START, RELATIVE W/ RADCOMP, START SPINDLE)
N520 G1 Z-.160 F150   (PLUNGE DOWN 1)
N530 M98 P2224   (CALL POCKETING SUBROUTINE)
/N540 Z-.080   (PLUNGE DOWN 2)
/N550 M98 P2224   (CALL POCKETING SUBROUTINE)
/N560 Z-.080   (PLUNGE DOWN 3)
/N570 M98 P2224   (CALL POCKETING SUBROUTINE)
/N580 Z-.080   (PLUNGE DOWN 4)
/N590 M98 P2224   (CALL POCKETING SUBROUTINE)
/N600 Z-.080   (PLUNGE DOWN 5)
/N610 M98 P2224   (CALL POCKETING SUBROUTINE)

N660 G0 G90 Z.080   (LIFT TOOL - ABSOLUTE, RAPID)
N670 G91 G40 Y.200   (CANCEL RAD COMP - RELATIVE)
N670 G90   (CHANGE TO ABSOLUTE)
N680 M99   (END SUBROUTINE)

O2224   (LABEL POCKETING SUBROUTINE)
N800 X#201 F8   (MILL TO 1ST CORNER)
N810 Y.500   (MILL TO 2ND CORNER)
N820 X#202   (MILL TO 3RD CORNER)
N830 Y-.500   (MILL TO 4TH CORNER)
N840 X#201   (MILL TO START POINT)
N850 M99   (END SUBROUTINE)

5

General Mach Discussion / Re: Problem with G42 cutter radius compensation

« on: January 27, 2014, 09:58:09 PM »

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.

6

General Mach Discussion / Re: Problem with G42 cutter radius compensation

« on: January 27, 2014, 08:34:02 PM »

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.

7

General Mach Discussion / Re: Problem with G42 cutter radius compensation

« on: January 27, 2014, 07:42:57 PM »

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?

8

General Mach Discussion / Re: Problem with G42 cutter radius compensation

« on: January 27, 2014, 06:56:22 PM »

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?

9

General Mach Discussion / Re: Problem with G42 cutter radius compensation

« on: January 27, 2014, 04:09:38 AM »

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.

10

General Mach Discussion / Re: Problem with G42 cutter radius compensation

« on: January 13, 2014, 04:17:42 AM »

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.