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: 775
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 7:53 pm

Ratonlaveur's idea looks like a handy quick cheat solution but I'm not sure this is good direction for a final solution.

1. the existing deburr, seems a little unfinished as a deburr tool, ( will post bugs if wished ). This may not be the best base to build on.
2. for a consistent and easily understood UI, I would expect the tool to look like the face surfacing tool, if it needs to be a new tool
3. what seems the most consistent to me is for the profile to be fixed to work on "zero area" faces as it ( allegedly ) used to do. The condition of having a closed loop projection seems artificial from a machining POV ( and thus confusing ). It seems to be entirely a programming difficulty / bug which should be fixed w/o altering the interface if possible.

my 2c.
User avatar
freman
Posts: 775
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 8:02 pm

What is the nature of the zero projection or finite loop requirement which apparently introduced with libArea?

Was this an bug which crept in, a restriction which was imposed by the new library or a condition introduced a new feature ( eg inside/outside ) ?
User avatar
sliptonic
Posts: 1579
Joined: Tue Oct 25, 2011 10:46 pm

Re: Limitations on creating simple paths.

Postby sliptonic » Wed Dec 04, 2019 9:21 pm

You're using terms that I don't recognize.

What's a 'zero projection'?

What's a 'finite loop requirement'?

What's a 'zero area face'?


FreeCAD's offsetting (both libarea and PathArea) are based on Angus Johnson's clipperlib and all the limitations of it apply to any operations that use it. Operations like deburr don't use PathArea at all.
User avatar
freman
Posts: 775
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 9:53 pm

Hi, I did explain what this was about above.

Upthread I posted some output when Chrisb suggested I use profile tool.

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).
Similar output is found in other path tools which cannot operate on edges or faces which do not form a loop with a finite projected area on the normal plane of the tool spindle axis. This leads to the rather odd limitation that it is impossible to get a path on a vertical plane.

The zero area condition also came up when I wanted to cut a 6mm slot with a 6mm tool. This was dismissed as not a bug since IIRC, since there was another way to do it, so it did not matter or I "shouldn't" be doing it anyway.

based on Angus Johnson's clipperlib and all the limitations of it apply to any operations that use it.
So does that mean switching to libArea introduced some restrictions which broke these path tools which , reportedly, were working at some previous point? Since you have a pretty thorough knowlege of this part of the code, it would be helpful to know the nature of the problem, if you can expand on what is happening.

How far back do we need to go to see vertical profile work? Is it recent or really "historical"?
User avatar
freman
Posts: 775
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Wed Dec 04, 2019 10:07 pm

Code: Select all

<Path.Area> Area.cpp(1429): empty projection
I just looked at Path/libarea/Area.cpp and it only has 829 lines and does not contain that string :?

Ah, I've got it, Area.cpp is used twice : Path/App/Area.cpp

Hmm, after a quick scan of the code there, it looks like most of the path tools are implemented as "AreaOps" , presumably the code is heavily geared around the presence of a defined normal vector and the existence of a finite area to operate on.

That may mean a new class of LinearOp is needed or the quick solution RatonLaveur suggested of hacking deburr tool.

Maybe the new class could serve "vertical mill from face", "vertical mill from edge" and deburr ( as it currently works ). ie the new class would be a generalisation of deburr, of which deburr becomes a special case.

does that make sense in terms of existing code structure?
User avatar
freman
Posts: 775
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Thu Dec 05, 2019 5:56 am

Just found this problem using deburr on a vertically oriented cylindrical surface. May be relevant re. using deburr as a base for vertical surfaces:

https://forum.freecadweb.org/viewtopic.php?f=15&t=41440


[EDIT]

confirmed the deburr tool seems to suffer from the same restriction: it only works on a closed loop of edges

Even stranger, it does seem to "work" for a rectangular, vertical face. However, I'm not sure what this means. I suspect it will cause a tool crash in this example with a countersink tool. See cylindrical-deburr file.

confirmed, even with a straight tool the result on a vertical face is clearly wrong and will cause a tool crash. It is creating a path on the face as though it was perpendicular to the tool spindle even though the plane is parallel to the spindle. Ouch!.

Separate thread and bug report for the tool crash.

https://forum.freecadweb.org/viewtopic. ... 35#p351935
https://www.freecadweb.org/tracker/view.php?id=4212

I suspect fixing that bug will mean introducing a check of plane orientation similar to the other AreaOps. This may block the idea of using Ratonlaveur's idea of step down if this is not taken into account !
Attachments
block-tool-crash.FCStd
(19.07 KiB) Downloaded 1 time
cylinder-deburr-vertical.FCStd
(35.69 KiB) Downloaded 1 time
CoderMusashi
Posts: 15
Joined: Mon Nov 19, 2018 8:26 pm

Re: Limitations on creating simple paths.

Postby CoderMusashi » Fri Dec 06, 2019 11:30 pm

Simple fast 2D GCode generation check out this post.
https://forum.freecadweb.org/viewtopic.php?f=22&t=41495

The macro is easy to edit for other needs like tool number, beginning prep code and ending prep code for all your needs. Simple step down profiling of a line.
User avatar
freman
Posts: 775
Joined: Tue Nov 27, 2018 10:30 pm

Re: Limitations on creating simple paths.

Postby freman » Sat Dec 07, 2019 8:15 am

Hi Mushati,

thanks for the idea of using a macro, that may be a good workaround for the lack of vertical milling capability. Currently I've just had to do this by hand coding on the machine , with a straight back and forth in x or y this is quicker than spending the evening trying to trick FreeCAD into doing something it does not want to do.

The real need here is for when there is something less trivial like the curved vertical surface in the model which I attached at the top of this thread.

Now it may be possible to attack this problem with a macro script if I can select the two edges ( a straight line and an arc ) and then work on that with a script. I could also use the deburr tool to get all gcode for a single pass and use a macro to replicate it downwards.

That is at least possible workaround. Many thanks for pointing this out.

In fact my simplest solution would be do all the post processing etc with FC to get the single deburr cut for the machine then use a text manipulation tool like awk or sed to duplicate the gcode block and tweak the z values .

It's all a bit messy but does provide a solution which I did not have a couple of days ago when I needed to cut this part.

[BTW, had to do that cut with 3d surface , which ends up making a staircase approximation of the cylindrical part. That was pretty messy on wood, but fortunately this piece was structural and not visible, so it passed QA. Sadly, 3d-surface is now also broken on recent master : https://forum.freecadweb.org/viewtopic.php?f=15&t=41470 ]

Thanks for the new angle on this problem.
chrisb
Posts: 19703
Joined: Tue Mar 17, 2015 9:14 am

Re: Limitations on creating simple paths.

Postby chrisb » Sat Dec 07, 2019 1:41 pm

I tried using this idea with pure Path tools, alas PathArray doesn't seem to work in Z direction. replicating the deburr operation works fine in X and Y.