Discussion: Path.Area and Path::FeatureArea (PR 460)

[sliptonic]

User @realthunder submitted a pull request recently to merge changes related to libarea. It also introduces a FeatureArea which is a user level object. The pull request is pretty large and includes some very interesting things but needs additional discussion. I asked a mod to move the thread from the PR section to here but it didn't happen so I'm starting a new thread to discuss this work. The original thread is here and the pull request also has some comments.

A little bit of background might be useful. libarea is a c++ implementation of the clipper algorithm for offsetting. It was used extensively in HeeksCNC and is now used extensively in FreeCAD Path. It does some things that OCC either can't do or is very buggy about. So it's a very important library for us. libarea includes a Python wrapper library called Area. Most of the user-facing functionality in Path is written in Python and uses this wrapper.

If I understand his work correctly, @realthunder has written a new wrapper which exposes much more of libarea's capabilities and could replace Area. This is very interesting to me but since there's no example python code using it, I haven't gotten very far exploring it.

The FeatureArea is a different beast. You can read the comments in the other thread but if you're comfortable using git and building from source, I encourage you to try it out and comment here. This object does not produce gcode yet but creates wires that could be processed for gcode in a later step.

My personal feeling is that this pull request represents two different units of work and it would be easier for us to evaluate it if it was split into two different PRs. I'd like to experiment more with the new wrapper but I'm afraid the FeatureArea will be confusing to end-users in its current form.

Looking forward to what the community thinks.

[realthunder]

Yeah, FeatureArea does seems stand out. But, it definitely can be useful to someone. I am using it as the main workhorse to build PCB shape for milling. It is so much easier to use than stock FC objects if possible at all. Okay, I can do it with Path.Area script object only, but since FeatureArea can have linked objects, and I am using Sketch as child shape. It means I can easily modify the outcome shape! How wonderful is that. There must be a place for it without confusing the user.

BTW, I just submit a new pull request that fixed Draft.makeSketch, so that it can convert any planar shapes (at least any shapes I've tested) into sketch. Think about the possibility here, say, an advanced feature, maybe a task window to let user manually modify the path wire.

[realthunder]

I copy my Path.Area sample code from the other thread here.

Path.Area is quite easy to use. All member functions are documented. Just treat it as if you are using FeatureArea. You can set any parameters (same name corresponding to FeatureArea property without space) you want to change in constructor, or change later using setParams(key=value...)

Code: Select all

import Path,Part

# optionally change any parameters you want in constructor
area = Path.Area(SectionCount=-1, Offset=1.0, PocketMode=1)

# optionally set a shape for working plane, you can turn off coplanar checking for speed up.
area.setPlane(Part.makeCircle(10))

# op=1 means cut, see docstring for values of op
area.add(Part.makeBox(10,10,10))
area.add(Part.makeCylinder(4,10,App.Vector(5,5,0)),op=1)

Part.show(area.getShape())

# Or show individual sections
for shape in area.Sections:
	Part.show(shape)

That's it, you get exactly the same result as FeatureArea plus the fact that you can combine shapes with different operation code. If you intend to produce many different type of offset or pocket, a more efficient way is to call area.makeOffset and area.makePocket directly. See the docstring for details. These two function operate on but not changing the cached shape inside Path.Area. Adding more shapes or changing any parameter will invalidate internal shape cache. There is no way to remove shape. I don't think that's necessary. To create a new empty area with the same parameters

Code: Select all

new_area = Path.Area(**area.getParams())

So in fact, most of the fun part is how you play with the settings. See docstring in getParams(). If it is too big to show,

Code: Select all

print Path.Area().getParamsDesc()

[sliptonic]

Yeah, FeatureArea does seems stand out. But, it definitely can be useful to someone. I am using it as the main workhorse to build PCB shape for milling. It is so much easier to use than stock FC objects if possible at all. Okay, I can do it with Path.Area script object only, but since FeatureArea can have linked objects, and I am using Sketch as child shape. It means I can easily modify the outcome shape! How wonderful is that. There must be a place for it without confusing the user.

I have no doubt that it's useful, it's just...different from the normal workflow. As Yorik pointed out the whole point of the Path workbench is to produce gcode. Our general assumption within Path is that object geometry is already done and we're just concerned with how to mill/cut it. So all the user-facing objects are related to that goal. Tool creation, job management, path creation, and path modification are all related to producing output to be consumed by a cnc machine.

In this case, you're still producing base geometry. The fact that it uses libarea is incidental, which is why it's confusing.

PathArea seems to be a 'swiss army knife' for working with libarea and there's a way that I can see the tool having a home within the Path workbench (and we would probably want to have it buried some place in an 'advanced' or 'utility' menu) and that is as a test fixture / diagnostic tool for the libarea wrapper itself. Since your tool produces more primitive objects (wires) than the other Path objects, it might be more convenient for the developers to visualize what's happening before those wires are converted into Path commands. Advanced users might find it useful for the same kind of workflow you're using.

[realthunder]

I have no doubt that it's useful, it's just...different from the normal workflow.

So what is the normal workflow in Path Mod. Because it is under heavy development, I can't seem to find any instruction on it. Let's say, I have a model in FC. In order to mill it, do I have to create a work piece and then cut it with the model? Is this step necessary? If so, does Path offer any tools to do that? Boolean operation with complex shapes fails easily.

[bill]

This is a big mod and needs to be treated appropriately. Chunking it into Path probably is not the most prudent move. This goes against the paradigm how FreeCAD develops.

From what I have seen,very often/typically, functions prove their worth as a Macro or WB, then become so useful, the work is incorporated

But, you need a temp sandbox

"QUICK SAND BOX" solution:

My suggestion, would be to Macrotize this functionality; provide necessay libs and let the dev/testing begin!

I definitely would like to poke around in the pyth lib wrappers.
Sounds like a great solution for ROUGHING. Put a parametric-solid in a cuboid-solid(primitive) and have at it!
Plus, the PCB solution; I have a need for that; always have and always will!

Sure, there is a lot of advanced function beyond the average user; but then again I dont use/or have ever looked at 85percent of FreeCAD more that once.

[yorik]

I think it's OK to "differ" from the "normal" way. After all, this is open-source software, nobody is forced to go in a certain direction. And it seems to me that indeed one can imagine tools that only work on shapes, but that are useful anyway for Path/CNC, and not much for other areas, so they would fit best in Path. And maybe realthunder will soon add support for gcode generation!

I think all we need to do is just think a little bit in how to best categorize these tools in the interface, so the user sees clearly how they differ from the others.

[sliptonic]

I have no doubt that it's useful, it's just...different from the normal workflow.

So what is the normal workflow in Path Mod. Because it is under heavy development, I can't seem to find any instruction on it. Let's say, I have a model in FC. In order to mill it, do I have to create a work piece and then cut it with the model? Is this step necessary? If so, does Path offer any tools to do that? Boolean operation with complex shapes fails easily.

Yeah, it's still rough but improving I've started doing videos to document path but the basic workflow looks like:

1. Select the base object and create a Job. A job is a container for a set of operations. A job can be post-processed to produce gcode that will run on a machine. Ultimately, a job will specify the base object, the transformation of the object to machine coordinates, stock material, and machine (post-processor).
2. Add tools. A job has a list of tools. The specific geometry of the tool is used to calculate the path. Tools have tool number that will be passed through the gcode to the machine if tool changes are needed.
3. Add operations to the job. Some of these can be added with a click to get a pretty reasonable output. For example contour will produce an outside profile to separate the part from surrounding stock. Other operations require more insight and planning from a skilled operator. For example, the operator may choose to clear a circular hole with either a helical path or with a drill operation. The part alone doesn't have enough information to determine the right kind of gcode to produce so the user must help out.
4. Besides creating and configuring the basic operations, the user is also sequencing them. The Part just defines a round hole but if accuracy is important, that will require first 'spot drill', then peck drill to depth, then ream for roundness. Those are three operations to create a single accurate feature.
5. Basic operations can then be modified and refined to deal with real-world limitations of tools and machines. This is a dressup. For instance cylindrical tool cutting an inside corner might need to overcut a bit to clear all the material, so we have a 'dogbone' dressup. A dragknife might need to move in a special way to pivot around tight corners and so we have a 'dragknife' dressup.
6. When the job and operation is correct, post-process to generate the gcode from the path commands and write it to a file for execution.

[sliptonic]

I copy my Path.Area sample code from the other thread here.

Path.Area is quite easy to use. All member functions are documented. Just treat it as if you are using FeatureArea. You can set any parameters (same name corresponding to FeatureArea property without space) you want to change in constructor, or change later using setParams(key=value...)

I'm getting some very strange results.

Code: Select all

import Path
area = Path.Area(FitArc=True, Offset=1.0)
area.setPlane(Part.makeCircle(10))

If I enter those commands one at a time in the console, it works fine.
If I run the whole thing from a macro, I get:

Code: Select all

Traceback (most recent call last):
  File "/home/brad/Dropbox/FREECAD/pathareatest.FCMacro", line 11, in <module>
    area.setPlane(Part.makeCircle(100))
<class 'Base.FreeCADError'>: Wrong parameters, call getParamsDesc() to get supported params

[chrisb]

To me the new approach seems to be a new implementation of the Part Design Pocket operation by means of milling. This is an operational approach compared to the declarative approach we have now. And yes, sometimes I would have liked to see a pocket created step by step. So this could be discussed by a larger group of users. We discuss it here in the Path forum onlyi because it uses similar techniques as are needed to create milling paths.

As for the usability of these techniques for Path generation that's something different. I have the strong feeling, that an integration would be a step forward, e.g. I like the visualization of the milling tool - we have discussed this here before.
From a user's point of view the integration is important, I don't want to have Frankenstein's Monster made of spareparts where I always have to know where they come from in order to be able to use them. To keep the picture: I want a seamless skin and one arm on each side is enough. I don't need two versions of the same function.
I don't mind the workflow (although the workflow described by sliptonic seems sensible to me and I already got accustomed to it and it has proven to work) but I would appreciate it, if it where the same in all corners of the Path Workbench.
As I have mentioned in the thread of the pull request I want the same mode of tool selection, the same colour model and the same mode of operation invocation. It can change, but it should not be mixed.
From a programmer's view it sounds phantastic to have more of the powerful libarea exposed to python. But again, there should be only one interface even if that means some refactoring.
I know that I can of course not request these things, but I thought you might want to know what I would prefer.