Subtle change in how depths are calcualted for operations

[mlampert]

Heads up.

PR-1004 will (once merged) introduce a subtle change in how operations calculate the depths (StartDepth and FInalDepth). Going forward the depths are calculated from the size of Stock, and not from Base anymore.

For most operations the only change is that StartDepth is now 1mm higher than it used to be (assuming you use the default Stock object which extends the Base object by 1mm in each direction). For Contour it also means that it will cut to the depth of the bottom of the Stock object - which means it will go 1mm deeper than the bottom of the Base object (again, assuming you go with the default Stock).

StartDepth and FinalDepth are automatically calculated to "safe" values based on the selected base geometries for the operation. There is now a "lock" checkbox in the depths page that allows you to manually set a value and make sure it doesn't get overwritten - even if you change the base geometries afterwards. Use at your own risk!

On a similar note, the default Pocket operation is now called "Pocket Shape", and works the way the old Pocket operation used to work. It removes material perpendicular to the selected (horizontal) faces - and nothing else. You can also select a loop of vertical faces to remove the enclosed volume (the Loop Selection command is your friend). This operation also allows you to override the calculated depths (see above).

However, the current Pocket operation is so cool and useful that we didn't want to lose it, so we moved it into a command group together with Surface. It got a new (rather crude) icon and is renamed to "3D Pocket" - otherwise no changes.

I'll add a note here once the change is merged.

[mlampert]

I almost forgot - the main reason for the change in depths calculation is because the new Pocket op supports the long asked for feature of "mill to model", or at least the first shot at it (as always there will be bugs and you guys will come up with a whole list of improvements ).

If you don't specify a BaseGeometry it will remove all material in X and Y direction between the bounds of Stock and the Contour of the model (it doesn't include the top face). However, due to how Path.Area works a Path is only generated where the removal material thickness is bigger than the Tool diameter. Keep that in mind if you try this out and there is no output.

[GeneFC]

This sounds great!

The only change I would make is to set the default stock to the exact bounding box. Why pick an arbitrary extension at all? It is unlikely to be suitable in most cases.

Gene

[mlampert]

This sounds great!

The only change I would make is to set the default stock to the exact bounding box. Why pick an arbitrary extension at all? It is unlikely to be suitable in most cases.

Gene

That is a very good point. The current default is what was the Stock default before - so that is where that comes from.

We figured everyone will have their own preference (pun intended) for what the default Stock would be - so we have included the definition of stock into the job template (there's now a dialog when you export a job template that lets you select what should be included). Adding a stock definition to the Preferences and use that if a job is created without a template is something I was supposed to do but forgot about - thanks for the reminder

[bill]

I almost forgot - the main reason for the change in depths calculation is because the new Pocket op supports the long asked for feature of "mill to model", or at least the first shot at it (as always there will be bugs and you guys will come up with a whole list of improvements ).

Grace H. called them bugs! Not me - never have! PATH has no bugs; just additional challenges!

Todays bug is tommorow's FEATURE and IMPROVEMENTS!

Thanks, MLMPRT

[mlampert]

I did some more testing with the new pocket op. I get correct paths for chrisb's infamous "U" even with OCE 6.8 (see below). I don't have access to OSX, so if someone could give it a try and see if it really works out that would be great. Also chrisb's radioForum model seems to work out correctly. I (think I) tried all the models we have linked to chrisb's U posted here in the forum and mantis and they all seem to work correctly. If you have some time please try the ones that didn't work for you previously once the change is merged. Thanks in advance!

Code: Select all

OS: Debian GNU/Linux testing (buster)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12188 +77 (Git)
Build type: Debug
Branch: feature/path-pocket-from-shapes
Hash: 4e1b5d15fdf9eabcf06e5741341930a48a9f50e1
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17
Locale: English/Canada (en_CA)

[chrisb]

Thank you very much, I will test and report back.

[dlhenke]

I did some more testing with the new pocket op. I get correct paths for chrisb's infamous "U" even with OCE 6.8 (see below). I don't have access to OSX, so if someone could give it a try and see if it really works out that would be great. Also chrisb's radioForum model seems to work out correctly. I (think I) tried all the models we have linked to chrisb's U posted here in the forum and mantis and they all seem to work correctly. If you have some time please try the ones that didn't work for you previously once the change is merged. Thanks in advance!

Hello Could you try to fix this bug ?
https://forum.freecadweb.org/viewtopic.php?f=15&t=24540

sliptonic told in the replies that is a known bug..

Thank you

[mlampert]

PR is merged, should show up in daily soon.