Rotated holes result in different sized Helix tool paths.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 23
- Joined: Fri Nov 16, 2018 2:00 am
Re: Rotated holes result in different sized Helix tool paths.
Having a user modify defaults is not a good solution. A user should not need to know underlying behaviour/quirkiness to have a model be precise.
IMBack showed code that works with correct radius, for other cases. Why not fix all locations to use correct radius?
To an end user, it doesn't matter what kernel FC is based upon. If there are other cases that need fixing, then fix those too.
Basing a radius on a tesselated circle's bounding box is FUNDAMENTALLY incorrect regardless of default precision. Tesselation isn't the same category as rounding error / truncation. If code is based on tesselation like this, it will fail in the future.
One might actually WORSEN the default Precision (set it to 10mm!) then use freecad to find/debug all the bad occurrences of using a tessellated circle's radius.
IMBack showed code that works with correct radius, for other cases. Why not fix all locations to use correct radius?
To an end user, it doesn't matter what kernel FC is based upon. If there are other cases that need fixing, then fix those too.
Basing a radius on a tesselated circle's bounding box is FUNDAMENTALLY incorrect regardless of default precision. Tesselation isn't the same category as rounding error / truncation. If code is based on tesselation like this, it will fail in the future.
One might actually WORSEN the default Precision (set it to 10mm!) then use freecad to find/debug all the bad occurrences of using a tessellated circle's radius.
- aka 'TheRainHarvester" on youtube.
Re: Rotated holes result in different sized Helix tool paths.
You will have a rough time succeeding with FreeCAD if you insist on sticking with the default parameters. Don't forget that many, if not most, FreeCAD users are interested in topics like architecture. One millimeter is probably good enough for those cases.
User parameters are "adjustable" because different users have different needs. If "one size fits all" was the case then the adjustment would not be needed
Gene
User parameters are "adjustable" because different users have different needs. If "one size fits all" was the case then the adjustment would not be needed
Gene
Re: Rotated holes result in different sized Helix tool paths.
First of all, I dont call this a bug.
It is just the way "Hole-Detection" was implemented at the time (now, we know better from testing), and Ive seen it as a long term problem that had to be acknowledged and compensated for through the user "awareness".
Shifted geometries need to be dealt with as best as possible; since they are asymptotic approximations with acceptable error.
Here we have a very-simple P.R. (that could be backed out with relatively no effort), effective, more gracefull implementation for dealing with this situation which needs to be merged.
You are doing development here, arent you, not production.
Suggestion:
With one modification/code test: If the bound box is resolved to be square, use older return value (to maintain max accuracy); if bound box is resolved to be non-square, return PR solution return value.
Continuously changing default settings is for the birds!
Just a thought!
It is just the way "Hole-Detection" was implemented at the time (now, we know better from testing), and Ive seen it as a long term problem that had to be acknowledged and compensated for through the user "awareness".
Shifted geometries need to be dealt with as best as possible; since they are asymptotic approximations with acceptable error.
Here we have a very-simple P.R. (that could be backed out with relatively no effort), effective, more gracefull implementation for dealing with this situation which needs to be merged.
You are doing development here, arent you, not production.
Suggestion:
With one modification/code test: If the bound box is resolved to be square, use older return value (to maintain max accuracy); if bound box is resolved to be non-square, return PR solution return value.
Continuously changing default settings is for the birds!
Just a thought!
-
- Posts: 23
- Joined: Fri Nov 16, 2018 2:00 am
Re: Rotated holes result in different sized Helix tool paths.
I'm not going to have a rough time because I can afford to spend 4 hours to figure out what is wrong. But new users? Maybe they won't.
- aka 'TheRainHarvester" on youtube.
Re: Rotated holes result in different sized Helix tool paths.
We often see here in the forum questions about transforming STL files to FreeCAD models. NormandC used to say that the STL is crap because it is tesselated - where he is right - as opposed to FreeCAD's representation of perfect mathematical objects - where he is almost right, the limiting factor being the computational precision of the hardware.rainharvester wrote: ↑Thu Aug 15, 2019 1:36 pmTesselation isn't the same category as rounding error / truncation.
This "mathematical precision" is probably far away from what we need for paths, where not many machines are able to position better than 1/1000mm, but it seems that using the bounding box is too coarse. If it is possible to use the FreeCAD mathematical object instead - fine, let's do it. If this is not possible for some reason such as an external library, then this is well possible, because the generated G-code is only an output format. But in that case let's use the precision parameter for paths which can be configured in the Path preferences. Let's not use some other parameter which is supposed to control only the visual representation of objects.
Decreasing these display values may result in significant performance issues in rendering complex models.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Rotated holes result in different sized Helix tool paths.
Just to drive the point home further that this is a problem, here is what happens when i change the viewport settings to 10% deviation and 80 degree deflection (not absurd for huge models), this is without rotating the object at all:
- Attachments
-
- Screenshot_20190815_194931.png (143.12 KiB) Viewed 2392 times
Last edited by IMback! on Thu Aug 15, 2019 5:57 pm, edited 1 time in total.
Re: Rotated holes result in different sized Helix tool paths.
And same thing again with PR and part:
- Attachments
-
- test part.FCStd
- (14.22 KiB) Downloaded 64 times
-
- Screenshot_20190815_195412.png (112.18 KiB) Viewed 2389 times
Re: Rotated holes result in different sized Helix tool paths.
These two images just show that these two properties affect the display of models, which is what they were made for.
It is better to show examples where the model itself or the generated G-code is wrong.
It is better to show examples where the model itself or the generated G-code is wrong.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Rotated holes result in different sized Helix tool paths.
no. hint: the diameter from the helix operation is shown, the fact that the visualization accuracy is poor is of course as intended
Re: Rotated holes result in different sized Helix tool paths.
Some people seem to be missing the point. It is NOT just "visualization" that is controlled by the tessellation parameters. OCC does real computations based on those settings, not just display.
If you want to make a special case for every conceivable shape and every operation in order to get around the computation imprecision I suppose that is OK. It just seems a lot better to improve the computation precision for all cases by adjusting a single setting.
Gene
If you want to make a special case for every conceivable shape and every operation in order to get around the computation imprecision I suppose that is OK. It just seems a lot better to improve the computation precision for all cases by adjusting a single setting.
Gene