Limitations on creating simple paths.

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

Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 8:59 am

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)
Attachments
rib.FCStd
(58.59 KiB) Downloaded 18 times
chrisb
Posts: 28036
Joined: Tue Mar 17, 2015 9:14 am

Re: Limitations on creating simple paths.

Postby chrisb » Wed Dec 04, 2019 9:31 am

freman wrote:
Wed Dec 04, 2019 8:59 am
In this case I just want to make a simple rectangular cut down the side of a rectangular bar.
How about Profile?
chrisb
Posts: 28036
Joined: Tue Mar 17, 2015 9:14 am

Re: Limitations on creating simple paths.

Postby chrisb » Wed Dec 04, 2019 9:45 am

freman wrote:
Wed Dec 04, 2019 8:59 am
There could hardly be anything simpler.
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.
User avatar
freman
Posts: 1228
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 10:06 am

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).
This is same issue I raised previously and it was agreed that there was no path tool which would do it. ( I previously just cited a planar vertical face but the curved face produces the same issue ).

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.
RatonLaveur
Posts: 794
Joined: Wed Mar 27, 2019 10:45 am

Re: Limitations on creating simple paths.

Postby RatonLaveur » Wed Dec 04, 2019 10:29 am

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.
chrisb
Posts: 28036
Joined: Tue Mar 17, 2015 9:14 am

Re: Limitations on creating simple paths.

Postby chrisb » Wed Dec 04, 2019 10:54 am

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.
User avatar
freman
Posts: 1228
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 11:21 am

chrisb wrote:
Wed Dec 04, 2019 10:54 am
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.
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.
RatonLaveur
Posts: 794
Joined: Wed Mar 27, 2019 10:45 am

Re: Limitations on creating simple paths.

Postby RatonLaveur » Wed Dec 04, 2019 12:24 pm

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.
mlampert
Posts: 1480
Joined: Fri Sep 16, 2016 9:28 pm

Re: Limitations on creating simple paths.

Postby mlampert » Wed Dec 04, 2019 5:50 pm

RatonLaveur wrote:
Wed Dec 04, 2019 12:24 pm
- Adding a layer to the deburr tool that makes it recursive with a step-down.
Like this? :D
Capture.PNG
Capture.PNG (13.41 KiB) Viewed 438 times
User avatar
freman
Posts: 1228
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 6:48 pm

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".