Creating CNC roughing and finishing passes

[prius06]

Hmm, said I'd work on the optimization some weeks ago, but finding spare time turned out to be harder than expected, once again. But I finally managed to make a trial on optimization of the OCL DropCutter output in 3D Surface OP. Still some polishing to do but I'm well past my bed time, so thought I'd call it a day and publish the intermediate result:
https://github.com/pekkaroi/FreeCAD/com ... 81b202526c

Initial testing with some simple model and flat end mill, the optimization was quite effective: from 30k points to 85 points. And this optimization is totally lossless, the removed points are really redundant points in the middle of a straight line of cut. Of course now it is done by comparing equality of floating point values directly, which is never a good idea, right? So adding some tolerances to the comparison would make sense, but then some accuracy may be lost as well.. I'll think about that later. Good night.

Thanks!

[roivai]

I changed the optimization a bit - now it is based on general "is point on a line" check. I think it is ready for pull request. Only question for @mlampert or @sliptonic or others: Should I add a parameter to enable/disable the optimization? Is there a case where user would prefer a fixed pattern of points in G-Code output? I highly doubt it.

[sliptonic]

I can think of one use-case but I'm not sure it's worth considering:
If you're familiar with gcoderipper, it can adjust gcode to correspond to a probed surface (like engraving on the mouse). It does this by doing a bilinear interpolation of the gcode points based on the probe data. I've built something similar as an experiment using a Probe operation and a dressup to modify an existing path.

With your optimization, there are fewer gcode points to interpolate so a long G1 move will be adjusted at the start and end but ignore any curvature in the middle.

Like I said, I'm not sure this is worth including the exception in your code. A better approach would be to re-optimize the gcode in my dressup based on the needed sampling.

BTW, if you're interested in improving Surface a bit more, there's two ways that can be done relatively easily:
1) The SampleInterval and Stepover properties really should be exposed in the task panel. They're already available in the property pane but both are likely to be tweaked by even casual users.

2) Currently the tools in the tool library and copied to the tool controller don't have a shape property. We really need to add this. OCL supports three different shape tools Cylinder, Ball, and Bullnose. As things are, Surface is effectively hard-wired to always use a cylindrical endmill. If you're interested in working on this, let's talk.

[roivai]

I can think of one use-case but I'm not sure it's worth considering:
If you're familiar with gcoderipper, it can adjust gcode to correspond to a probed surface (like engraving on the mouse). It does this by doing a bilinear interpolation of the gcode points based on the probe data. I've built something similar as an experiment using a Probe operation and a dressup to modify an existing path.

With your optimization, there are fewer gcode points to interpolate so a long G1 move will be adjusted at the start and end but ignore any curvature in the middle.

Like I said, I'm not sure this is worth including the exception in your code. A better approach would be to re-optimize the gcode in my dressup based on the needed sampling.

I think that may be a valid point. I will add a parameter for this.

BTW, if you're interested in improving Surface a bit more, there's two ways that can be done relatively easily:
1) The SampleInterval and Stepover properties really should be exposed in the task panel. They're already available in the property pane but both are likely to be tweaked by even casual users.

That's good point. I will do that.

2) Currently the tools in the tool library and copied to the tool controller don't have a shape property. We really need to add this. OCL supports three different shape tools Cylinder, Ball, and Bullnose. As things are, Surface is effectively hard-wired to always use a cylindrical endmill. If you're interested in working on this, let's talk.

This was already implemented with DropCutter during my previous update. The decision is done based on the Tool.ToolType. Only BallEndMill and normal EndMill only though.I can add bullnose as well but I am not sure which ToolType in Path to use, there is no Bullnose?

[sliptonic]

This was already implemented with DropCutter during my previous update. The decision is done based on the Tool.ToolType. Only BallEndMill and normal EndMill only though.I can add bullnose as well but I am not sure which ToolType in Path to use, there is no Bullnose?

Doh! I really should re-base my development branch more often.

A bullnose or 'torus' is just an endmill with a corner radius. We could either add a new tool type or add a corner radius property to cylinder end mill and default it to zero. I think I'd prefer to add a new one.

[roivai]

1) The SampleInterval and Stepover properties really should be exposed in the task panel. They're already available in the property pane but both are likely to be tweaked by even casual users.

Here's how it looks now:

2018-09-25-205829_3840x1200_scrot.png (28.23 KiB) Viewed 486 times

I did not work on adding support for rounded endmills, but one thing crossed my mind and I think someone has requested a feature like this: As the operation area of the DropCutter is now selectable between Stock and BoundBox, why not add another option like "Custom".. This would then accept any feature that has a bounding box, like a sketch or face or whatever. Of course, even better would be that user could select any shape no matter how complex and the operation would be limited by its area, but it is a lot more complex task than using the rectangular bounding box of the shape. so this would be the first, low-hanging fruit.. I just have to figure out how to implement that feature chooser.. Any comments?

[prius06]

Here's how it looks now:...

You rock! Thank you!

[JoshM]

3D Surface has one big wrong starting point in my mind: It works allways with the whole object.
As written above, most areas of a part can be done verry well with existing OPs. It should be possible to reduce the working area of 3D Surface of the area where it's needet.

This has been my concern as well Herb. I've looked at this a lot, and have some initial coding done to generate face by face surfacing, but in doing so, I've realized that PathWB is currently constructed in a very 2d manner for 3d software.

Each Job does require parsing when generating paths for a single face to ensure no milling incursions into other Faces. There is a context.

Knowing what is allowed to be cut and deciding how much to cut at what feed rate with what tool are separate questions. This amounts to bounding the results to make them usable.

As stands, Jobs have Tools and Tool-Controllers associated with them. 3d surfacing operations require only the diameter and geometry of the tool, and care not at all about Feedrates and other variables within the Tool-Controller. Typically, multiple Tool-Controllers often exist within a single Job using the same Tool, allowing different Feed Rates. It makes no sense to Parse the model redundantly. For each Tool geometry, the Tool-Path perspective of the 3d Job Model is identical, so any OP should reference a common parsing.

Before calling OCL, you could separate the Job Model into sections by Faces. Here, I take the bounding of local face I create in algo, but then use it to create a separate Job and apply OCL.

SemiBoundedOCL.png (204.25 KiB) Viewed 435 times

As seen, this gets closer, but still is problematic as follows:
1. Only a finish pass, assumes roughing completed already.
2. Paths now only consider current face, and cut into other faces, where the Face Boundbox is used to bound the paths.

What is needed is further bounding, which I show below, in concept, by stealing another piece of geometry that I create in my algo.

BoundedOCL.png (224.16 KiB) Viewed 435 times

I cannot actually do an intersection with the Path Wires as they are not a Shape, but in abstract, this shows next step required...

In looking at this overall issue this last year or so, a couple of other things become clearer to me.

1. The 3d Stock Model is underutilized. The defaults Heights--a perpetual problem area--should not be a 2d/text input, but a 3d shape based on the stock used.

StockModel.png (249.27 KiB) Viewed 435 times

2. All "Roughing" begins on--or just below--the stock top, and Rapids travel is typically never allowed within the Stock Model.

RoughingStockModel.png (212.96 KiB) Viewed 435 times

3. Once a face is used for milling, no face below it can be milled without damaging the top face, so there is an "incursion zone" below it.

IncursionZone.png (220.45 KiB) Viewed 435 times

[JoshM]

3. An expanded zone can be considered around the incursion zone, an "Aversion Zone" which is too close for comfort and which can be used for warning of potential conflicts--say in Path Sanity.

AversionZone.png (230.88 KiB) Viewed 434 times

There are inherent conflicts when considering what is "required" to fully mill a Face without over milling other faces, and there is no single answer--thus dog bone dressups, etc... Thus, smarter surfacing requires more information.

In theory, once sections of the Stock are removed, local rapids could be increased in theory. I've seen this in other software, and it avoids using slow feed rates when returning into deeper sections of Pockets, etc...

Anyway, at the risk of hijacking your thread, these are some thoughts on the implications of this. BTW, scanning the current threads shows that this is at the nexus of a bunch of current limitations in PathWB. For example, milling to/over edges, falls out, amongst others...

Best,
Josh

[sliptonic]

3D Surface has one big wrong starting point in my mind: It works allways with the whole object.
As written above, most areas of a part can be done verry well with existing OPs. It should be possible to reduce the working area of 3D Surface of the area where it's needet.

This has been my concern as well Herb. I've looked at this a lot, and have some initial coding done to generate face by face surfacing, but in doing so, I've realized that PathWB is currently constructed in a very 2d manner for 3d software.

Just to clarify, The Surface OP currently works on the whole object but there's no reason it has to and I think that's what you're implying below. There's no limitation in OCL to do that. I'm glad to see additional work being done on Surface now and adding the ability to select a sub-area or calculate a local working area of a model is certainly possible.

The current operations in Path are definitely oriented to 2.5D work on 3D solids but the Path Workbench itself is not inherently 2D or even biased that way. As newer 3D oriented algorithms and operations are built, they should fit nicely into the PathWB framework.

Each Job does require parsing when generating paths for a single face to ensure no milling incursions into other Faces. There is a context.

Knowing what is allowed to be cut and deciding how much to cut at what feed rate with what tool are separate questions. This amounts to bounding the results to make them usable.

Not really. The job does not (and wasn't intended to) access the model geometry at all or parse it. The job simply sequences the operations and acts as a container for them. It doesn't (and wasn't intended to) have any overall control of material removal. I would resist putting any 'smarts' in the job level to check whether an operation is invalid because of something another operation did or did not remove.

Instead, the selection and sequencing of the operations should be left to the user for now. For instance, if a user selects a finishing operation, i don't expect the job to complain that no roughing operation has been done.

On the other hand, I would very much like to see REST machining become possible where the area to be worked on in operation B is the material left over from operation A.

It makes no sense to Parse the model redundantly. For each Tool geometry, the Tool-Path perspective of the 3d Job Model is identical, so any OP should reference a common parsing.

There might be some optimization possible here but it's not clear to me how you can parsing the model independent of the operation intent.
I don't think we're ready for that level of optimization yet.

Anything we can do that improves selection of material to remove and visualization of that material is great. But for now I think we should keep the operations atomic and trust the user to pick and sequence them appropriately in a job.