Added Path.Area and Path::FeatureArea

[realthunder]

Pull request link: https://github.com/FreeCAD/FreeCAD/pull ... -274108849

Path.Area is aimed to fully expose the power of libarea/ClipperLib. It is a python scriptable object, which is backed by Path::Area c++ class. Path::FeatureArea is the companion document object. This single feature is capable of doing:

• Boolean operation on planar shapes (Union, Difference, Intersection, Xor)
• Multi-pass 2D offset
• Generating pocketing tool path
• Multi-slicing of solid shapes
• Stroke of generated path
• Any combination of the above steps within one feature, with linked children Part.Feature derived objects
• Exposed many libarea and ClipperLib internal settings for fine tuning

There are so many things this feature can do, I don't know where to begin. I originally wanted to try PCB milling with FCAD, but didn't get very far. FCAD doesn't really handle very well with 2D shape operations. Simple face cutting can fail randomly. Then I discovered the wonderful libarea, which build on the even better ClipperLib, and they are already there is the Path Mod. They are already being used in Path, but with simply python bindings only. So, I decided to come up with a better wrapping. Here comes the Path.Area, it is originally only intended for 2D operation, but now it can do 2.5D, too.

Let start with a cylinder Part. Say I want to mill this shape out of a Cube material. Just go head create the two objects.

Screenshot from 2017-01-21 00-25-58.png (173.72 KiB) Viewed 4006 times

Now, activate the Path workbench. First select the Cube, then the Cylinder, and finally click the Path Area (circled in red) button

Screenshot from 2017-01-21 00-26-41.png (147.27 KiB) Viewed 4006 times

This creates a Path::FeatureArea with two children shapes. It uses the first planar face it can find as the workplane, all other non-coplanar shapes are ignored. Now we need to change the workplane. Hide FeatureArea, show the Cube. Now select the FeatureArea in the treeview (this way we selects the whole object, not any sub elements), and hold on control key to select a face on the Cube (usually the XY face), finally click the button right besides Path.Area button.

Screenshot from 2017-01-21 00-27-42.png (198.94 KiB) Viewed 4006 times

Once the button is clicked, the FeatureArea will be shown with the swithced face. Hide the Cube to confirm,

Screenshot from 2017-01-21 00-28-23.png (183.95 KiB) Viewed 4006 times

Show back the Cube, click FeatureArea in the tree view, change Operation from Union to Difference. Now, let the fun begin. Click FeatureArea in the treeview, scroll down to Section, enter -1 in Section Count, you will get this,

Screenshot from 2017-01-21 00-29-19.png (216.96 KiB) Viewed 4006 times

Wait, I can only attach five pictures? Bummer

[realthunder]

Set PocketMode to ZigZagOffset,

Screenshot from 2017-01-21 00-30-34.png (241.72 KiB) Viewed 4002 times

Change to PocketMode to Offset, with a smaller ToolRadius, 0.3

Screenshot from 2017-01-21 00-31-44.png (276.06 KiB) Viewed 4002 times

Add extra offset traces by setting ExtraPass to 2,

Screenshot from 2017-01-21 00-33-14.png (278.9 KiB) Viewed 4001 times

Turn off PocketMode, the offset lines changed to three. This is because in Pocket mode, the outer offset is discarded in order to achieve offset then pocket function, i.e. enlarge the pocketing area but without the extra offset line. Something like this,

Screenshot from 2017-01-21 00-30-59.png (249.37 KiB) Viewed 4002 times

With the pocket off, and offset ExtraPass 2, now enable Thicken. The offset traces are thickened in width of ToolRadius. This function is intended to let you visualize your toolpath coverage,

Screenshot from 2017-01-21 00-34-28.png (242.22 KiB) Viewed 4002 times

Okay, I'm not done yet.

[realthunder]

To see some complex shapes, I wrote a script to import Kicad PCB file, the use FeatureArea as the main work horse to build the final copper shape step by step,

Screenshot from 2017-01-21 00-39-38.png (224.68 KiB) Viewed 3997 times

And the above unified shape comes from many small shapes, as can be seen from the treeview, and also below,

Screenshot from 2017-01-21 00-40-30.png (251.16 KiB) Viewed 3997 times

Now, simply change the Offset to 0.5, ExtraPass 1 on the top level FeatureArea, the PCB isolation routing is almost done, partly enlarged as below

Screenshot from 2017-01-21 00-41-52.png (257.7 KiB) Viewed 3997 times

The feature can hold as many children shapes as you want. The first selected one will be used as Base for some boolean operation, such as Difference, the rest are Tools. There are lots of other settings you can tune to get better results, such as increasing arc points to get better arc fitting. Oh, libarea/Clipper only works with polygon/polylines, so all curve will be discretized before processing, and arc fit back. And this is the reason why Area is in Path Mod, instead of Part. The resulting shape is kind of deformed a bit. And it can get worse if you repeat is discretize and fit back many times. An option FitArc can be used to turn off arc fit, and only fit back at the last step.

[realthunder]

Path.Area is the python script object. It has all the functions of FeatureArea and more. All parameters in the property view can be set using setParams(key=value...). You can get each individual section shape with getShape(index). You can call add(shape,op) to add each individual child shape with different operation, which can't be done by FeatureArea. The shape returned from getShape() will be offseted and pocketed according to your settings, or you can directly call makeOffset and makePocket with different parameters without altering the internal cached shapes.

P.S. this may be of interest to the developers. Because of the need to expose tons of parameters in various places, I wrote a helper Macro library called ParamsHelper, located at src/Mod/Path/App/ParamsHelper.h, with detail documents. You can make WebDoc to see the document. Better turn on doxygen Show_Files option though, some of the document is only shown when Show_Files is enabled. The library lets you define groups of parameters once, and refer to and operate on in groups in everywhere, and by everywhere I mean class definition, constructor initialization, function declaration/definition/calling, properties, python bindings, and even doc string generation. It needs a bit of getting used to, because small typo in parameter definition or reference will give you some really cryptic compiler error message. But once you get the hang of it, you'll be addicted to adding new parameters whenever you want and expect it to automatically appear everywhere.

[mlampert]

Is this still a pull request?

I have the feeling this is a general discussion (and probably should be one) and belongs into the Path forum for folks to comment on. My 2 cents.

[chrisb]

Is this still a pull request?

I have the feeling this is a general discussion (and probably should be one) and belongs into the Path forum for folks to comment on. My 2 cents.

I would second a discussion although I am not yet sure what to think about it:
- Lots of interesting good stuff!
- is it usable for me with the limitation of not producing arcs;
- how does it integrate with the existing path stuff like job, tooltable, ...;
- do we have the same or similar features doubled;
- usage of colour model (rapid move in red, path in green); and probably much more.

You see more questions than statements and opinions, that's why I had hoped someone with more expertise would just decide things for me, but as you opened the discussion about the discussion: let's talk about it.

[sliptonic]

I agree with mlampert. This is massive PR. 32 files affected and almost 5,000 lines of code changed!

This is going to take us some time to understand and digest. Would a moderator please move/copy this thread to the Path/Cam forum?

@realthunder: The thing I'm most curious about is the Path.Area python scriptable object. You didn't include any python sample code for how to use it so I'm trying to infer its use from the limited documentation and tooltips. Do you have any sample code or can you better describe how it works?

[DeepSOIC]

I think it's a followup/complement/replacement to realthunder's previous pull-request:
https://forum.freecadweb.org/viewtopic.php?f=17&t=19617

[realthunder]

Is this still a pull request?
...
- is it usable for me with the limitation of not producing arcs;
- how does it integrate with the existing path stuff like job, tooltable, ...;
- do we have the same or similar features doubled;
- usage of colour model (rapid move in red, path in green); and probably much more.
You see more questions than statements and opinions, that's why I had hoped someone with more expertise would just decide things for me, but as you opened the discussion about the discussion: let's talk about it.

• It can produce arcs. It uses libarea after all. The arc fitting is not perfect of course. But you have much finer control than the origin area python module. I've exposed all of the arc fitting parameters.
• I am going through the current Path script code and see if I can write some demo code to produce gcode using Path.Area
• It seems that the feature set does have many overlaps, again, they originate from the same libarea. But right now, Path can't handle complex shapes. I am hoping my Path.Area can help with that.
• Rapid move currently is outside the scope of Path.Area. I need to read some more Path code to see if I can expose more helper function with that.

[sliptonic]

Since discussion of this is much more than just he pull request, I started a companion thread here: https://forum.freecadweb.org/viewtopic.php?f=15&t=20152