Waterline milling update

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
Russ4262
Posts: 224
Joined: Sat Jun 30, 2018 3:22 pm

Re: Waterline milling update

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

Thanks
JoshM wrote:@JoshM
for all your great work. Your knowledge and ability to clearly and technically express yourself with fantastic visuals always impresses me and inspires me to do more.

Thanks for being a part of this creative community and sharing your views and exploring new approaches to the challenges we are tackling.

Gracias!

Russ
RatonLaveur
Posts: 358
Joined: Wed Mar 27, 2019 10:45 am

Re: Waterline milling update

Postby RatonLaveur » Wed May 08, 2019 5:32 am

The waterline milling with step down is indeed a functionality that works very well.

What i meant is specifically shown in the example you kindly provided: the top surfaces are not exposed to the waterline and will therefore not be surfaced. If they had been slightly curved that would have been waterlined. And rightly so as I assume a perfectly horizontal flat surface wouldn't even be "detected" by the algorithm.

If i had to try and solve what I suggest today, i would create a sphere primitive of a diameter larger than the X/Y dimension of the part, and step by step drop the sphere through the part starting from the top. Each intersection outline would produce a waterline of sorts, and this way both lateral and flat surfaces would be surfaced.

This would of course not be ideal in terms of computation and I'm sure that Anders Wallin and other OCL contributors already have something like this under the hood, but this is in essence what the work of Josh inspires in me. Just a thought really before i go back to give some love to 4th axis :)

I wish a pleasant night to those on the other side of the pond and a good morning to the fellows in my timezone.
User avatar
sliptonic
Posts: 1579
Joined: Tue Oct 25, 2011 10:46 pm

Re: Waterline milling update

Postby sliptonic » Thu May 09, 2019 7:52 pm

RatonLaveur wrote:
Wed May 08, 2019 5:32 am

What i meant is specifically shown in the example you kindly provided: the top surfaces are not exposed to the waterline and will therefore not be surfaced. If they had been slightly curved that would have been waterlined. And rightly so as I assume a perfectly horizontal flat surface wouldn't even be "detected" by the algorithm.
The way a waterline algo works is by pushing the cutter in from the side until the collision is made, repeating around the part, and then connecting those points into the waterline. It's not that the top surface isn't exposed, it's that there's no collision to detect.

As implemented, this waterline is a surfacing operation. That is, it's set up for finishing, not roughing. For a roughing op, It would be possible to use the OCL waterline to detect the loops, then use something like PathArea or OpenVoronoi, or our own adaptive roughing, to clear the waste material inside or outside the loop as appropriate.
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Fri May 10, 2019 12:46 pm

Amazing stuff going on with Path these days, and in large part due to collaborations Russ has led. Bravo on getting things done.

My focus lately has been on facet sampling mesh in a non-linear way, and I struggled for a while trying to reconcile the vector math to get the algo correct. A couple of days ago, I finally figured out what I was doing wrong. I'm tidying it up and hope to get most of that done this weekend.

What I've been focusing on at the moment has been drop-cutter calculation, but I think it translates quite easily to waterline.
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Thu May 16, 2019 11:06 pm

Here's an example of what I've been working toward. Until now I've been printing out vectors and spot checking to try to get the basic algorithm working. I trapped most of the issues and now have drawn out the results for some tool path segments.

I implemented it poorly, and instead of adding all line segments to a Shape and then showing that, I iterated my edge-returns taking forever if I select many segments. Calculations for all tool path segments shown takes about 7-8 seconds. Showing the edge added 10 seconds, and is only an iterative step. Attached are two images--only difference that one is wire-frame, showing the Mesh edges explicityly.
MeshParsing000.png
MeshParsing000.png (110.51 KiB) Viewed 374 times
MeshParsing001.png
MeshParsing001.png (307.21 KiB) Viewed 374 times
The basic idea I've mentioned previously. determine intersection points of all facet edges with planes generated tangent to the tool path segments, and typically for many CNC vertical with the Z axis.

  • The red line-segments lie in the plane formed with tool path Edge14.
    Each resulted from the calculation of the intersection point geometric LINE and PLANE.
    Mesh.Facets were iterated, and the 3 Points used to form 3 line-segments, the Facet edges.
    Each Facet edge lies in a LINE. The LINE is either Parallel to, or Intersects with the PLANE at some point.
    If Parallel, the LINE is either in the PLANE, or disjointed.
    Exclusions cases must ignore all results where both points are beyond the tool tip radius, or above where above, below, beyond the tool path plus tool tip radius, etc...
    Facet edges that approach the PLANE within the tool tip radius along the PLANE normal vector but don't intersect are trimmed to where that offset distance is met.
    The tool tip radial offset is used with the tip type for squaremill, ballmill, or chamfer.
These are Interference line segments. Easier to see with a ZOOM in here:
MeshParsing002.png
MeshParsing002.png (265.23 KiB) Viewed 374 times
They are stored in a sorted list of tuples, along with their linear sort length from the Start Point of the tool path segment. Conceptually, the goal is to create a slot around each tool path line segment and account for any facet intersection with that slot. With all those points sorted, the result loses no detail in the Mesh. Lots of small lines where a PLANE crosses a fillet or spheroid. All Facets are sampled.

What I haven't done yet, is generate the "envelope" function to generate a wire that follows the upper-most line-segments, ignoring bottom. These don't represent lines that must all be milled--each line-segment represents a minimum allowable z-depth as the tool tip passes that portion of the plane. I also have to bound cases where only one point of the interference line lies within the tool radius to the PLANE. Among other things... But, I think it's promising.

While I'm focusing on this for zig-zag, z-axis milling, it's not entirely tied to that.
--With regard to tool path pattern, any linear pattern is efficient for parsing a mesh this way. It's also possible to invert this and treat each Facet as a PLANE, and find the bounds of intersection of that with tool path planes. I'm not sure if it makes a difference.
--With regard to z-axis, at the moment, I've tied it that way, but there's no additional burden to shifting the PLANE--defined by a Point and a normal vector--to any arbitrary "slice" angle--allowing calculation of arbitrary tool-angle/work-angle.
Attachments
Dev005.FCStd
(71.22 KiB) Downloaded 15 times
aMeshSurfaceMilling.FCMACRO
(34.5 KiB) Downloaded 14 times
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Fri May 17, 2019 12:28 am

As for Water-Lining, it's not significantly different. Here goes:

Above, I defined an X-axis/Y-axis tool path, and calculated for each facet edge if there was any interference with that pre-determined tool path. I then adjusted the minimum allowable z value for the bounds of each interference line.

To Water-Line:
1: section the Mesh with an XY PLANE, using same algorithm to determine interference/intersection of all Facet Edge line-segments, capturing all inflection points--all the available information in the mesh. Here, though, the result is the desired tool tip path, not an interference line-segment.
2: For each of these points, calculate the offset point on the PLANE, a radial-distance, calculated from the tool tip type, same as above.
3: Calculate Points using each Facet Normal and the radial-distance from step-2.
4: Create tool path line-segments from the two bound points from each Facet intersection or proximity to the side of the Facet along its positive normal.
5: What happens on external features is obvious--the tool path lines define a desired offset that the tool must be move, relative to each Facet.
6: For internal features, where there is inadequate space for the tool tip, I find it less intuitive. But, when all interference lines are considered, they will intersect and I believe it should fall out of that similarly. Maybe someone sees through this portion, where the tool path crosses itself.
7: Iterate the z-axis typically.
RatonLaveur
Posts: 358
Joined: Wed Mar 27, 2019 10:45 am

Re: Waterline milling update

Postby RatonLaveur » Wed Jun 05, 2019 7:52 pm

Josh,

I'd like to give a go to your approach for waterline milling. I've copied the macro you kindly provided, should I just try to use it as is?

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

Re: Waterline milling update

Postby JoshM » Wed Jun 05, 2019 8:58 pm

RatonLaveur wrote:
Wed Jun 05, 2019 7:52 pm
Josh,

I'd like to give a go to your approach for waterline milling. I've copied the macro you kindly provided, should I just try to use it as is?

Thanks, j.
Hi RatonLaveur,
You're most welcome to try to make progress, and I wish you every success. I've become very busy with work and don't have much time to play with it for a bit.

I believe that where I left off--which focused more on drop-cutter milling paths--I collect all facet interference points. I needed to sort them and stalled there. Conceptually, what is needed is to find the "upper/outer envelope" and keep only those points, ignoring those at lower z-levels.

In theory, any mill angle could be used--so for example, if you wanted true "water line" paths, then the toolpath plane is horizontal, and all facet intersection/interference points are calculated using the same vector math. Where in "drop cut" mode, the facet points/edges of concern are within a tool radius in the XY, and require the Z to be calculated, in "waterline" the Z is fixed, and the XY interference points require the tool to be moved along the XY-component of the normal to that facet-edge. And, the question then becomes, does that movement cause interference with other facets, which I suspect means enlarging the initial proximity calculation....



One thing that I did not initially understand--and I this is in the code I posted--is that for a mesh, there's "inside" and "outside". So, for "drop mill" style, if you have a plane in the zig-zag you are evaluating, I am looking for facet-edges that approach--and that cross the tool-path plane, and calculating a line projected onto the toolpath where the tool could potentially interfere.

There is good/bad to this I believe. On the one hand, for thick, solid objects, it is of no concern how deep you would have to cut through the part before that toolpath plane is not a concern. On the other hand, the LINE/PlANE intersection calculation is actually telling you if you are inside or outside as well--I think ;)

If there's any help I can provide, please just ask.

Best,
Josh
RatonLaveur
Posts: 358
Joined: Wed Mar 27, 2019 10:45 am

Re: Waterline milling update

Postby RatonLaveur » Wed Jun 05, 2019 10:03 pm

Oh I'm afraid i might have been misleading, with all the praise i lavish myself with otherwise, i am code illiterate. I just wanted to explore the behaviour.

Which I will still. Hope your being busy at work is a good sign of an engaging challenge!
User avatar
JoshM
Posts: 419
Joined: Thu Oct 05, 2017 5:34 pm
Location: New Hampshire

Re: Waterline milling update

Postby JoshM » Wed Jun 05, 2019 10:14 pm

At least Python is a relatively accessible language. Until I started playing with it, I had only programmed 8-bit microcontrollers in assembly language and a C-class 25+ years ago.

What was worse was for me was my math skills had been largely unused over that time frame too... While no expert, I feel much more comfortable with vectors again for the effort.