Waterline milling update

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Wed Jan 02, 2019 12:23 am

Hi Julian,
I'm glad for your perspective, and have hoped to chat with you since you started posting. I take your point on mesh superiority, and I don't have an interest in working at an inferior approach. But, after about a year of playing with the concepts, I have found the effort engaging and have enjoyed learning some Python. I also have found it useful in simply using FreeCAD successfully for modeling--give a better sense of why certain operations fail, others succeed, etc...

For context, my background is electronic engineering, and the bulk of my programming has been assembly language 8051, with some C for 32b Pic micro controllers. As you've seen my attempts at coding in Python, likely not a surprise :lol: If nothing else, the experience has bettered my understanding of some concepts like classes...

I upgraded from a slightly older v18 and see your fix on line 626 is required. I think there has been work afoot to add multiple objects to Jobs.

I mocked that up as a modification of earlier work, over the last couple of days. I know exactly what you mean about Job-model incursion, and had set that aside in short term. I also haven't dealt with concave surfaces--which provide the opportunity for incursion due to self intersection, among other issues...

Also, as you mention, while it works as a conceptual demonstration, not all parts and pieces work well as is. For example--currently, I am selecting Job and Tool Controller, and running all Faces. This really makes no sense. If I were to go further with it, I would target only selected Faces to generate Paths, but parse all Faces for tool-incursion. I prefer the more atomic approach existing in FreeCAD PathWB, and that would be more consistent philosophically--it would also cut processing time.

BTW, if you are not aware, the same stock-top 2d path patterns, if imposed on top of a solid that bounds the space between surface cuts and stocktop, will generate tool paths that step down (2.5d milling) which seems appropriate for roughing...

I'm curious as you mention limits of Model-incursion avoidance algos. I have not implemented this yet, but since every shape is projected onto the Stock-Top, then in theory, all of the closed-2d edges bounding the individual Face tool patterns provide a way to sort out incursions and over-shadowing. In the Cone example I posted, the overshadowed plane-object Face should never be targeted as it is overshadowed. It's stocktop-edge is inside the Cone's stocktop-edge. For partially shadowed cases, the shadowed portion would interfere...

I also like the idea of allowing direct model inputs to better define the Job in a 3d manner. For PCB work, the essentially-2d tool I use provides layers, including "Keep Out" layers for components and also for copper. It also provides Design-Rules checking for copper clearance, component clearance, etc... It seems like we could do similar in FC-PathWB to allow 3d model of Fixtures to provide "Keep Away" zones. Similarly Face-Face incursion could be more directly avoided by users by having "included" faces selected in the Job.Op, as well as "avoid" faces selected for the Op. This allows more explicit Op definition and more likely success by software.

More reasonably, if this were completed, my take is that the issue is more easily avoided by allowing User to select/deselect included Faces... Still, under that approach, the Sanity check would benefit from ability to catch incursions....

As stands, FC-PathWB requires more of the user, and that may turn off some, and may differ from commercial software, but I think it has tremendous upside in that it allows the user to learn more granularly. My boss and I were both overwhelmed by the 3d milling software we tried out a couple of years ago because it wasn't clear how to do simple stuff. He wanted to mill pockets in an existing panel, it wanted to process the whole panel. I'm sure it all worked, but in the limited trial, it was overwhelming to us.

I also don't think the typical FC user is necessarily the same demographic as commercial software user. At my work we use FC to make molds and run other small jobs on desktop CNC--enclosure panels, etc... We also use FC for 3d printer models. None of us are experts in machining areas, but we all appreciate the functionality provided. The "bar for entry" is relatively low, allowing hobbyists (or paid hobbyists like me :lol: ) to do stuff. With the DIY/Desktop boom, I see think there will be a lot of users who don't have significant expertise. Just my perspective--which is that providing these tools freely to people with less expertise allows them to try out their ideas at a reasonable price point. I read something that surprised me sometime last year saying that the CNC machine was something that the North Korea government invested in heavily in nuclear ambitions--I like to think of PathWB providing similar power to more peaceful endeavors in garages and small shops everywhere :D

If there is anything I can do to work with you or be of any service in your efforts to realize a true 3d milling solution in PathWB, I would be thrilled.

Cheers,
Josh
routalot
Posts: 14
Joined: Sun Sep 23, 2018 11:40 am

Re: Waterline milling update

Postby routalot » Wed Jan 02, 2019 1:31 pm

This looks like a wonderful avenue of development.I look forward eagerly to the day when we are able to machine compound curved surfaces,as opposed to those generated from equations.I have fumbled through machining wooden models by projecting a series of horizontal lines through a body and then machining a series of profiles and this gives a useful starting point for a spell of sanding out steps,to be able to achieve a good surface direct from the machine would be great.I shall be watching with great interest.
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Wed Jan 02, 2019 8:40 pm

I hear you--I've done similar for Delrin jobs. Not sure in wood if applicable, but ballnose makes less sanding.

The curious thing that I've found is that there's a lot of beauty in geometry. Common available tool types--Square Endmill, Ball Endmill, Rounded Edge, Corner Round Mill, Tapered, Chamfer--require a combination of radial and vertical offsets.

For example, referenced to tool-tip/center:
1. Square Endmill is offset radially, by the Flat-Radius, along the XY component of the normalAt(U,V) for the UV value of the point on the finish mill surface.
2. Ball Endmill is offset by the Corner-Radius, along the normalAt(U,V) for the UV value of the point on the finish mill surface, then then down the Z-axis by the Corner-Radius
3. Rounded Edge Mill is a combination of the two--adding the Square and Ball Mill vectors.
4. Chamfer while not practically applicable to all surfaces, does have a beautiful geometric relationship: it can engage a hemisphere from top center down to a maximum point, where the shank would engage--with exception of Drill/Mills, which could continue cutting from the side. The angle from the sphere center to the maximal point equals the Chamfer angle. The same holds for cylinders. For planes, it makes no sense other than engaging the Chamfer angle, though in theory any face angle less than the Chamfer angle is possible.
5. https://images1.mcmaster.com/mvA/conten ... 1471621323
Corner-Radius--practically is single use, filleting, and like the Square Mill, it's along the XY component of the normalAt(U,V) for the UV value of the point on the finish mill surface, but here the Flat-Radius is smaller than the Cutting radius.
6. Taper like Chamfer, can engage a plane up to it's Taper angle. Practically, it's most meaningful for engaging at it's Taper angle.

I wasn't aware of these relationships a year ago, but have figured them out--often using Sketcher and Constraints to help see through the relationships.

I do have to laugh at myself, and the effort I'll go through to work around the limits of my smarts. I am comfortable using vectors and cross and Dot functions, but I still can't wrap my head around how to calculate the an object's Rotation vector to align it with another object. The other day I realized I didn't know how to align a circle to the inside of a toroid at any angle in 3d space. I got around it by placing a vertex at the toroid major radius along the surface axis cross(+Z Vec) and revolving it around the surface axis. :lol:
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Fri Jan 04, 2019 1:03 am

I've cleaned this up quite a bit, and it's much easier to try out now. I figured out how to make the BSpline shape without drawing to screen. It really didn't change time much. I have been generous with recomputes.
Attachments
Top3dMilling.FCMACRO
(52.53 KiB) Downloaded 30 times
User avatar
Kunda1
Posts: 5201
Joined: Thu Jan 05, 2017 9:03 pm

Re: Waterline milling update

Postby Kunda1 » Fri Jan 25, 2019 12:40 pm

JoshM wrote:
Fri Jan 04, 2019 1:03 am
Any success ?
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Fri Jan 25, 2019 2:15 pm

Hi Kunda1,
I've been following JulianTodd's posts, as he has mentioned he's successfully achieved 3d milling for commercial software in the past.

I've been playing with mesh a bit since he mentioned it's a superior approach, and I've reached out to him by PM to see if there's any way I can be of help, and to try to get a sense if he's looked at the MeshDesign WB capabilities already built into FreeCAD, but I havn't heard back yet.

Mesh is new to me, and interesting. The FreeCAD MeshWB documentation seems non-existent. But, my sense is that he is on the money about the the benefits of mesh.

I've attached the script I've been playing with that simply makes a mesh from the Job Face(s), and then moves the points to offset for the tool tip shape. It then makes a copy of the mesh with the Facets that have a negative Normal.z removed. It's not elegant--I didn't split the Facets along the plane.


Best,
Josh
Attachments
aMeshSurfaceMilling.FCMACRO
(17.06 KiB) Downloaded 14 times
User avatar
sliptonic
Posts: 1559
Joined: Tue Oct 25, 2011 10:46 pm

Re: Waterline milling update

Postby sliptonic » Fri Jan 25, 2019 2:41 pm

JoshM wrote:
Fri Jan 25, 2019 2:15 pm
I've attached the script I've been playing with that simply makes a mesh from the Job Face(s), and then moves the points to offset for the tool tip shape. It then makes a copy of the mesh with the Facets that have a negative Normal.z removed. It's not elegant--I didn't split the Facets along the plane.
I still think we could get some short-term benefit by doing more with OpenCamLib. Using the the tessellated shape of the part and pushing a tool shape against it is exactly the approach employed. http://www.anderswallin.net/CAM/
JulianTodd
Posts: 51
Joined: Tue Oct 23, 2018 3:35 pm

Re: Waterline milling update

Postby JulianTodd » Sat Jan 26, 2019 12:34 am

I've got to get back to working on this. I have code I was working on 5 years ago (see pictures). I looked at it again, but have not been able to see how to make it useful here. The path work bench is already too complicated for what it does. I should just focus on making some slices for a given tool, and find a way to get the geometry back into FC like I did with the SVGnest hack. Then we'll have something to argue over and hopefully find an integration that can be made useful.

There are quite a few technical choices that need to be discussed, in terms of python libraries and speed ups (eg using cython, pypy or pyOpenCL) and I don't know what the policy is on dependencies like these. I'm not going to do anything in C++. It's not fun, and I think it's a dead language. The future has got to be on the GPU for this sort of thing -- the computation of all the toolpaths for a 36 hour machining job doesn't come to that deployed on 2 seconds of video game play these days. I mean, if you line up each 24 bit pixel against one micron of toolpath, which is basically nothing, that's at least 30 metres a second spooling out.

I don't see getting from your average confused C++ algorithm into something done massively parallel on a GPU, whereas I think it's possible to jump from Python to that place, because you're not going to have so many mixed up data structures swimming around.

Does anyone around here know how to code for GPUs? I'd like to think I could get the algorithms into a state where they can be transferred to them.

As you can see in the picture, the main tool is this 2D mesh subdivision modelling the area where the tool is intersecting with the surface. This is the basis of many of the machining algorithms.

In my first implementation 1992-2002 there was a basic square subdivision, and then each cell could have a mini-grid which criss-crossed the whole cell. In my second implementation 2003-2012 the subdividing lines still had to be parallel to X or Y, but they didn't need to go the full with of each cell, and could form T-junctions.

In this implementation, the subdividing lines can go in arbitrary directions to model the area.

I can't tell if this is better in the long run, as such topology can have ordering issues (you know which order two points on the X axis are no matter how close they are together, but two close points on a non-perpendicular line can disagree in their coordinates). However, if can model shapes more efficiently, and this might make a difference.

Please pester me, or email me, or send me shapes you would cut if I got this done, to get me back to working on it, or I'll keep frittering away my time on experiments with GPS with RTK, which I only learnt about last week, and the tools have been open source for years.
Attachments
closeslicesubdiv.png
closeslicesubdiv.png (64.28 KiB) Viewed 515 times
impslices7.png
impslices7.png (104.95 KiB) Viewed 515 times
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Thu Jan 31, 2019 12:23 am

Hi Julian,
Thank you so much for your response. I've been processing what you posted. I don't fully understand some, so wanted to respond:
The path work bench is already too complicated for what it does.
From an open-source standpoint, you don't need consensus, just implementation :D . You can take what parts work for your needs, if any, and build a new workbench from the modules behind anything. I get there are pros and cons, but in an active forum the WB is ratcheted into correctness. For example--your contributions with helical and nesting.
Does anyone around here know how to code for GPUs?
No idea. But, implementation aside, I believe it's largely important to focus on bite size chunks and keep things granular.

Still learning about Mesh module's built in capabilities. Documentation is limited. Plus I have no prior experience with mesh concepts. So I haven't figured out why when I trim with a polygon plane, I get what I want, but offset
trim_000.png
trim_000.png (29.49 KiB) Viewed 407 times
?

In pic#1 you posted--2d--is the grid (and micro grid) a meshing algorithm you developed, to produce the waterline tool paths, or are you deriving the toolpath from a mesh model of the job?

Is it even worth splitting facets, or is the point to tessellate with adequate fineness and call it good when the specified deviation limit is met? The benefit is then all Facets are created equal. Offsetting using the Facet.Normal and the tool tip geometry. Am I on the right track concept wise?

Josh
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Thu Jan 31, 2019 12:28 am

I still think we could get some short-term benefit by doing more with OpenCamLib. Using the the tessellated shape of the part and pushing a tool shape against it is exactly the approach employed.
Hey Brad,
It's always been an option. I couldn't get it to compile--or figure out how to drive it. I'm no help there.
-j