Waterline machining proposals

[JulianTodd]

I'm trying to find a useful contribution to make to 3axis milling.

It seems there is no 3D horizontal slicing of a triangulated model by a toolshape. (Correct me if I'm wrong!) This is the basis of most roughing strategies (eg the Adaptive Clearing).

I have coded this algorithm for commercial CAM software packages at least two times over the decades, so this outline should work in the long term.

It's based on a mesh model of a 2D area where the boundary can be subdivided until it fits the required machining tolerance. (See subdividingarea.png for a picture of how this model looks: red is inside, blue is outside, and the the lines are a consistent network of probing lines that look for cuts across the boundary; I'll write up a better description in due course.)

The code is in pure Python and quite slow. But it is better to get the answer right, rather than fast, and do as much we can to simplify the algorithm enough into a state that it can be made it parallelizable. I would be most excited if the calculations were clear enough that they could be done on the GPU; there is a great deal of similarity between graphics rendering and toolpath positioning, so there is no reason the layers shouldn't be calculated to an arbitrary precision in a split second. I would very much like to have something that outperforms that outperforms all the code that's in the commercial CAM software.

The code so far is here: https://github.com/goatchurchprime/tran ... icer.ipynb

It remains to extend it to handle the tool shaft, toroidal cutter shapes, and input boundaries.

Could this for now be done as a just Macro, so I can find how to connect it to the FC primitives? (I have pointed out elsewhere that I think that CAM algorithms ought to be executed in a separate process from the main application, which makes the interface even simpler to speculate.)

subdividingarea.png (37.16 KiB) Viewed 2910 times

[sliptonic]

It shouldn't be difficult to do as a macro.
I cloned your repo into my macro directory (customizable from preferences. Mine is in a non-standard location)

I had to add it to the python path so it could find the modules but then I was able to import from tribarmes.

Code: Select all

newpath = '/home/brad/Dropbox/FREECAD/transition-CAM'
sys.path.append(newpath)

from tribarmes import TriangleBarMesh, MakeTriangleBoxing

stlfile = newpath + "/stlsamples/frameguide.stl"

tbarmesh = TriangleBarMesh(stlfile)
tboxing = MakeTriangleBoxing(tbarmesh)

EDIT: stupid mistake. Works to that point. Haven't tested further.

[JulianTodd]

It's going to take a bit more development till it can be used; I scavenged it from code I made a couple of years ago that was working towards some 5-axis theory. (I'm not going to come out of nowhere fully-formed like the Adaptive Clearing feature did.) I just need to make sure I'm not repeating something that is already in the system.

[yorik]

Hi,

This looks great!! Integrating this in FreeCAD doesn't seem hard. Most FreeCAD objects are Part-based (which means, they have an OpenCasCade-generated shape), usually located in their Shape property. I say most, becuase you can also have mesh objects, and non-geometric objects too, or not Part-based (the toolpaths from Path module for example).

So to get the shape of an object in your current document:

Code: Select all

myShape = FreeCAD.ActiveDocument.getObject("ObjectName").Shape

(beware that FreeCAD objects have an internal, unique Name, and another name that appears in the tree view, that is called Label, that is not necessarily equal to Name and not necessarily unique)

from any given shape, you can get a triangulated version:

Code: Select all

myShape.tessellate(1) # the argument is the precision of the tessellation

This will return you a list of two lists, one of 3D points and one of triangle vertex indices.

That's probably all you need to make your algo work.

But the big advantage of Part shapes is their absolute precision, compared to triangulated meshes. So maybe there would be some advantage to take there... On the other hand, working with meshes can be faster...

Then, the cool thing could be to use the Path module to display the result. A Path object is constructed with simplified GCode data, for example:

Code: Select all

import Path
myPath = Path.Path("G0X0Y0G1X1Y1")

but there are more methods to create paths, see the Path Workbench docs. It should not be hard to convert the list of points returned by your algo to a Path toolpath

then to turn your Path into a visible, existing object in the FreeCAD document:

Code: Select all

myPathObj = FreeCAD.ActiveDocument.addObject("Path::Feature","testpath")
myPathObj.Path = myPath

or simply:

Code: Select all

myPath.show()

Would be me, I would test all this in a macro, because it's easy to work with and you can go quite far there (add input dialogs, etc..) but at a later point it could also be all embedded into a parametric object, which would take a shape-based object as input, and generate the path with your algo, based on other needed parameters.

The Power users hub has quite a lot of doc about working with Part shapes, creating parametric objects, etc.

[JulianTodd]

Hi, I've got a few of questions/points on how to approach this. I'll have to number them:


1) Does the code in the .FreeCAD/Macro/ directory have essentially the same content/features/capability as the code I'm finding in /freecad-build/Mod/Path/PathScripts/PathChamferGui.py ?


2) Is there a recommended generic/blank machining operation that it's best to start from when developing a new one? This would provide all the standard methods for obtaining the shape, tolerances, boundaries, tool radius (I can't find it in this guis), as well as the right way to drip feed a toolpath back to the UI.


3) There are a lot of very similar toolpath operations, such as raster passes, spiral machining, radial machining, that are just standard shapes dropped within a boundary onto the part (accounting for the toolshape). These can be pretty handy, while easy to do.


4) Toolpath linking is an issue common to many operations, (esp those in 3). It can be useful to break these into two separate operations. In the linking operation you've got choices of reordering, 2-way or one-way machining, curl in and curl out radius, and so on.


5) What's a good way to develop/debug these operations? It seems you can run from Python without the FC interface, with:
doc = FreeCAD.open("logocarve.fcstd")
But doesn't this lose the context -- ie which part of the tree was selected when you clicked on the operation? Are there any unit tests of these opeprations for guidance?


6) There is a MeshPart.meshFromShape(Shape) function, which is far superior to the Shape.tessellate(), because you've got far more options to control the quality of the triangulation. I'll be having a look at that one day.

I am an opponent of the fallacy of "absolute precision" of the CAD shapes in relation to machining. CNC must work to a non-zero tolerance -- otherwise how could you have any distance between the points in the G-code? -- so all you do is give half that tolerance to the tessellation and the other half to the machining algorithm, and it's as good as can be.

Unfortunately, most CAD companies believe in the fallacy of "absolute precision", so they don't think it's important to make their tessellate() function any good. A better distribution of triangles could make the CNC algorithms run much faster.

[mlampert]

1) Does the code in the .FreeCAD/Macro/ directory have essentially the same content/features/capability as the code I'm finding in /freecad-build/Mod/Path/PathScripts/PathChamferGui.py ?

Generally speaking yes, there is no difference except that you cannot control when a macro is being executed, whereas tools/scripts in a WB can be enabled/disabled depending on user selection and such.

2) Is there a recommended generic/blank machining operation that it's best to start from when developing a new one? This would provide all the standard methods for obtaining the shape, tolerances, boundaries, tool radius (I can't find it in this guis), as well as the right way to drip feed a toolpath back to the UI.

I meant to do that but unfortunately have not gotten around to do that. As a simple example PathSurface is probably the easiest - and then have a look at PathOp.py which holds the base classes and framework. The functions in there have a doc string - which hopefully makes some sense.

If you want to work on an UI integrated op you might also want to look at PathOpGui.py, it's the UI pendant to PathOp.py and provides the UI framework for the ops with the standard components most ops have implemented.

I shall lift my behind off the couch and start documenting these in a wiki or somewhere. I know sliptonic has some notes - I'll let him comment since he's probably got more and better answers for you anyway

5) What's a good way to develop/debug these operations? It seems you can run from Python without the FC interface, with:
doc = FreeCAD.open("logocarve.fcstd")
But doesn't this lose the context -- ie which part of the tree was selected when you clicked on the operation? Are there any unit tests of these opeprations for guidance?

It depends on what you do. FC does have a unit test framework which works pretty good for generic algorithm and logic tests. Recently the option to run UI unit tests was added but I have no personal experience with that. If you're working on a macro I actually recommend opening the python file in FC directly, that way you still have access to the UI and you can use "Play" button to execute the script.
I've also heard that ppl load FC into python IDE with a python debugger and whole nine yards. I think the requirement for that is that python can find the FC shared library, then you can just import it and go from there ... Again, no personal experience - but if you search the developer's forum for python debugger you'll find pointers.

I'm afraid that's all the wisdom i can offer, but please feel free if you have more questions.
HTH

[sliptonic]

I've added a branch to my repo here:
https://github.com/sliptonic/FreeCAD/tree/devhelp/NewOp

This adds a template operation called NEWOP along with a gui command, icon, and task panel.

If you build with this branch, you'll have a new menu item under supplemental commands that adds the NEWOP to the job.
The op itself only adds a couple comment lines to the post-processed output but gives an idea of how all the pieces come together.

I also have a page of notes on my wiki:
https://github.com/sliptonic/FreeCAD/wi ... g-for-Path

No guarantees that I didn't miss anything. If you find something missing please let me know so I can update this for future devs.

[GeneFC]

I am an opponent of the fallacy of "absolute precision" of the CAD shapes in relation to machining. CNC must work to a non-zero tolerance -- otherwise how could you have any distance between the points in the G-code? -- so all you do is give half that tolerance to the tessellation and the other half to the machining algorithm, and it's as good as can be.

This has actually become an occasional problem in the FreeCAD Path WB over the past year or so. Some of the newer approaches, such as the path.area method, intentionally lowered the precision of the path generation, and this lowered precision showed up in real parts made on real machines. Several corrections and updates have been made, and it does not appear to be a common issue now.

I do not care how fast or efficient the computer work becomes if the end result on a physical part is not correct.

Gene

[chrisb]

I do not care how fast or efficient the computer work becomes if the end result on a physical part is not correct.

I would even go further: I care for clean GCode. E.g. if I have modeled a circle I want to see a G2 or G3 in the GCode and not some tesselation, even if the resolution is beyond the machines precision. There are several reasons for this

- One is very practical: It does not consume much of my very limited memory (precise: ...memory of my machine )
- Besides that: a situation will come, where I have to edit the GCode. That's only possible if the code is as clean as possible.

[mlampert]

I tend to agree with JulianTodd, machining is a manufacturing process which always is measured to a maximum tolerance. And it doesn't matter which component of the process chews up what percentage of that tolerance, as long as the end result stays within specified tolerances.

About reading and editing the actual g-code. I wonder if that has more to do with the quality of the produced g-code and the trust we put into the tools generating it than with an actual requirement. Personally, if I wouldn't be debugging Path I wouldn't care about the actual g-code (and between you and me, it is the worst programming language I've ever dealt with).

This does not address the memory issue which I have no experience with. My controller has 2kB of RAM so I have to trickle-feed the g-code anyway.