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.