Limitations on creating simple paths.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Limitations on creating simple paths.
Hi,
I am constantly being frustrated ( ie prevented from doing a job ) by what seems like inexplicable limitation on creating very basic and essential path operations using FreeCAD.
In this case I just want to make a simple rectangular cut down the side of a rectangular bar. There could hardly be anything simpler. I have an 8mm tool which could do it in one cut ( subject to repeats for depth of cut ), yet it seems impossible to get a path on this using the path tool.
The first two bounding choices produce no path at all ( tool would need to be less than cut width ) yet if I bound on stock , it dumbly eats away half the work piece.
Once again I find myself off the the workshop to do a job by hand coding Gcode instead of using FreeCAD.
Now there maybe some way to trick FC into doing this by adding fictional "helper geometries" or lying about the shape and size in the model to fool it into doing what is needed but this all becomes a bit of a mess.
The other cut on this job I had to with 3D in a rather rough finish on the curved section instead of the obvious way of facing the curved surface as a vertical since FC refuses to put a path on a vertical face ( an issue which I have highlighted before ).
These are not complex or obscure operations but some of the most obvious cuts that one may want to do. Can something be done to solve these short comings?
Thanks.
OS: Fedora 31 (Thirty One) (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18821 (Git)
Build type: Release
Branch: master
Hash: 379d04166431517f3eef59c5a55b6e2979562722
Python version: 3.7.5
Qt version: 5.12.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)
I am constantly being frustrated ( ie prevented from doing a job ) by what seems like inexplicable limitation on creating very basic and essential path operations using FreeCAD.
In this case I just want to make a simple rectangular cut down the side of a rectangular bar. There could hardly be anything simpler. I have an 8mm tool which could do it in one cut ( subject to repeats for depth of cut ), yet it seems impossible to get a path on this using the path tool.
The first two bounding choices produce no path at all ( tool would need to be less than cut width ) yet if I bound on stock , it dumbly eats away half the work piece.
Once again I find myself off the the workshop to do a job by hand coding Gcode instead of using FreeCAD.
Now there maybe some way to trick FC into doing this by adding fictional "helper geometries" or lying about the shape and size in the model to fool it into doing what is needed but this all becomes a bit of a mess.
The other cut on this job I had to with 3D in a rather rough finish on the curved section instead of the obvious way of facing the curved surface as a vertical since FC refuses to put a path on a vertical face ( an issue which I have highlighted before ).
These are not complex or obscure operations but some of the most obvious cuts that one may want to do. Can something be done to solve these short comings?
Thanks.
OS: Fedora 31 (Thirty One) (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18821 (Git)
Build type: Release
Branch: master
Hash: 379d04166431517f3eef59c5a55b6e2979562722
Python version: 3.7.5
Qt version: 5.12.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)
- Attachments
-
- rib.FCStd
- (58.59 KiB) Downloaded 42 times
Re: Limitations on creating simple paths.
How about Profile?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Limitations on creating simple paths.
Path workbench has been built by a very small number of programmers, mainly sliptonic and mlampert, who have proven by creating this powerful workbench that they really know what they are doing. In their spare time.
We all know, it's not perfect yet, but if you say that something is simple, it sounds like an accusation. And then you should sit down, write a proposal to be discussed here, and code it. In your spare time. It's as simple as that.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Limitations on creating simple paths.
If you say that something is simple it sounds like an accusation.
No, it's not an accusation. The point of that comment was that it is not some obscure operation but something basic which is missing. Since the solid basis which is already in place is all voluntary work there is no "accusation" in anything being missing, it is pointing out that this may be something worth fixing when possible since it seems fundamental.
If I did not have to spend so much time just getting FC to build and run, my intention was to try to improve some of these areas. Breaking py2 wasted a lot of the free time I had available and involved me in a major distro upgrade which also took me down a rabbit hole of bug reports and wasted time. I even installed a Ubuntu based distro thinking this may make life easier here: yet more time wasting and bug reports on the distro where everyone just ends up saying " pull requests are welcome" instead of fixing anything.
How about Profile?
Code: Select all
Profiling Select Mode
<Path.Area> Area.cpp(1287): project failed
<Path.Area> Area.cpp(1429): empty projection
PathProfileFaces.ERROR: Unable to create path for face(s).
It seems that if the face has zero area when projected on the normal plane of the spindle axis, it gets rejected. So any plane or curved surface perpendicular to the tool fails.
The aim of this thread was to start a discussion on how that could be fixed. Or for someone with knowledge to say that it could be done, did not need to be done , or whatever.
If we can agree on whether FC is unable to cut a vertical face and whether this is desirable or a stupid idea, we would be one step forward.
-
- Posts: 991
- Joined: Wed Mar 27, 2019 10:45 am
Re: Limitations on creating simple paths.
What you want seems actually like a generalisation of the "Deburr" tool. Made by mlampert
Which could be named "profile based on edge", with a tick box for "deburring" (automatically applies the offset necessary for deburring, with the deburring tool parameters). And the possibility to step down the line and control the overshoot.
It seems to me if you can apply a step-down to Deburr, you got your OP, a "basic" python prototype could work (literally stepping down multiple deburr operations) or really modifying the Deburr tool.
Which could be named "profile based on edge", with a tick box for "deburring" (automatically applies the offset necessary for deburring, with the deburring tool parameters). And the possibility to step down the line and control the overshoot.
It seems to me if you can apply a step-down to Deburr, you got your OP, a "basic" python prototype could work (literally stepping down multiple deburr operations) or really modifying the Deburr tool.
Re: Limitations on creating simple paths.
Either deburr, or even better Profile based on edges, where the path hasn't have to be closed. That would have the advantage, that radius compensation is already included.
Herbert pointed out recently that this used to work before switching to PathArea.
Herbert pointed out recently that this used to work before switching to PathArea.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Limitations on creating simple paths.
Thanks, so this is a regression. That may explain the absence of what I'd deemed an obvious function. That probably means it's easily fixed since it used to work and has already been done.
This zero area thing has come up in a number of different oddities I have pointed out.
-
- Posts: 991
- Joined: Wed Mar 27, 2019 10:45 am
Re: Limitations on creating simple paths.
Well, I agree with both chrisb and freman, but since Deburr already generates tool-paths based on an arbitrary open profile, I feel like maybe the solution for a versatile profiling op is there.
I don't know the inner workings of PathArea, but if it was used, there may have been a good reason.
The question is rather, which is the more optimum/feasible solution:
- Adding a layer to the deburr tool that makes it recursive with a step-down.
- Re-working the profile tool to allow it to get out of PathArea/closed loops only.
That, I cannot answer.
I don't know the inner workings of PathArea, but if it was used, there may have been a good reason.
The question is rather, which is the more optimum/feasible solution:
- Adding a layer to the deburr tool that makes it recursive with a step-down.
- Re-working the profile tool to allow it to get out of PathArea/closed loops only.
That, I cannot answer.
Re: Limitations on creating simple paths.
Like this?RatonLaveur wrote: ↑Wed Dec 04, 2019 12:24 pm - Adding a layer to the deburr tool that makes it recursive with a step-down.
Re: Limitations on creating simple paths.
That's cool.
It probably would probably be good if it was structured like the other similar path tools, with start depth, final depth, step down; finish depth is not really relevant on a side cut.
As raton suggested, this probably mean renaming the tool since this would be confusing as "deburr".
It probably would probably be good if it was structured like the other similar path tools, with start depth, final depth, step down; finish depth is not really relevant on a side cut.
As raton suggested, this probably mean renaming the tool since this would be confusing as "deburr".