G41/G42 discussion.

[Battwell]

thanks jason- thats what i needed to see.

[cncdrive]

In the example profile when it gets to teh corner and wraps around (90deg) it checks teh next block and see that it will NOT interfere with teh next line. HAD it looked one more block it would have seen there was an intersecting line and that intersecting line would be closer than teh tool radius indicating a gouge. IT could do 1 of 2 things ERROR out OR change teh path to fix teh problem I would say that a 3 block look ahead could find 99.9% of all collisions. It could SEE a situation such as a small area that teh tool could not fit into. It would check for X and Y interferences over 3 blocks.

Yes, good thinking, however there can be cases when this would give a false positive for collosion.
Imagine a toolpath were one part is machined and then it moves to another part which is closer to the first one with less than the radius distance.
There can be toolpaths which are made this way on purpose and then if the controller looks ahead and checks for collosion to those lines too then it will report a false positive.
If it does look ahead just one then I think this could probably work reliably though.
And collision detection on the current and next line and even the previous one could be done relatively simple with looking for intersections between the line and the circle drawn by the 2*radius around the offset points.
If there are more than 1 intersect points found then that is a collision.

And I got the Fanuc manual in email, thank you. I looked through it, but I don't see where does it describes post-actions for gouges removals?
What I see in the manual is basicly the same algorithms we implemented and ofcourse some more which we did not, like the 3D radius comp.
I mean the manual is 440 pages long and I looked through it a few times, but maybe I missed to see that part. Please help which pages are of the interest?

[cncdrive]

Hi Terry,

In teh Fanuc examples teh controller simply ignored any segment that was an interference and rewrote teh path to teh next clear segment that did not violate teh tool Radius.

Yes, this is what I was looking for in the doc you sent, but I could not find any info about it. The only things I saw was the same algorithms what we implemented, I did not find anything which would say it is looking for collision and that it back-corrects these type of issues in any ways. Please look it up for me, because maybe I'm just too blind to see it or it is just too late night here.

[cncdrive]

IIRC there were several examples one was a step down like Ger example andn teh other was a notch that the tool could not access because the tool was too wide. IF you try that in UCCNC it will destroy teh part. I did test that part as well. It will turn a .250 notch into a 1" notch(;-) BUT that is MORE programmer error than machine It just did what I told it to do. It did not know I was just kidding

Yes, I know, I ran both codes with UCCNC to see why the issue happens. I ran it even in Mach3 and 4 to see if they make same or similar issues and they do.
And I see a new forum member posted also a Centroid controller which does the same issue.
And I'm not at all surprised that this issue happens on other controllers too.
How the G41/42 is described to work these issues have to happen, it is a algorithmical weekness problem, they are guaranteed to happen by algorithm.
Unfortunately currently I have no access to any other controllers, but maybe I can also run it in LinuxCNC later, but I have no access to a Fanuc or similar to run it, but will ask a few guys to see if somebody can run the code for me...
And I beleive you that there can be additional codes which tries to correct these problems, I just did not see a controller like that so far, so this is when it would be great if you could point it out for me in the Fanuc document you sent, because I'm more and more curious to see.

[cncdrive]

Hi Terry,

Thanks for pointing those pages out, I really did not see them when I looked the doc through.
I read the mentioned topics through now and the interesting thing in point 6.6.5 is the first 2 issues described, because basicly these are what we talking about and there is the solution how to detect and to report this issue is in point 6.6.6
The 3rd things in point 6.6.5 is not so interesting, because the UCCNC already have solutions for that implemented, because our algorithm distiungish between XY and other axis motions and non-motion commands and the non XY movement commands and the non-motion commands are buffered in, so the controller can still look ahead to the next motion, the look-ahead will not stop like in the Fanuc as it is described in the manual, so this issue does not happen with the UCCNC's algorithm. For this issue to not happen we have 2 extra buffers in the radius compensator class.

Even more interesting is point 6.6.6. where they describe detection methods for the first 2 issues they described in point 6.6.5.
What they basicly do is they compare the original movement vectors' direction angle with the offset vectors' direction angle and if any differ with 90<= alpha <=270 then they generate a warning, because that means that the direction of the offset vector is close to the opposite to the original vector which is basicly the case in the example gouging paths we described in this forum topic.
I think we can implement the same procedure, I mean I see no problem implementing it.
These does not correct the gouging, but they can give a warning, so at least the user will be aware of the problems.

[jazzcnc]

Just to throw little fuel on the fire I'm just testing Cslabs SimCNC and thought I'd run the code thru to see what happens and it caught the Gouging and wouldn't allow continuing.

[cncdrive]

There is no fire.
Terry showed a Fanuc document already which describes a nice method to detect gouges, so we will implement that.
And meanwhile we also figured out some algorithms which will detect and remove gouges where possible. Ofcourse it is not a solution for all possible scenarios, but we've tested it with a few codes already where it worked successfully. So, there will be a mixed solution of detecting and possibly removing gouges.

[ger21]

The new version is now much better, with no gouging. Nice job.
However. As you see in the attached image, the two identical corners are being comped differently. The top one is the way I'd prefer it, if you can find the issue and make them the same.
EDIT: I guess it's due to the direction the tool is traveling??

G-Code is attached, Set tool #1 diameter to 0.5 or 0.75.

After this, you just need to fix the leadin moves and it will be perfect.

[cncdrive]

Hi Gerry,

Thanks.
With one of those movements the corrective algorithm could work, but with the other the algorithm can't do the correction, just the detection,
because it does not see the next line which would be required to be available in this case to do a correction, so it is not possible to correct then.
So, what happens is that while the algorithm still knows that there is gouging it can't correct it in that case and so it will switch to square mode to still keep the result without gouging.
We will still try to implement (in addition) the reversed vectors direction detection with looking ahead which Terry showed in the Fanuc manual, that one was not implemented yet.
That will not solve gouging, it will just detect different cases just like how it is described in the Fanuc manual and will just give warning reports if it happens, because there could be still cases ofcourse when gouging happens and when it can't be corrected and can't be worked around, but could be at least detected.

To change the lead-in moves is not as easy as it sounds. I looked into it and yet I could not resolve a logic twist and because there were lots of other things to develop on the UCCNC as you can see the release notes are really long now and some are serious changes and developments, so I did not have time then to stuck thinking about it, but had to move on, but will be back on the topic as soon as possible.

[ger21]

To me, it appears to always looks two moves before the comp to decide where to lead in,and comp is applied before the lead in move, rather than during it.
And if you are making multiple passes, where the tool approaches the leadin from a different direction on the second pass, it will throw an error.
The tool center should always be at the coordinate of the start of the leadin move before the G41/G42, with comp applied after that point. The direction you are moving towards the start of the lead-in should not affect where the comp starts.