Hello Guest it is March 29, 2024, 09:51:59 AM

Author Topic: More Problems with Radius Compensation G42 / G41  (Read 9549 times)

0 Members and 1 Guest are viewing this topic.

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)




Offline Graham Waterworth

*
  • *
  •  2,668 2,668
  • Yorkshire Dales, England
    • View Profile
Re: More Problems with Radius Compensation G42 / G41
« Reply #1 on: May 07, 2014, 06:34:59 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.

Without engineers the world stops
Re: More Problems with Radius Compensation G42 / G41
« Reply #2 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.


Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: More Problems with Radius Compensation G42 / G41
« Reply #3 on: May 07, 2014, 10:49:53 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.

Just a thought, (;-) TP
Re: More Problems with Radius Compensation G42 / G41
« Reply #4 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.

Offline Graham Waterworth

*
  • *
  •  2,668 2,668
  • Yorkshire Dales, England
    • View Profile
Re: More Problems with Radius Compensation G42 / G41
« Reply #5 on: May 10, 2014, 06:41:00 AM »
when you purchased your PC did you expect Microsoft to be sending you OS fixes every other day as they sold you a faulty piece of software.  NO, and you paid for that, this has cost you nothing and you have the option of using something other than Mach3 to control your machine.

By the way comp works just fine if you only use 1 sub and obey the lead in/out rules.
Without engineers the world stops

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Re: More Problems with Radius Compensation G42 / G41
« Reply #6 on: May 10, 2014, 07:02:14 AM »
The reason you don't hear a lot about problems using radius comp is because we lazy folks use CAM to generate pre-compensated code rather than hand code. Echoing what Graham said pay, attention to lead in and out.

RICH

Offline ger21

*
  • *
  •  6,295 6,295
    • View Profile
    • The CNC Woodworker
Re: More Problems with Radius Compensation G42 / G41
« Reply #7 on: May 10, 2014, 07:11:05 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.
Gerry

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

JointCAM Dovetail and Box Joint software
http://www.g-forcecnc.com/jointcam.html
Re: More Problems with Radius Compensation G42 / G41
« Reply #8 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?

Offline ger21

*
  • *
  •  6,295 6,295
    • View Profile
    • The CNC Woodworker
Re: More Problems with Radius Compensation G42 / G41
« Reply #9 on: May 10, 2014, 07:45:43 AM »
I never use subroutines, and almost never use offsets. I use comp for about 99% of the things I cut.

As for lead-ins and lead-outs, I've done it both ways, depending on the CAM software.
For most of the stuff I do at home, I use an AutoCAD macro to generate g-code. For this I draw the lead-ins and lead-outs.
At work, we use AlphaCAM, and it automatically adds them.
Gerry

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

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