Waterline milling update

Here's the place for discussion related to CAM/CNC and the development of the Path module.
mlampert
Posts: 1326
Joined: Fri Sep 16, 2016 9:28 pm

Re: Waterline milling update

Postby mlampert » Thu Jan 31, 2019 6:09 am

I just cloned the repo and compiled it under Debian buster. There is a tiny issue in one of the files (see https://github.com/mlampert/opencamlib/ ... ian-buster) otherwise it was a clean build on my dev vm. Now I use this vm to compile FC all the time which means that OCL doesn't have any "additional" dependencies ;)

I haven't run it through it's paces yet, I'm currently a bit short on extra time - hope it gets you going again ;)

EDIT: there seems to be an issue with cmake if one tries to compile the python bindings - my cmake kung fu is not very strong, might take a bit to figure this out.

EDIT 2: it works if you build one library at the time, which means you have to disable building the c++ library when building the python library. I ran some of the examples and they look good. The command I used (for an out of source tree build):

Code: Select all

cmake -DBUILD_PY_LIB=1 -DBUILD_CXX_LIB=0 ../opencamlib && make -j3 && sudo make install
herbk
Posts: 1534
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Waterline milling update

Postby herbk » Sat Feb 02, 2019 7:53 am

Hi all,
i would like to share some thoughts about waterline milling. You know that i'm not a programmer and so may be some of this thougs are just stupid... ;)

First: why you are going to use a mesh to getting a path? Is it more easy?

I have had some parts where i need a "waterline contouring" at the past, and i realized it with a workaround. For the workaround i need the "old Path" (of FC0.16), because there is no Job which creates a copy of the part where it takes the milling data. (That's also one thing i don't understand what it's good for...).
What im doing is simply cutting the object in slices and creating a "Path from Face" of each slice.

In my mind 3D Pocket dos exactly the same at each step down: Taking a slice to get the countour at this level. The only different to that what we want at Waterline Op is, it removes the material at the whole area of that level, - which looks like a facing operation to me.

For me the question comes up: Why not use 3D Pocket as base for Waterline and just replace the "Facing Op" by a "Countour Op"?
Gruß Herbert
chrisb
Posts: 18821
Joined: Tue Mar 17, 2015 9:14 am

Re: Waterline milling update

Postby chrisb » Sat Feb 02, 2019 9:22 am

This can be very well done in 0.18 as well:
- Use Part->Crossection to create the crosssections in an appropriate distance
- Part->SliceToCompound
- Switch to Path WB
- Create a job with the slice as base
- Create Profile paths, one for each slice, Cut side: outside, StartDepth=FinalDepth

The drawback is, of course, that you have to create a profile for each level. This could be the basis for a waterline algorithm as well.
Attachments
Bildschirmfoto 2019-02-02 um 10.18.06.png
Bildschirmfoto 2019-02-02 um 10.18.06.png (61.31 KiB) Viewed 746 times
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: 3d surface milling update

Postby JoshM » Sat Mar 09, 2019 5:00 am

Thanks to @JulianTodd, I've explored this a bit further. I have a hacked up script--attached--that has allowed me to play with mesh offsetting. It takes a minute or more to run the attached model. This is not optimized.

In short, a 2d Path-FeatureArea is attached to the stock top.
  • The wire is discretized by distance generating a list of Points
    The Job model is converted to a suitable resolution mesh
    The negative Normal facets are excluded for 3d
    For each Point, Mesh.nearestFacetOnRay(pt,vec) returns the intersect facet index and point with the job model
    Here, the model has been sampled, and the set can be further re-sampled to offset the Z of the path at each
To calculate the offset points, I've explored two strategies so far. only end mill initially. The model I've tested is complex enough to have overhangs cylinder, cone, and vertical and horizontal concave face intersections.

First, I re-sampled the data-set with a FIFO matching the tool diameter. The results were surprisingly good, though had errors because due the lack of sampling width. It was relatively fast, but the outer edges would be gouged by errors as seen here in some areas.
dropcutter_example_002.png
dropcutter_example_002.png (135.65 KiB) Viewed 627 times
Second, I re-sampled the data-set and calculated the xy distance from each point against all others, generating the set of z values under the tool tip. The max of the set is used for the Z height in the result--each XY point from the central point. This takes longer but provides significantly better results.
dropcutter_example_000.png
dropcutter_example_000.png (102.65 KiB) Viewed 630 times
dropcutter_example_001.png
dropcutter_example_001.png (133.69 KiB) Viewed 630 times
The most efficient re-sampling strategy determines the highest-z value for all z-value sample points within the tool radius. Perhaps a rastor approach might be better to limit the point set search.
Attachments
Dev005.FCStd
(69.73 KiB) Downloaded 22 times
aMeshSurfaceMilling.FCMACRO
(21.13 KiB) Downloaded 27 times
chrisb
Posts: 18821
Joined: Tue Mar 17, 2015 9:14 am

Re: Waterline milling update

Postby chrisb » Sat Mar 09, 2019 8:40 am

As we see regularly questions here concerning surface milling it will be great to have this in Path workbench.
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Sat Mar 09, 2019 10:57 pm

Hey Chris :D . I think I'm onto something worth exploring further here. I tried a 3rd strategy.

I made an offset mesh per endmill tool shape, and used the projection onto it. It quickly generates tool paths where the tool tip should be. I was momentarily perplexed because one side is imperfect at the bound of the model.

I realized that it's the fixed sampling step by specifying Distance for the discretize.
dropcutter_example_004.png
dropcutter_example_004.png (181.48 KiB) Viewed 574 times
dropcutter_example_003.png
dropcutter_example_003.png (207.86 KiB) Viewed 574 times
I'm going to run with this a bit. Instead of fixed sampling, I want to take the FacetIndex returned by the nearestFacetOnRay() call and factor that into the sampling algorithm so that portions with greater derivative get finer sampling.

If that is productive, then goal is to break the job up to provide more atomic control. Also, the 2D path-template will for each section can have separate path parameters (zig-zag, offset, etc...).
Attachments
aMeshSurfaceMilling.FCMACRO
(22.36 KiB) Downloaded 28 times
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Sun Mar 10, 2019 3:50 am

The difference in the two sides is because of mesh deformation in the offset mesh. Still looking at fix for that.

I tested against a toroid at an angle, and was pleasantly surprised.
dropcutter_example_005.png
dropcutter_example_005.png (123.71 KiB) Viewed 561 times
herbk
Posts: 1534
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Waterline milling update

Postby herbk » Sat Apr 27, 2019 7:20 am

Hi Josh,
JoshM wrote:
Sun Mar 10, 2019 3:50 am
...ping
i tryd your macro, if i ad a tool and delete the defoult tool i get this error and no output

Code: Select all

Traceback (most recent call last):
  File "/home/herbert/.FreeCAD/Macro/aMeshSurfaceMilling.FCMACRO", line 525, in <module>
    ToolController = Tool3d(SelectedToolController[0])
  File "/home/herbert/.FreeCAD/Macro/aMeshSurfaceMilling.FCMACRO", line 104, in __init__
    self.length_of_cut = (selected_tool_controller.Tool.CuttingEdgeHeight - self.tip_length)
<class 'TypeError'>: unsupported operand type(s) for -: 'float' and 'NoneType'
If i ad a tool and do NOT delete the defoult tool i get this error and a output

Code: Select all

Traceback (most recent call last):
  File "/home/herbert/.FreeCAD/Macro/aMeshSurfaceMilling.FCMACRO", line 555, in <module>
    QtGui.qApp.setStyleSheet(s)
<class 'AttributeError'>: 'NoneType' object has no attribute 'setStyleSheet'
But the wire don't fit to the outline of the shape.
wire.jpg
wire.jpg (61 KiB) Viewed 428 times
And: how can i get gcode from that wire?



Both happens at FC 0.18.1 from Opensuse Repo (which not contends a version number) and the AppImage (0.19.16502)
Gruß Herbert
RatonLaveur
Posts: 340
Joined: Wed Mar 27, 2019 10:45 am

Re: Waterline milling update

Postby RatonLaveur » Tue May 07, 2019 9:47 pm

Hello Herbk and all,

If it's still relevant to you, making G-code from the wire is easy using the Path From Shape tool. Which you'll usually find in the Path menu initially if you haven't set it up as an icon in your toolbar.

JoshM I'm just now dwelling on this topic, having thus far been distracted by Sliptonic, and Russ shooting features right left and center to play with.

I think your approach to waterline milling is extremely promising, and although I've had real interesting results using the openCAMLib drop-cutter approach to make my 3d laser milling paths, the limitations are that my path necessarily drapes around outside round shapes or more complex shapes. Making it difficult to machine single features (i.e. a recess for a single conical screw...a dimple for a latch...etc.)
Besides the drop-cutter limits us to a X or Y oriented machining layout. When sometimes I'd like to have it round/offset. That being said the OCL implemented in FreeCAD does have an interesting waterline system, but it does not "drape" on flat surfaces for example. At least not yet. That's where I found your approach interesting.
But to be fair to Sliptonic, I'm pretty sure it's also possible working with OCL.


At anyrate I'll be happy to try your approach. And should you wish to streamline it into a single surfacing tool, I'll be glad to help crash test it.

To all of you starting to think with meshes, all I can say as a cheap seat user is that whenever meshes have been retrofitted from PartDesign and involved in my recent forays in PathWB, my computer like it (much faster) and OCL loved it (much more accurate, fewer artifacts). But perhaps it's only due to the underlying FC structure of PartDesign models, maybe they are inherently extremely low quality mesh.

Thanks for an interesting read.
User avatar
Russ4262
Posts: 222
Joined: Sat Jun 30, 2018 3:22 pm

Re: Waterline milling update

Postby Russ4262 » Wed May 08, 2019 3:01 am

Evening,
I was reading up on recent posts and this one caught my attention.
RatonLaveur wrote:
Tue May 07, 2019 9:47 pm
Besides the drop-cutter limits us to a X or Y oriented machining layout. When sometimes I'd like to have it round/offset.
Yes, I am not finished with OCL Dropcutter yet. I have a lot in mind for that great tool. Adding additional "Cut Pattern" options is one of the features I was starting before jumping over to 4th-axis on Path Pocket Shape. I would like to make some of the cut patterns that already exist in some other tools available for OCL Dropcutter also. We are just not there yet. Face selection/boundary is another practical feature for the OCL Dropcutter op that many FC users would like to have and find useful. We just are not there yet. That being said, I think the visionaries and more influential developers in the PathWB, as well as everyday users, would rather the NEWLY COMMITTED PR #2114 - 4th-axis integration for PathPocketShape and 3D Surface ops receive some needed attention on the UI side for easier daily use by the general public.

RatonLaveur wrote:
Tue May 07, 2019 9:47 pm
That being said the OCL implemented in FreeCAD does have an interesting waterline system, but it does not "drape" on flat surfaces for example. At least not yet.
By "drape," are you referring to the example in the picture attached? If you are, this is another one of the great improvements included in the recently commited PR #2114 - A reworked and more practical OCL Waterline feature. Okay... that may be overselling a bit... But the updated version has stepdown (layering/mulit-pass) support and so far, test show no model violations and weird artifacts like the previous version. So, maybe take another look at the now updated OCL Waterline feature within the 3D Surface op in the PathWB. @Sliptonics investigation into better meshFromShape() parameters revealed a much better result from that function, which highly benefits the OCL based operations: OCL Dropcutter and OCL Waterline.

I really do appreciate all the feedback and great discussion and ideas you all offer!

Russell
Attachments
Dev005_1-Updated_Waterline.png
"Draped" - Updated OCL Waterline w/ stepdown
Dev005_1-Updated_Waterline.png (222.92 KiB) Viewed 320 times