forum.cncdrive.com

The beginning and end of the G41 / 42 diameter compensation is interpreted incorrectly in many cases. There are also cases when the compensation works correctly, but when the g-code is run again, the trajectory is built differently.

1. I have run two instances of UCCNC to show the differences in the toolpath in the same code.

2.marked the places where the compensation trajectory is incorrect, as well as different variants of trajectory errors on the same code

3.marked places where compensation is turned on / off in the wrong place (it is 1 line late, or starts 1 line earlier than necessary)

This has been an issue sine G41/G42 was first added, and I've brought it up before.

Since I don't have a machine running UCCNC right now, I haven't followed up on it.

The way it should work, is like this.

G0 X0 Y0 (Center of tool should be at X0 Y0)
G42
G1X5 Y0 (Comp should be applied during this move)

What happens, is that the tool does not always start at the center of specified coordinate before the G41/G42. Where it start varies depending on the location the tool is coming from. It should not be doing this.

ger21 wrote:What happens, is that the tool does not always start at the center of specified coordinate before the G41/G42

This is true. compensation is applied where it should not be. And this differs from case to case. sometimes it works correctly and sometimes it doesn't, in the same code.
It is impossible to take into account its behavior in CAM, and correct the path and postprocessor, this is a problem.

G40 - Disabling compensation also has this problem. Code after G40 should not have an offset ... but it is offset by the radius

YEP it has been wrong ever since it came out in UCCNC . We explained this but no responce or fix.

(;-) TP

It varies is different in the same g-code file (looks good sometimes and not the other times) because your starting point (tool starting location) is different each time, so it depends on from what starting point you doing the compansation.
It is possible that your tool for example is so close to the starting point that it is impossible to do the compensation properly.

cncdrive wrote:It varies is different in the same g-code file (looks good sometimes and not the other times) because your starting point (tool starting location) is different each time, so it depends on from what starting point you doing the compansation.

The beginning of the work of the G-code always took place from one place, at the top of the coordinates Z.
How the code is interpreted should never depend on where the machine was when it was not running.
Today I run g-code and get one, but when I run this code tomorrow, I get another product?


or several identical (same code) parts on the table are cut out differently ...
if you look closely at the path, half of parts are completely damaged by the wrong lead-in.
the path is the same in all cases, only the rotation of the part is different.

cncdrive wrote:It is possible that your tool for example is so close to the starting point that it is impossible to do the compensation properly.

I selected real parameters for compensation, and tested the code on other CNCs. mach3, linuxcnc show the way exactly like the simulation in CAM.

But the UCCNC creates a different, incorrect result.
The good news is that the wrong way is only at the moment of switching the compensation on and off (the lines next to g40/41/42 are usually the tool in and out). At other times, the entire path is correct.

Yes, with G41/G42 you can get "another product" if you parking your tool in the wrong place when starting the job.
It is also the truth that an exception to do when applying G41/G42 was not implemented 100% properly, but it could be overcome with parking the tool on the proper place when starting jobs using G41/G42. If your tool starts from the proper spot then you will always get the proper results.

Parking the tool in the proper place is even important with Mach3 or with any other CNC softwares, because with G41/G42 you could park your tool in a way that the compansation start could not even be done properly.

And yes, this particular code looks fine with Mach3, but beleive me MAch3's G41/G42 is broken at lots of places, it does not always offset arcs properly and there are several other cases which MAch3 handles erratically around the G41/G42. So, please do not say that MAch3's compensation is any better than UCCNCs, because we have studied Mach3 a lot about this and it has much more problems than the UCCNC.
The UCCNC's current problem or limitation is the only one what you posted in this thread and the same have been discussed earlier also, while MAch3's G41/G42 is kind of randomly buggy.

And at some point we will try to implement those exceptions which are required to handle the G41/G42 enable independent of the actual tool position, but it is a lots of work, because of how the G41/G42 algorithm works now, lots of changes needs to be done, so we did not start doing it yet.

cncdrive wrote: but it could be overcome with parking the tool on the proper place when starting jobs using G41/G42. If your tool starts from the proper spot then you will always get the proper results.

before applying compensation, the tool always moves to the desired location. An example with many of the same details shows this well. but the subsequent path is unpredictable, and it is impossible to take into account how it will be built ...

I show an example of mach3, only by the fact that it is at the moment in my pc. Linuxcnc/myCNC will work the same for this example....
Yes, I have worked a lot with mach3, and I know his problems(I have often seen cases of incorrect compensation of an arc crossing the contour of a part. but it also has many more critical problems). That's why I buy your cnc controllers

for example, I will show the path of mach3 - all lead-in/lead-out are the same from all sides, as it should be. Linuxcnc/myCNC will work the same way...

cncdrive wrote:And at some point we will try to implement those exceptions which are required to handle the G41/G42 enable independent of the actual tool position, but it is a lots of work, because of how the G41/G42 algorithm works now, lots of changes needs to be done, so we did not start doing it yet.

Thanks for your work!
I appreciate your work and recommend it to my colleagues for a long time.
I will wait for future updates!

Thank you. I appritiate that you using our controllers.
Honestly this G41/G42 compensation is one of the most complicated part of the whole software, it is similarly complicated as the motion control.
And it is complicated because the controller has to look ahead in the g-code.

Anyways, we will get to developing the mentioned G41/G42 proper start asap.

Thank You!!