Path Operations refactor branch.

[mlampert]

[Edited] It seems that I have again that problem, when I pull from git, but somehow old version remains.

The PR hasn't been merged yet.

[Konstantin]

[Edited] It seems that I have again that problem, when I pull from git, but somehow old version remains.

The PR hasn't been merged yet.

Oooops It's me.

[chrisb]

I have simplified the model. The image shows that only one face is selected but the path includes the letters as well.

Edit: The problem occurs even if the letters have a different depth than the frame.

[mlampert]

I have simplified the model. The image shows that only one face is selected but the path includes the letters as well.

Edit: The problem occurs even if the letters have a different depth than the frame.

Confirmed - if I was in marketing I would call it a feature.

Kidding aside I checked with an older version and this is also how it behaved before the refactoring. It seems Pocket always includes the entire shape covered by the perimeter in the removalShape (what one would expect from Surface). I have tried different ways but couldn't find a work around so unfortunately this can't be machined right now. Could you file a bug report please?

[chrisb]

For Qt4 test I still have an old version around and the problem described here was ok then. Even the pocket of the letter "U" worked. Perhaps you can have a look why it worked in that version.

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10692 (Git)
Build type: Release
Branch: (detached from 8337a79)
Hash: 8337a7909fb9395a8a931d466b0cee13ea52e5c6
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0

[mlampert]

For Qt4 test I still have an old version around and the problem described here was ok then. Even the pocket of the letter "U" worked. Perhaps you can have a look why it worked in that version.

Hash: 8337a7909fb9395a8a931d466b0cee13ea52e5c6

That version is from April, before sliptonic changed all ops over to Path.Area. There were a lot of pockets that implementation couldn't handle - and I guess we neglected to test the simple cases

[chrisb]

With all these issues I forgot to praise the current state of the Path WB, especially the UI: due to late changes of the object I had to reassign the edges and faces. It was very fast and easy and intuitive.

So here is a big Thank You!

If we had such easy ways of workflow the topological naming might never have become such a big issue.

[Konstantin]

Ok, after getting in trouble with ccache I finaly built FreeCAD today (with Qt5 and Pyside2). Now I can see drilling menu, but segfault (when drillbit cutting angle > 90°) is not fixed. How to reproduce:

1. Create Job,
2. Remove Default tool
3. Modify some tool to have angle bigger than 90°, add it to the Job
4. Press Drilling button

It looks that problem in line 757

Code: Select all

PathLog.error(translate("Path", "Invalid Cutting Edge Angle %.2f, must be <90° and >=0°") % tool.CuttingEdgeAngle)

If before starting FreeCAD I don't set "LANG=C" it segfaults, if I set - it runs Ok and I see the output in the konsole. Now it's again, Language problem. And I don't know, how to fix it? This:

Code: Select all

OS: "Manjaro Linux"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.11935 (Git)
Build type: Release
Branch: master
Hash: a5bc70cca0d2eaa56709603521650ccb3d8d926c
Python version: 2.7.13
Qt version: 5.9.1
Coin version: 3.1.3
OCC version: 6.9.1.oce-0.18
Locale: Russian/Russia (ru_RU)

segfaults, and this :

Code: Select all

OS: "Manjaro Linux"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.11935 (Git)
Build type: Release
Branch: master
Hash: a5bc70cca0d2eaa56709603521650ccb3d8d926c
Python version: 2.7.13
Qt version: 5.9.1
Coin version: 3.1.3
OCC version: 6.9.1.oce-0.18
Locale: C/Default (C)

not. Should it be somewhere in localization files? Or how PathLog works?


And a bit offtopic here: I still don't understand, why you are against my solution of checking the angle and if it's bigger than 90° divide it and calculate appropriate tip lenght (and checking cutting edge height parameter and use it for tip lenght compensation if angle is 0°)? This was here. This thing can be used (and is used now) ONLY for drilling tip calculation, I do not imagine, where else it could be used and break anything. Even if you implement tapping - you still will need it, (because you can't set it's angle, you should use cutting edge height instead). And this leaves up to me to decide how I want to describe cutting edge of DRILLBIT and TAP only. I don't see here potential problem with breaking anything. It's not even breaking tool structure. "drillTipLength" is made now more like workaround, because we don't have such parameters in the tool, so why don't make this workaround a bit better, until you finally decide, that tool system must be revised.

[chrisb]

Could you file a bug report please?

Done: issue #3170

[mlampert]

Ok, after getting in trouble with ccache I finaly built FreeCAD today (with Qt5 and Pyside2). Now I can see drilling menu, but segfault (when drillbit cutting angle > 90°) is not fixed. How to reproduce:

1. Create Job,
2. Remove Default tool
3. Modify some tool to have angle bigger than 90°, add it to the Job
4. Press Drilling button

It looks that problem in line 757

Code: Select all

PathLog.error(translate("Path", "Invalid Cutting Edge Angle %.2f, must be <90° and >=0°") % tool.CuttingEdgeAngle)

Who would have thought I would ever install Russian on any of my boxes ....
I cannot reproduce the segfault though. I get the error message in the report view:

Capture.PNG (200.4 KiB) Viewed 2160 times

Can you post a stack trace of the segfault?

And a bit offtopic here: I still don't understand, why you are against my solution of checking the angle ...

I never said I'm against your solution, we just haven't decided what we want to do there and currently have more basic functionality to address. We already have a precedence of behaviour and I don't want to replace that with another one if it's quite likely to be replaced again.