Bug #4011 - no pocket path is diam=tool diam

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
freman
Posts: 627
Joined: Tue Nov 27, 2018 10:30 pm

Bug #4011 - no pocket path is diam=tool diam

Postby freman » Fri Jun 07, 2019 12:51 pm

Hi,

due to problems with producing drilling paths suitable for GRBL, I tried to work around by using a edge pocket path and an end-mill.

If I try to make a 3mm radius hole using a 6mm diameter mill, I don't get a path.
If I specify 3.001mm , no path.
If I specify 3.01 , I get a path but it has tiny wiggle arc path added on. ( Technically correct )

Why does it not produce a path at 3mm radius? I'm guessing someone code a ">" instead of ">=" thus eliminating what seems to be a valid possibilty.

Code: Select all

OS: Linux (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16854 (Git)
Build type: Release
Branch: master
Hash: fe0fd5512ba9a8a9c729cdc47af35bbe965050ac
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)
Attachments
drill-test-y20.FCStd
(23.26 KiB) Downloaded 6 times
Last edited by Kunda1 on Sat Jun 08, 2019 11:51 pm, edited 2 times in total.
Reason: re-arranged topic
User avatar
sliptonic
Posts: 1561
Joined: Tue Oct 25, 2011 10:46 pm

Re: no pocket path is diam=tool diam

Postby sliptonic » Fri Jun 07, 2019 1:43 pm

That's possible. It might also have something to do with python floating point math.
If you're up to the challenge, this should be a pretty easy one to narrow down.
User avatar
freman
Posts: 627
Joined: Tue Nov 27, 2018 10:30 pm

Re: no pocket path is diam=tool diam

Postby freman » Fri Jun 07, 2019 2:48 pm

Much as it would be fun , I need to spend time on the h/w which still has a lot of issues , like crap chinese ball scews which seem to be appallingly inaccurate. For me to find my way around the code to pin point where <= needs to be would be a rather expensive use of my time when those who are familiar will probably find it in 10 min.

My test with 3.001 seem to indicate that it is not fp error. My money is on a conceptual error when it was programmed.

I'll open a bug about this so at least there is a record.
RatonLaveur
Posts: 340
Joined: Wed Mar 27, 2019 10:45 am

Re: no pocket path is diam=tool diam bug #0004011

Postby RatonLaveur » Fri Jun 07, 2019 3:35 pm

I unfortunately cannot test, but it looks to me like it isn't a math problem since 3.001 is still >3. Now it could be number of floating points...but still. Could it have something to do with the accuracy in path? Below a certai n threshold it won't even try?
User avatar
freman
Posts: 627
Joined: Tue Nov 27, 2018 10:30 pm

Re: no pocket path is diam=tool diam bug #0004011

Postby freman » Fri Jun 07, 2019 3:46 pm

That is why I did that test. It is smaller than geometric tolerance of 10um but still >0 for fp maths.
I'm sure someone familiar with the code will pinpoint it rapidly, given the specifics.

Although there is not much need to do this if FC was producing valid drilling paths for GRBL, this may also manifest in other areas if test conditions are not correctly structured.

Since it is a go/no go error which simply and quietly fails to produce a path or flag reason why it did not , this probalby should be fixed.

Code: Select all

I unfortunately cannot test
Why not? Configure output for grbl in the job set up , do post process and see what the output file has in it .

Similar thing happens with a square profile. Selecting four edges of 6mm sqr fails to produce a path; 6.01mm does. That is more of a real usage case. Also consider trying to machine a 6mm slot using 6mm tool.

Same thing happens on a rect slot cutting 6mm slot with 6mm tool fails.

Both edge pocket and face pocket do the same. This seems quite a generalised error, very likely all from the same line of code.
mlampert
Posts: 1326
Joined: Fri Sep 16, 2016 9:28 pm

Re: no pocket path is diam=tool diam

Postby mlampert » Fri Jun 07, 2019 7:12 pm

freman wrote:
Fri Jun 07, 2019 2:48 pm
I'll open a bug about this so at least there is a record.
This is not a bug, AFAICT it's working as intended. You can't make a profile op if there is no profile to follow - and the difference between 3.000 and 3.001 most likely falls into the accuracy tolerance you've set.
User avatar
freman
Posts: 627
Joined: Tue Nov 27, 2018 10:30 pm

Re: no pocket path is diam=tool diam bug #0004011

Postby freman » Fri Jun 07, 2019 7:34 pm

I agree about 3.001, that was done intentionally to see at what delta triggered this . ( I remarked above that 3.001 is below 10um tolerance ).
You can't make a profile op if there is no profile to follow
A 6mm cylinder is a profile. It trivial to achieve with a 6mm tool ! I think what you are saying is expressing the ( I would say false ) assumption behind the coding error. This is exactly what I felt was happening from the behaviour.

If I define a 6mm rectangular slot in my model and want to cut it with a 6mm tool is that also "not a profile" ?

Maybe there is a different way of looking at this. I'm a noob here, saying it with child-like ignorance of the assumptions made by those who know what they are doing ;)
mlampert
Posts: 1326
Joined: Fri Sep 16, 2016 9:28 pm

Re: no pocket path is diam=tool diam bug #0004011

Postby mlampert » Fri Jun 07, 2019 7:37 pm

freman wrote:
Fri Jun 07, 2019 7:34 pm
A 6mm cylinder is a profile. It trivial to achieve with a 6mm tool ! I think what you are saying is expressing the ( I would say false ) assumption behind the coding error. This is exactly what I felt was happening from the behavious.
Bad phrasing on my part - there's only a Profile (as in Path.Profile) if there is a difference between the shape of the tool and the amount of material it's supposed to remove.
User avatar
roerich_64
Posts: 712
Joined: Thu May 21, 2015 7:00 pm

Re: no pocket path is diam=tool diam bug #0004011

Postby roerich_64 » Fri Jun 07, 2019 7:41 pm

Ok let us see over the rim of a plate:

Other CNC-Software have also a problem to cut out canal of 3mm with a 3mm tool...

Why?
The Canal or the hole becomes not a precision as it shouldt have.

In practice, you have two ways to make a hole:
- with drilling
- with mill out

With drilling you become the acuracy with the tool at position...
With mill out the tool shouldt be a little bit smaler of the hole or of the canal to become the precision.

So, it is correct when the toolcontroller says that he can not cout out the path when between the paths are the same diameter...

@ Freman: I love your precision and analythic but please: do not lost the eyes of the practics...
User avatar
freman
Posts: 627
Joined: Tue Nov 27, 2018 10:30 pm

Re: no pocket path is diam=tool diam bug #0004011

Postby freman » Fri Jun 07, 2019 9:07 pm

Bad phrasing on my part - there's only a Profile (as in Path.Profile) if there is a difference between the shape of the tool and the amount of material it's supposed to remove.
Where does that definition come from? That is a programmer's perception of what "profile" means. CAM stands for computer aided manufacturing not computer enforced manufacture.

Is there a technical or machinist's reason that I would not want to ( indeed be prevented from ) cutting a 6mm trough with a 6mm tool ?
Last edited by freman on Fri Jun 07, 2019 9:17 pm, edited 1 time in total.