Pocket operation cutting outside of area

[hokieengr]

I created a (arguably complicated) part for the kiddos. To start, I selected all the faces that make up the tracks and selected Pocket at once. The result is interesting:

Screenshot_2018-06-13_20-45-11.png (83.81 KiB) Viewed 2121 times

Some parts of the track look really good, others cut through areas that are not included in the pocket area.

The file is attached here:

bad_pocket_operation.fcstd

(164.01 KiB) Downloaded 58 times

General info:

OS: Ubuntu 18.04 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.13905 (Git)
Build type: Debug
Branch: master
Hash: e80b5678ccfa59a5222b91bdc7e748a53a468468
Python version: 2.7.15rc1
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 6.9.1.oce-0.18
Locale: English/UnitedStates (en_US)

[mlampert]

I have noticed something similar in a profile operation. The problem is PathArea.makeSections where it just shortcuts an arc. Maybe

knows more about this.

[realthunder]

Some parts of the track look really good, others cut through areas that are not included in the pocket area.

After I opened your files, and mark Pocket_Shape operation for recompute, and then recompute, the path is fixed. I notice that you are using OCE, can you please try compile with OCCT 7?

[mlampert]

Some parts of the track look really good, others cut through areas that are not included in the pocket area.

After I opened your files, and mark Pocket_Shape operation for recompute, and then recompute, the path is fixed. I notice that you are using OCE, can you please try compile with OCCT 7?

I did that with OCC 7.3 and the problem persits:

Code: Select all

OS: Debian GNU/Linux testing (buster)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.13964 +7 (Git)
Build type: Debug
Branch: feature/chamfer
Hash: ae078f2be5863dc77e041aa066a130e99650a75a
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/Canada (en_CA)

[realthunder]

I did that with OCC 7.3 and the problem persits:

I am using the lastest upstream master, but with OCCT 7.1.

OS: Ubuntu 16.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.13964 (Git)
Build type: Debug
Branch: master
Hash: 548511ac30cd07328db60169f854d08975adf047
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/Singapore (en_SG)


Please see the following screencast. I see some warning and error opening the file. Once I recompute it, the path is corrected. Please set the log level as 5 like in the screencast. This will cause Path.Area to output intermediate shapes. Please recompute and save it, and post the file here. Also, please save the log in the report view and post it, too. I'll take a look.

[chrisb]

Did you set the tolerances in Path Preferences to small values? I have them set to 1 micrometer.

If I recompute your model it collapses. It is a very fragile and complicated model. You use the (complicated) sweeps where you can use (simple) pads and pockets. That may result in problems with the graphic kernel. I would recommend to use a master sketch and reference only this.

Since I started with looking at Sketch006, some remarks on on this: It has self intersections, which you should remove:

selfie.png (26.39 KiB) Viewed 2091 times

Furthermore you should avoid measures as far as possible, use equality instead. I simplified the sketch by deleting the unused external geometry. Finally you can refine the shape. Simplifying and refining probably has no effect on the Path generation, the self intersection can have.

noSelfie.png (21.22 KiB) Viewed 2091 times

I attach the file anyway (before recompute) so you can have a look at Sketch006.

[hokieengr]

Did you set the tolerances in Path Preferences to small values?

The tolerances are still set to their default value of 0.0004" (about 1 micron)

If I recompute your model it collapses. It is a very fragile and complicated model.

Aside from the Pocket (and apparently Profile as well, something about that curve it does not like) I didn't have any issues with the model. Recomputing causes no issues here and Check Geometry also passes. From a user standpoint, I don't see anything wrong with the geometry.

You use the (complicated) sweeps where you can use (simple) pads and pockets.

This is true, however, it is not wrong to do so. Obviously there are many ways to create the same part. To me, the simplest way was simply to define the track profile and sweep it along the two desired paths. That let me easily modify the curve trajectory by modifying one simple sketch and the exact geometry of the curvature was subject to refinement.

Just to be clear, I'm not saying the easiest way to do it is my way. I'm just pointing out that it was the easiest for me. Surely you'd prefer to use simple pads and pockets and that is totally up to you. My point is that the tools we are developing should produce identical results even if people have different styles.

[chrisb]

Of course it should work, but as we have seen: it doesn't. So I pointed out a different way using operations as simple as possible. I will create a model tonight and it would be kind if you can try it.

[GeneFC]

I agree with chrisb. The error in sketch006 is causing the problem. If you recompute the entire document the error shows up in pad001.

A full recompute should never cause errors to appear. Removing the extra line in sketch006 automatically allows the path generation to proceed correctly.

A sketch should never have three or more lines joining at a vertex.

Even after this fix, there is still some strange path behavior at the crossing frog. I do not know why.

Gene

[hokieengr]

I didn't mean to offend you. I realize that I might have miscommuncated my intent!

My goal in posting this is not so much to find a way to cut this model (kids need to learn to wait for things!) but rather to identify and fix the issue with path generation. To that end I was making the point that the model is what it is and how can we fix the Path issue. If I made that point poorly then I apologize!

That being said, if trying different models in an attempt to narrow down the Path problem is your goal then by all means let me know. I just don't want you to waste your time fixing my crappy model!

Bob