Path Operations refactor branch.

Here's the place for discussion related to CAM/CNC and the development of the Path module.
mlampert
Posts: 1330
Joined: Fri Sep 16, 2016 9:28 pm

Re: Path Operations refactor branch.

Postby mlampert » Mon Aug 28, 2017 6:42 am

Konstantin wrote:
Mon Aug 28, 2017 6:21 am
[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
Posts: 261
Joined: Wed Jul 23, 2014 10:10 am

Re: Path Operations refactor branch.

Postby Konstantin » Mon Aug 28, 2017 7:10 am

mlampert wrote:
Mon Aug 28, 2017 6:42 am
Konstantin wrote:
Mon Aug 28, 2017 6:21 am
[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 :lol: It's me. :oops:
chrisb
Posts: 18863
Joined: Tue Mar 17, 2015 9:14 am

Re: Path Operations refactor branch.

Postby chrisb » Mon Aug 28, 2017 7:35 am

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.
Attachments
Bildschirmfoto 2017-08-28 um 10.10.45.png
Bildschirmfoto 2017-08-28 um 10.10.45.png (39.16 KiB) Viewed 866 times
radioForum.FCStd
(170.08 KiB) Downloaded 12 times
mlampert
Posts: 1330
Joined: Fri Sep 16, 2016 9:28 pm

Re: Path Operations refactor branch.

Postby mlampert » Mon Aug 28, 2017 7:05 pm

chrisb wrote:
Mon Aug 28, 2017 7:35 am
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
Posts: 18863
Joined: Tue Mar 17, 2015 9:14 am

Re: Path Operations refactor branch.

Postby chrisb » Mon Aug 28, 2017 10:12 pm

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
Posts: 1330
Joined: Fri Sep 16, 2016 9:28 pm

Re: Path Operations refactor branch.

Postby mlampert » Tue Aug 29, 2017 3:08 am

chrisb wrote:
Mon Aug 28, 2017 10:12 pm
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
Posts: 18863
Joined: Tue Mar 17, 2015 9:14 am

Re: Path Operations refactor branch.

Postby chrisb » Tue Aug 29, 2017 5:39 am

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
Posts: 261
Joined: Wed Jul 23, 2014 10:10 am

Re: Path Operations refactor branch.

Postby Konstantin » Tue Aug 29, 2017 9:59 am

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
Posts: 18863
Joined: Tue Mar 17, 2015 9:14 am

Re: Path Operations refactor branch.

Postby chrisb » Tue Aug 29, 2017 4:07 pm

mlampert wrote:
Mon Aug 28, 2017 7:05 pm
Could you file a bug report please?
Done: issue #3170
mlampert
Posts: 1330
Joined: Fri Sep 16, 2016 9:28 pm

Re: Path Operations refactor branch.

Postby mlampert » Tue Aug 29, 2017 5:39 pm

Konstantin wrote:
Tue Aug 29, 2017 9:59 am
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 .... :D
I cannot reproduce the segfault though. I get the error message in the report view:
Capture.PNG
Capture.PNG (200.4 KiB) Viewed 749 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.
cron