I've refined an approach to this that seems largely workable. The algo is quite similar to prior approaches I've looked at, with some refinements.
In broad brushstrokes:
1. Bound the part of the face available to mill from top, and creating a 2d stock-top closed wire based on that shape.
2. This allows any toolpath pattern to be generated on the stock-top, and then projected down onto the surface.
3. The projected wires are then discretized and new wires offset according to tool geometry are generated.
4. Use Path FromShape to generate actual tool paths.
There are specifics to make this work dependent on how well existing FreeCAD functions perform. For example, in theory, the tool pattern wires could be truly projected onto the surfaces, but in practice, this doesn't perform reliably for all wire sections, so I have shifted to extruding the pattern through the Face. There again, in theory, Common, Slice, and Section should all work well to determine the 3d surface wires, but in practice, common is unreliable, and Slice and Section both work well.
Also, there are details in the settings of the FromShape that are critical to ensuring the results do not violate the model.
I have this working for external/convex Sphere/Cylinder/Cone/Plane shape and am about to implement Torus. Essentially any tool tip geometry can be used by offset is generated along normal or XY portion of normal...
At moment, it is much slower (30-40 seconds to handle several faces) than it can be. It is slow because I don't know how to calculate the BSpline myself and am now using the Draft.makeBSpline which draws each tool-wire sequentially. I need to ask Yorik how he does this--I've looked at his code but not fully understanding it yet.
There is much to do, but I think this is promising. Note that it does not yet account for collet/shank/tool-length violations or face/face violations. Much of that should be relatively straight-forward as much can be done on the stock-top 2d level. Also, output results are all G1 due to BSplines, but the someedge.Cuve.toBiArcs() could fix this at some point.
- (47.09 KiB) Downloaded 41 times