Limitations on creating simple paths.

[freman]

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)

[chrisb]

In this case I just want to make a simple rectangular cut down the side of a rectangular bar.

How about Profile?

[chrisb]

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.

[freman]

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]

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]

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.

[freman]

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]

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]

- Adding a layer to the deburr tool that makes it recursive with a step-down.

Like this?

Capture.PNG (13.41 KiB) Viewed 438 times

[freman]

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