Sorry if I'm late.
sliptonic wrote: ↑
Thu Sep 27, 2018 7:17 pm
If the roughing op uses a dropcutter algo to determine intersection points, that collection of points may not be useful for a finishing op that uses the same tool and model but a waterline algo. Or maybe it is. I don't know. I'm just suggesting that it's a level of optimization that can wait.
Speaking of opencamlib, the dropcutter algorithm, is a mere "probing" of the 3D surface with the tool "model" if I remember well when I have mailed with Anders Wallin some time ago, it is a sort of collision detection using the model and the shape of the tool, and there is differences, between say a 3mm cylindrical tool and a ballnose tool and even with a bullnose tool.
For the roughing operation, many strategies could be use, obviously the final scope is to minimize time and preserve the surface for the subsequent finishing operation.
In some case like cutting wood or some granular materials if you go very rough in the roughing operation you have to take in account the amount of material that could be "damaged" by the roughing strategy, plywood or laminated wood as an examples could be damaged by some splines that are lifted by the roughing operation.
So maybe if a roughing strategy is to be implemented, maybe a sort of "allowance" parameter that enlarge the area of roughing could be inserted.
Some CAM program have a "Roughing Clearance" parameters and a sort of dual mode for the operations.
basically the operation have two mode "roughing and finishing" and some parameters are taken in account according to the mode.
When operating you create the finishing OP, then copy the finishing OP and set the trigger that state that this operation is a "roughing".
For the order of the operation that someone has cited in this discussion, a parameter that specifies the order of the operation at the GCode creation phase could be introduced, if there is no need of modifications the order of creation could be used if not if you have say 8 operation and want that the 8 is done before the 6 [1,2,3,4,5,6,7,8] could became [1,2,3,4,5,8,6,7] and obviously this care has to be taken by the user.
I will try the Path workbench in the near future, as I'm developing a workbench that convert a file written by a CAM program in FreeCAD entities, and I'm thinking of implement a manner to translate the MOPs (Machine OPerations as they are called in the other program) in FreeCAD Path.
my two cents, and sorry for the intrusion