sliptonic wrote:The biggest limitation right now is that the Z vertical moves downward are still rapid moves(G0). Moves INTO the material must be feed moves (G1) to not crash the tool.
I'll add special handling of step down. Any other cases you have in mind?
sliptonic wrote:How do I set feed rate (F parameter) for vertical and horizontal feed moves?
That one is not directly related to Path.Area script object, but to Path.frameShapes. So will that be enough for me to add an F parameter for this? For other more complex need, I think you can directly access the returned Path object to modified the command, maybe?
sliptonic wrote:I don't understand how to control the direction of travel. This corresponds to climb vs. conventional milling and makes a big difference to tool wear and surface finish. But I don't see how to control whether the tool proceeds around a path in a clockwise or counterclockwise direction.
You've got to treat me like a CNC noob, which I am, and explain these concepts in pictures or something.
sliptonic wrote:PocketMode has several different styles. ZigZag and offset work about as I would expect. ZigZagOffset also seems to work correctly. Spiral, however, stops unexpectedly on many shapes after one or two passes.
I exposed libarea's Spiral pattern as it is. I notice the problem, too. It seems this pattern is not fully implemented in libarea. You can in fact achieve the same effect by using PocketMode Offset, and set tolerance to tool diameter when your call Path.fromShapes()
sliptonic wrote:To be fully compatible with the old heeks code, PocketMode should also have another pattern for ZigUnidirectional. This would follow the zigzag pattern but rapid back to safe height and then back to the other end so all feed moves are in the same direction.
Yes, I intend to add that pattern. Am I correct to say that this is essentially a straight line pattern to Path.Area? By default, Path.fromShape will reorder the path direction to reduce rapid move. You'll have to turn off sorting for that.
sliptonic wrote:There are four properties that are related: toolradius, pocketstepover, stepover pocketextraoffset. I think I understand what each is supposed to do but it's not entirely clear how the work together. MIght just need more documentation here. Can pocketstepover and stepover be combined?
toolradius and pocketstepover may not be the same. I speak from my PCB milling experience. You often need some overlap in extra passes to get a clean isolation, so pocketstepover < toolradius. 'StepOver' is for use by Offset (i.e. contour) operation, not Pocket operation (not to be confused by PocketMode Offset, which uses pocketstepover). They are separated, because the two operations may be separated. 'PocketExtraOffset' is to do an inward/outward offset before doing the pocket. It lets you shrink or expand the pocket covering area. For example, in PCB milling, you normally do one or more pass of isolation (contour), then optional choose to pocket out certain unwanted copper. So shrink first (because of the contour) then pocket to save some time.
sliptonic wrote:getParams() returns a dictionary of parameters. It would be nice if setParams() could accept the same kind of dictionary as an argument.
You can, like this, setParams(**params), where params is a dictionary. This is a python language feature.
sliptonic wrote:I'm still confused about when/whether to use sortWires(). Could you provide an example of how this would be used?
Path.fromShape internally calls sortWires by default. To turn off that, you can pass sort_mode=0. Wire sorting is essential for PCB milling, which has lots of complex isolated multiple contours. Without sorting, your tool will be all over the place. For other type of CNC, I guess the usefulness is limited. You can try to turn on and off the sorting (for PathFeature, you can change the SortMode property), and see the effect. I offer Path.sortWires separately for extra flexibility. In most case, just let Path.fromShapes do the sorting.