Pocket operation cutting outside of area

Here's the place for discussion related to CAM/CNC and the development of the Path module.
hokieengr
Posts: 62
Joined: Sat Dec 31, 2016 5:09 pm

Pocket operation cutting outside of area

Postby hokieengr » Thu Jun 14, 2018 12:49 am

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
Screenshot_2018-06-13_20-45-11.png (83.81 KiB) Viewed 489 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 20 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
Posts: 1273
Joined: Fri Sep 16, 2016 9:28 pm

Re: Pocket operation cutting outside of area

Postby mlampert » Thu Jun 14, 2018 2:15 am

I have noticed something similar in a profile operation. The problem is PathArea.makeSections where it just shortcuts an arc. Maybe
realthunder wrote:
knows more about this.
realthunder
Posts: 1096
Joined: Tue Jan 03, 2017 10:55 am

Re: Pocket operation cutting outside of area

Postby realthunder » Thu Jun 14, 2018 3:13 am

hokieengr wrote:
Thu Jun 14, 2018 12:49 am
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?
Try Assembly3 (latest version 0.10.2) along 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
mlampert
Posts: 1273
Joined: Fri Sep 16, 2016 9:28 pm

Re: Pocket operation cutting outside of area

Postby mlampert » Thu Jun 14, 2018 4:17 am

realthunder wrote:
Thu Jun 14, 2018 3:13 am
hokieengr wrote:
Thu Jun 14, 2018 12:49 am
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
Posts: 1096
Joined: Tue Jan 03, 2017 10:55 am

Re: Pocket operation cutting outside of area

Postby realthunder » Thu Jun 14, 2018 4:32 am

mlampert wrote:
Thu Jun 14, 2018 4:17 am
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.
Image
Try Assembly3 (latest version 0.10.2) along 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
chrisb
Posts: 17440
Joined: Tue Mar 17, 2015 9:14 am

Re: Pocket operation cutting outside of area

Postby chrisb » Thu Jun 14, 2018 6:35 am

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
selfie.png (26.39 KiB) Viewed 459 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
noSelfie.png (21.22 KiB) Viewed 459 times
I attach the file anyway (before recompute) so you can have a look at Sketch006.
Attachments
good_pocket_operation_cb.fcstd
(133.06 KiB) Downloaded 13 times
hokieengr
Posts: 62
Joined: Sat Dec 31, 2016 5:09 pm

Re: Pocket operation cutting outside of area

Postby hokieengr » Thu Jun 14, 2018 12:10 pm

chrisb wrote:
Thu Jun 14, 2018 6:35 am
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)
chrisb wrote:
Thu Jun 14, 2018 6:35 am
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.
chrisb wrote:
Thu Jun 14, 2018 6:35 am
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
Posts: 17440
Joined: Tue Mar 17, 2015 9:14 am

Re: Pocket operation cutting outside of area

Postby chrisb » Thu Jun 14, 2018 1:24 pm

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
Posts: 1025
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Pocket operation cutting outside of area

Postby GeneFC » Thu Jun 14, 2018 2:27 pm

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
Posts: 62
Joined: Sat Dec 31, 2016 5:09 pm

Re: Pocket operation cutting outside of area

Postby hokieengr » Thu Jun 14, 2018 2:46 pm

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