Path.Area: Welcome, to the new era!

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

realthunder wrote: You code works without modification with my latest PathArea branch. Please sync it. You may have some problem pulling, because I rebase the branch with upstream master and force update it. If you have any error, just checkout a fresh copy. I have submit the PR already, it should be in the master soon.

Great! I'll check it out.

By the way, in your code. If you are adding a face, there is really no need to use section. It's only for solid. You can do away with TechDraw, and simply use Area to makeSection at absolute position
Your method will work for my pawn but not as a general solution to the 2.5D contour I'm trying to achieve. In other shapes there is no absolute z height at which a section represents an outside profile. That's what the TechDraw function does - a projection onto the plane and then a determination of the outside wire by walking around it.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

I rebuilt with the latest and it correctly builds each step-down part of the path. However, the vertical moves are rapids (G0). After the cutter completes all cuts at a given Z-height, it should feed at the vertical feed rate to the next Z height and then continue. A rapid to the next level could crash the machine.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

sliptonic wrote:I rebuilt with the latest and it correctly builds each step-down part of the path. However, the vertical moves are rapids (G0). After the cutter completes all cuts at a given Z-height, it should feed at the vertical feed rate to the next Z height and then continue. A rapid to the next level could crash the machine.
This is actually a more general problem. Are there any common rules to check so Area can know when to use rapid move?

For now, here is what Area can do. You can play around with these parameters in Path.fromShapes,

* threshold, normally set this to your tool diameter. So, if the move is within this distance, no rapid. You can try higher value and see.
* retraction, retract absolute height
* clearance, pause height after return from retraction. It will then proceed with feed rate.

See doc string for more information

Code: Select all

print Path.fromShapes.__doc__
You can also use FeaturePathShape which exposes those parameters as properties, so that you can play around interactively.
Last edited by realthunder on Fri Mar 24, 2017 3:18 am, edited 2 times in total.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

sliptonic wrote:Your method will work for my pawn but not as a general solution to the 2.5D contour I'm trying to achieve. In other shapes there is no absolute z height at which a section represents an outside profile. That's what the TechDraw function does - a projection onto the plane and then a determination of the outside wire by walking around it.
Can you describe this a bit more? In what cases you'll need a outer shape like that? If this is a general need, I'll see if I can add this to Area. Maybe show some picture of your desired path?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

Sure. It's actually a pretty common scenario if the part requires work on multiple sides. Take a part like this and imagine that you want to cut it out of a larger block of material before machining the bottom. There's no Z level that represents an actual part profile.
Screenshot from 2017-03-23 23-09-01.png
Screenshot from 2017-03-23 23-09-01.png (152.36 KiB) Viewed 2102 times
What you want is just the outside profile like this:
Screenshot from 2017-03-23 23-09-15.png
Screenshot from 2017-03-23 23-09-15.png (161.53 KiB) Viewed 2102 times
This is kind of what I was referring to when I said the existing python code represents a lot of 'border cases'. I don't think the Path.Area tool needs to account for all of them, itself. It just needs to be very accessible from python so we can tweak the paths when necessary. The TechDraw.findPartOutline() function isn't perfect but it is immensely useful to us.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

sliptonic wrote:This is kind of what I was referring to when I said the existing python code represents a lot of 'border cases'. I don't think the Path.Area tool needs to account for all of them, itself. It just needs to be very accessible from python so we can tweak the paths when necessary. The TechDraw.findPartOutline() function isn't perfect but it is immensely useful to us.
I see. And yes, I can't seems to find a place in Area to add this.

What I meant by replacing the existing code with Path.Area is for those libarea python code. You know, those code to translate FC geometry to libarea geometry, and then back, which is what Path.Area originally designed for. I think Path.Area has exposed most of librea's functions now.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

realthunder wrote:
sliptonic wrote:I rebuilt with the latest and it correctly builds each step-down part of the path. However, the vertical moves are rapids (G0). After the cutter completes all cuts at a given Z-height, it should feed at the vertical feed rate to the next Z height and then continue. A rapid to the next level could crash the machine.
This is actually a more general problem. Are there any common rules to check so Area can know when to use rapid move?

For now, here is what Area can do. You can play around with these parameters in Path.fromShapes,

* threshold, normally set this to your tool diameter. So, if the move is within this distance, no rapid. You can try higher value and see.
* retraction, retract absolute height
* clearance, pause height after return from retraction. It will then proceed with feed rate.

See doc string for more information

Code: Select all

print Path.fromShapes.__doc__
You can also use FeaturePathShape which exposes those parameters as properties, so that you can play around interactively.
The other python operations have properties for 'safe height' - which is generally the MaxZ of the Part boundbox or the highest part of the part. They also have a property for the 'clearance height' which is the MinZ to clear all holding structures like clamps, vises, etc. So All vertical moves down below 'safe height' should be Feed moves. Vertical moves down from clearance to safe height can be rapid moves.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

Over the last couple days I've been trying to convert Contour and PathMillFace to use PathArea instead of the old Heeks python code. I've had some success and some challenges so I thought I'd post my observations so far.

Overall I'm really pleased with how things are working and it makes the code much cleaner, shorter, and more readable. Some early tests were giving me good paths for some shapes that have caused me trouble.

Here are the things that I'm still struggling with or confused about. Any help is appreciated:

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.

How do I set feed rate (F parameter) for vertical and horizontal feed moves?

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.

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.

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.

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?

getParams() returns a dictionary of parameters. It would be nice if setParams() could accept the same kind of dictionary as an argument.

I'm still confused about when/whether to use sortWires(). Could you provide an example of how this would be used?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

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.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

realthunder wrote:
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?
I can't think of any. I might come across more as I implement other things though.
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?
Yes. That will work but vFeed and hFeed need to be separate.
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.
This gives a good overview: http://www.cnccookbook.com/CCCNCMillFee ... tional.htm
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()
ok. Good to know.
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.
Yes. This might work with the climb/conventional or CW/CCW setting to change which direction is cut and which direction is rapid but you're right that it's a straight-line pattern
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.
Oh, awesome!
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.
[/quote]
ok.
Thanks realthunder.
Post Reply