forum.cncdrive.com

I've played around a bit with the new G41/G42, and have some comments/suggestions.

1) Your implementation of how comp is applied seems to me to be a bit non-standard. Imo, comp should be applied during a lead-in move. As it is now, comp appears to be using the previous tool location to determine how to apply the comp. This seems to cause unnecessary errors.
I can run code that works fine, but sometimes throws an error, depending on where the tool happens to be. This requires additional moves to be added prior to the lead-in move, to avoid these errors. In some cases, depending on tool position, UCCNC does apply the comp like I am expecting. But most of the time, it does not.

If you apply the comp during the lead-in move, then as long as the lead in move is correct, you eliminate the first three of your five warning messages. As long as you specify that the user needs a lead-in move longer than the tool radius, most of your problems go away.
This is how LinuxCNC does it. http://linuxcnc.org/docs/2.6/html/gcode ... mpensation
And how the controls I've used on high end Italian routers as well.
It's fine, imo, if you don't allow arcs for lead-in moves.

2) Comping an outside corner should always result in the tool "rolling around" the corner. This is how basically all CAM programmed g-code is written. I use G41/G42 to cut cabinet parts, which are nearly always rectangular, with square corners. I don't want the tool to stop at each corner, when it can roll around the corner at higher speeds.
I can't think of any situation where it wouldn't be desirable to roll around the corner. In it's current state, I would not be inclined to use comp, even though I prefer it. Comp should give the same toolpath that a CAM program will give. If not, it's a feature that's only partially implemented, imo.

I'm attaching a .pdf I threw together to show what I think it should be.




G41/G42 does appear to be working nicely, though, outside of these two issues.

Now would probably be a good time to add wear compensation as well, no? You just add a wear DRO, and add the value to the tool diameter. I personally don't use this, but I know that some do.

Thanks guys for the feedbacks and I hope everybody had a great Christmas time!

Gerry,

I don't understand point 1. yet, but did not read fully after it yet, I will read the doc you linked to see if I understand what this means and let's discuss it afterwards.

The point 2. is something which we already started implementing. I mean there will be the square shape joints and round joints option for connection angles grater than 180°.
So, it will be an option what you want in point 2., we will finish it in the beginning of January. Unfortunately we could not finish it before Christmas, but wanted to give you guys a release so is why yet only the square joints only are available in this release.

And if you guys find bugs then please post the associated profil file and g-code and some description, because seeing one printscreen is not enough info for us to even start debugging.
It is possible that there are bugs in this version because as I wrote earlier the G41/G42 required serious code changes with additional bufferings, so however we ourselves tested this software version a lot it is possible that some issues remained in which we did not notice.

Terry,

Could you please describe how a proper tool table would look like?

Thanks Terry, I'll debug this soon to see why the issue happens.
I'll also check the thread about the tool table.

ger21 wrote:I've played around a bit with the new G41/G42, and have some comments/suggestions.

1) Your implementation of how comp is applied seems to me to be a bit non-standard. Imo, comp should be applied during a lead-in move. As it is now, comp appears to be using the previous tool location to determine how to apply the comp. This seems to cause unnecessary errors.
I can run code that works fine, but sometimes throws an error, depending on where the tool happens to be. This requires additional moves to be added prior to the lead-in move, to avoid these errors. In some cases, depending on tool position, UCCNC does apply the comp like I am expecting. But most of the time, it does not.

If you apply the comp during the lead-in move, then as long as the lead in move is correct, you eliminate the first three of your five warning messages. As long as you specify that the user needs a lead-in move longer than the tool radius, most of your problems go away.
This is how LinuxCNC does it. http://linuxcnc.org/docs/2.6/html/gcode ... mpensation
And how the controls I've used on high end Italian routers as well.
It's fine, imo, if you don't allow arcs for lead-in moves.

Gerry,

I don't understand point 1. yet, but did not read fully after it yet, I will read the doc you linked to see if I understand what this means and let's discuss it afterwards.

Balazs, did you ever look into this?

I still don't like the way this works. You should never get some of the warnings you are giving, if you apply comp properly during the lead in. The location of the tool before the g-code starts should have no effect on the lead in move, but it does the way you are doing it.

The round corners are much better, though.

Here's some code that causes gouging when rounded corners is selected.

Set up tool #1 with a 0.5" diameter.

THAT is one strange leadin senario (;-)

That was a quick sketch, but it's basically how we lead in on nested cabinet parts. Come in from the side on the longest edge, with a shallow approach angle, so you can place your parts as close together as possible.

In that test code IF you set teh tool correctly for teh pathing (.250 for example) it runs fine

What do you mean "set the tool correctly"? I run parts like this with 1/2" tools, and it should work correctly with whatever tool I want.

If you do leadin and leadout correctly it does work.

Where's the definition of "correctly"? All the controls I've used lead in like I was talking about in my earlier post. The way it is now, you get a different leadin, depending on where the tool is before you hit cycle start.
The tool should move to the position called for prior to the G41/G42, then do the leadin. The way it is now, the prior move seems to factor into the leadin, which is what throws all the errors

Hi Guys,

Gerry, I did not have time yet to think about the leading in discussion we started here.
As you can see in the new release update list there were lots of other things to change and to fix and also the G41/G42 got the round joints which was itself lots of work.
The next step will be to continue this discussion to let me clearly understand how it should work and then we will try making it for the next release.

The gauging is unfortunately a result of how G41/G42 works.
It is mathematically defined how it works, how it has to work.
As I described you guys earlier a few times (or at least I have tried to) G41/42 has limitations, because it can only look ahead one movement.
It will never be that perfect as how a CAM program can compute an offset path, because G41/42 looks ahead only one movement while CAM softwares view the path as a full and using ray tracking algorithms to compute the optimal offset path.
To use such algorithm in a CNC controller is not possible with todays' computer technology, because with even medium size of codes the computation time runs much longer than how it would be comfortable in a CNC controller software. It is just not comfortable to make the user to wait even minutes to get the offset path.
In CAM software it is not a problem, because you know that when you pressing the "generate toolpath" button then you will have to wait.
But in a CNC controller you have to compute this on the fly is one thing and the other thing is what I have said many times is that it is defined how G41/G42 has to work and it is one look ahead, otherwise the machinist could not follow the algorithm if it is more complex than that which would cause an unpredictible result for different code scenarios.

With round joints with your example code Gerry the gauging can be seen and happens. With square joints it does not happen and this is why we wanted to also implement the square joints calculation method, because it often gives better results with gauging less.

I understand that you guys looking for the perfect G41/G42, but unfortunately it can't be done perfect, which I was talking about for some time now. I told it even prior to we started implementing it.

I've made a quick printscreen comparion about how the UCCNC with round joints and with square joints and also what Mach3 calculates with the same offset. I will attach this picture to this post.
Please note that I have no access to the code of Mach3, the only thing I know is the definition of the G41/G42 and you can see that still both softwares do the gauging the same way at the same places which I present you as a proof of that the limitation is the G41/G42 definition of working.
I present this printscreen now, because it tells more than if I start explaning, start reasoning why and how the gauging happens which would require me to go into describing the algorithm deeper which is kind of hard for me as it would be a long and painful description for me in English...

To get a perfect results always a different algorithm should be implemented, but that is no more G41/G42, that is then called a CAM software.
10 lookahead is nice, but that will still not give a perfect result in all scenarios and I would not call that G41/G42 anymore.
And I've not seen any controllers so far which would implement G41/42 other way than with a single look ahead line.
Even industrial controls which I saw worked only with a single look ahead, but I understand and described the reason for that.

And no, it can't stop without overshot in this example. If the algorithm would be forced to stop in this scenario and not to overshot then other scenarios would work incorrectly.
It is just simply impossible to make it to give perfect results in all scenarios.
And the algorithm does not know when it is gauging/overshooting. Maybe it could be done to detect it somehow, but to see if it is even possible I will have to think it through and dig deeper...

And yes, Mach3 is buggy in regards the G41/42 at several points and the matter of fact is that my first thought was when I started testing and observing the Mach3 G41/42 was how could anybody even use this for real work, because it failed on so simple codes and those failures which I saw were not algorithm limitations related.
However this specific example is not a result of a bug in Mach3, there is a clear reason why it happens and the reason is the limitation of the offset algorithm.
And I think it should be clear that to have 2 softwares to have the same bug in a relatively complex algorithm like the G41/42 is not likely to happen,
I'm not saying it is impossible, but because I know the algorithm I can confidentaly say that it is very very unlikely and it is not the case for sure with this code.