Path.Area: Welcome, to the new era!

[bill]

I dont know what you are trying to do; pocket that hex rim with zigzag?

Can a TOOL zigzag in its own WIDTH?

Maybe you need to zigzag the face feature of the widened wire? like this? Hope this can help!

feature_feature.png (14.82 KiB) Viewed 2004 times

pocketsim_sim.fcstd

(76.78 KiB) Downloaded 35 times

[realthunder]

Does the 'thicken' property work with pocket mode? I'm playing more with collision detection and can't seem to get it to work

Fixed in my branch. Please test.

I dont know what you are trying to do; pocket that hex rim with zigzag?

He is trying to thicken the pocketing path to see if the tool bumps into something. It can also be used to visualize pocket area coverage.

Screenshot from 2017-06-21 11-49-23.png (19.86 KiB) Viewed 1998 times

[sliptonic]

Fixed in my branch. Please test.

Damn, you're fast!

I didn't have time to reply to Bill and you got the reply AND the fix!

[realthunder]

Damn, you're fast!

I didn't have time to reply to Bill and you got the reply AND the fix!

Well, it's a small fix after all. So, are you testing fine? If so, I'll submit the PR.

[sliptonic]

Well, it's a small fix after all. So, are you testing fine? If so, I'll submit the PR.

Let me do a bit more work this morning and I'll post again.

[sliptonic]

Two things I'm still struggling with and only one might be a PathArea issue.
I've got sectioncount=-1 and Stepdown=1 but when I do simobj = pocket.getShape(), I only get back the bottom section, not the others as shown in your image.

The other issue, I don't think is PathArea but I'm not sure. in the attached file, I have the thickened path (sim) and the original pocket. They should be colliding. But if I check for the volume of the common, I get 0.0

Code: Select all

orig = FreeCAD.ActiveDocument.Pocket.Shape
sim = FreeCAD.ActiveDocument.simshape.Shape
intersection = orig.common(sim)
print sim.Volume
print orig.Volume
print intersection.Volume

>>>19831.0408755
>>>349991.353417
>>>0.0

[realthunder]

I've got sectioncount=-1 and Stepdown=1 but when I do simobj = pocket.getShape(), I only get back the bottom section, not the others as shown in your image.

This is probably because you've set the bottom face as work plane, and use the default SectionMode, which means relative to work plane. A positive stepdown means starting from the work plane downwards, so you only get one section. If you don't set the plane, the default work plane is the top XY0 parallel face, and you'll get the expected result. Or, if you still want the bottom face as work plane, try either change step down to -1, or use different SectionMode.

The other issue, I don't think is PathArea but I'm not sure. in the attached file, I have the thickened path (sim) and the original pocket. They should be colliding. But if I check for the volume of the common, I get 0.0

If you Part.show(intersection), you'll see an error message. Looks like common operation failed. What do you want to achieve here? I fail to see why common operation is used for collision detection. If common were to succeed, you should be getting the same shape as sim, right? I don't think OCC is suitable for doing such operation that may be too close to tolerance. You can try using Area, but may still have problem, because it still requires OCC to convert back the result to Face.

Code: Select all

import Path
orig = FreeCAD.ActiveDocument.Pocket.Shape
sim = FreeCAD.ActiveDocument.simshape.Shape
area = Path.Area().setPlane(orig.Face13).add([orig,sim],op=2)
Part.show(area.getShape())

op=2 means Intersection (i.e. common). You can try other operations if you want. The key is to set the correct workplane.

[bill]

What/How tolerance are you checking (at):

Have not looked at this for a long time; but do seem to remember needing to adjust tolerance to object size!

... if Cvol.Volume > 1e-12 :
errorDialog(
'WARNING: COLLISION/INTERFERENCE Detected Between Objects ! \n\n {} and {}\n\n INTERFERENCE Volume is approximately {} cubed/units!\n'.format(
OBJ1,OBJ2,Cvol.Volume))
else:
errorDialog(
'NO COLLISION/INTERFERENCE Detected Between Objects ! \n\n {}\n and\n {}\n\n'.format(OBJ1,OBJ2))...

You WILL encounter False Negatives depending on tolerance selection!

[sliptonic]

This is probably because you've set the bottom face as work plane, and use the default SectionMode, which means relative to work plane. A positive stepdown means starting from the work plane downwards, so you only get one section. If you don't set the plane, the default work plane is the top XY0 parallel face, and you'll get the expected result. Or, if you still want the bottom face as work plane, try either change step down to -1, or use different SectionMode.

Yes, that did it. Thanks.

What do you want to achieve here? I fail to see why common operation is used for collision detection. If common were to succeed, you should be getting the same shape as sim, right? I don't think OCC is suitable for doing such operation that may be too close to tolerance. You can try using Area, but may still have problem, because it still requires OCC to convert back the result to Face.

I might be trying to be too clever here or using OCC inappropriately. If there's an easier/better way to detect collision, I'm all for it. My goal wasn't to push this close with tight tolerance but just to find gross overlaps where user settings in the path operation would result in a gouged model.

In this specific example, the common and the sim are the same and that would be fine. A volume> 0 would correctly indicate a collision.

A more accurate representation of the sim would include all the sections like below. Collision detection is one advantage, but the real reason for calculating objects like this is to find areas NOT removed by the operation so they can be refined with another operation/tool. This is called 'rest machining' Then may, just maybe, I can finally kill the spider.

snapshot-2-1.png (51.5 KiB) Viewed 1871 times

[realthunder]

A more accurate representation of the sim would include all the sections like below. Collision detection is one advantage, but the real reason for calculating objects like this is to find areas NOT removed by the operation so they can be refined with another operation/tool.

Yeah, I that's my guess, too. So, you should actually use 'difference' operation instead,

Code: Select all

import Path
orig = FreeCAD.ActiveDocument.Pocket.Shape
sim = FreeCAD.ActiveDocument.simshape.Shape
area = Path.Area().setPlane(orig.Face13).add([orig,sim],op=1)
Part.show(area.getShape())

op=1 means 'difference' (i.e. Cut). You can adjust the code to produce sections of 'difference'.

Screenshot from 2017-06-23 00-51-20.png (10.37 KiB) Viewed 1860 times

You can then do another pocketing to this with a finer tool.