Radius compensation?

[A_Camera]

Hi Balázs,

I would like to know if there is any hope of ever getting this feature. In my opinion this is by far THE most important update or feature, far more important than anything else, including faster macro execution and any built in safety features. Without tool radius compensation UCCNC is not really a fully grown product and the lack of it is a serious limitation. I know it is not easy to get it right, but it can be done and it is important. Any news about the status?

[cncdrive]

Hi Josef,

Yes, it will be done sometime, but ETA can't be given yet.

Altough not too many people asking about these codes, probably because in the CAM age people simply offsetting the path in the CAM software which is a far more accurate way or offseting,
the only downside is that it is a slower process. But G41/G42 in most cases introduces inaccuracies which may or may not be a problem depending on the path to offset and value to offset and the required tolerances and the possibly caused innaccuracy is because of the nature of how G41/G42 works, how it has to work.
So, it is not a magic wand and in the inexperienced hands using these codes can cause more trouble than benefits.
Anyways, we will implement it asap.

[ger21]

But G41/G42 in most cases introduces inaccuracie

Can you clarify this? I can't see what there should be any inaccuracies. The actual tool path is just offset from the programmed path. It should be no different than offsetting in a CAM program, and parts should always be 100% accurate.
Now, if you're referring to areas where the tool can't reach, that's something else, and is again no different than CAM.

In the industrial router arena, G41/G42 is used for everything, as we are cutting thousands of unique parts, and almost always using sharpened tools of various diameters. G41/G42 Allows us to program well in advance, and not worry about the size of the tool being used.

[cncdrive]

Can you clarify this? I can't see what there should be any inaccuracies. The actual tool path is just offset from the programmed path. It should be no different than offsetting in a CAM program, and parts should always be 100% accurate.
Now, if you're referring to areas where the tool can't reach, that's something else, and is again no different than CAM.

In the industrial router arena, G41/G42 is used for everything, as we are cutting thousands of unique parts, and almost always using sharpened tools of various diameters. G41/G42 Allows us to program well in advance, and not worry about the size of the tool being used.

Gerry, the G41/G42 works totally different in a CNC controller than in a CAM program.
In a CNC controller the G41/G42 creates the offset path point by point getting the points to be executed from the g-code program.
The controller needs 2 points to have enough information to create an offset vector, a single point is not enough, because then the direction of the motion so the direction of the movement vector and therefor the direction of the offset vector is unclear. The issue is that the controller knowing 2 points only and therefor it does not see the path in total, so there can be cases when the path offset will be not perfect, the cutter overruns on a path part of the future which the software does not see yet.
Looking ahead could help some, but not always for several reasons, but I will not go into these as it would be long to describe.

I had some nice images of this problem printed out of sample problematic toolpaths which had defects when g41/G42 offset because of this, I've posted that somewhere in the hungarian hobbycnc forum and had those pictures on my old PC, but since that I changed PC and also the hobby forum was moved to a new provider and I can't seem to find the pictures now.
But if time will allow I will make some new pictures which demonstrates the issues.

A CAM program watches the path as a whole, the offset algorithm is totally different in a CAM, it knows the full path so it has the full picture not only about what is currently happening.

The CAM offsetting approach can't be implemented as a G41/G42 is because it can take long times to do the scanning rays definition and then the calculations it could take seconds or minutes if there are enough segments on the path, this is not good for a CNC control software which has to respond in about realtime.
G41/G42 may be programmed also manually (MDI) and then the offseting has to be changed immadiately to happen with the new value on the next movement commands,
so it is not OK to let the user wait seconds or minutes for the recalculation.
Also because scanning rays calculation method is mathematically complex it would be hard for machinists to conclude the exact results while the G41/G42 unidirection polygon offsetting is much simpler, so the algorithm can be fully described in an understandable way just like it is done in several CNC controller's manuals.

[cncdrive]

I wonder how many low end CAM's can actually do tool Comp Coding ??

Non of them and all of them.
I mean I think non of them adding G41/G42 codes in the output code, because of it's possible disadvantages,
but a basic operation of CAMs is to make a simple inner/outer contour with specified tool diameter.
And if there is no tool comp parameter then you can still just change the tool diameter which is a tool radius compensation.

[A_Camera]

Hi Josef,

Yes, it will be done sometime, but ETA can't be given yet.

Hi,

OK, thank you for a honest answer. I am OK for now, since I can switch to Mach3 when needed, but basically that's the only thing keeps me from getting rid of it.

Altough not too many people asking about these codes, probably because in the CAM age people simply offsetting the path in the CAM software which is a far more accurate way or offseting,
the only downside is that it is a slower process. But G41/G42 in most cases introduces inaccuracies which may or may not be a problem depending on the path to offset and value to offset and the required tolerances and the possibly caused innaccuracy is because of the nature of how G41/G42 works, how it has to work.
So, it is not a magic wand and in the inexperienced hands using these codes can cause more trouble than benefits.
Anyways, we will implement it asap.

I honestly can't see CAM as an alternative, yes it works, but regenerating G code just because a different tool is used is not an alternative, possibly a temporary work around. It is much better and easier to just change the tool number or if for some reason the too diameter is changed, for example a set of new tools is a bit smaller or larger than expected (inaccuracies with manufacturing) it is simple to create a new tool in the tool table and use that. No need for generating a new G-code.

Maybe you are right about possible inaccuracy issues, but so far I have not seen any problems.

[A_Camera]

I had some nice images of this problem printed out of sample problematic toolpaths which had defects when g41/G42 offset because of this, I've posted that somewhere in the hungarian hobbycnc forum and had those pictures on my old PC, but since that I changed PC and also the hobby forum was moved to a new provider and I can't seem to find the pictures now.
But if time will allow I will make some new pictures which demonstrates the issues.

Hi Balázs,

Are you referring to these images:





Found them on this forum: http://forum.hobbycnc.hu/topic.php?topic=219

Reading Hungarian is a bit painful for me after all these years, but maybe I'll give it a try one of these days...

[ger21]

I mean I think non of them adding G41/G42 codes in the output code, because of it's possible disadvantages,

I don't agree that there are disadvantages, but rather poor g-code programming. Garbage In, Garbage Out. If you are going to use G41/G42, then you should no what you are doing.
If the control can't offset the path, then it should give an error, rather than an incorrect path. But I don't see there being accuracy issues, if comp is implemented properly.

Two things about the pics posted above.
1) Mach3 is known to have bugs in there G41/G42 implementation. I've seen comp errors on two Identical parts, that were just in different locations. One worked fine, the other had errors.
2) I suspect that there are a lot of short segments in those corners that are causing issues.

All of UCCNC's competition doesn't seem to have any issues with offering G41/G42, so I just don't see a problem.

[cncdrive]

Gerry,

What Josef posted is not an incorrect path, it is the correct path with the algorithm of how G41/G42 has to work, it is not a bug of Mach3.

The control can't give a fault, because it often does not see enough beyond of the current happening, it does not see future path and that is what is causing the problem I've mentioned.
There is no solution for this, except if the offset is calculated in a different way like how it is done in a CAM programs,
but that can't be realtime and that can't change in realtime when you change the G41/G42 value and can be slow and therefor annoying for the user,
and then it is not really a G41/G42 anymore.

[cncdrive]

Josef,

Thank you for looking these up, yes, there are some of which I thought about.
I had some better ones also which demonstrates the issue better, more clear, but I think I left them on my old PC and the last time I tried to start that PC it did not start up,
and I did not have time to remove the harddrive yet to get those files.