Adaptive Path/CAM Operation

[kreso-t]

Hi,

I have created a very simple example showing the issue with a cube and a rectangular pocket. It might help to find the error.

I'm setting up a new laptop with

OS: openSUSE Leap 15.1Beta
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16027 (Git) AppImage
Build type: Release
Branch: master
Hash: ad28ba509579d11ac1c6966dedaa70eb6476182b
Python version: 3.6.7
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)

and a old problem comes up...

path_tnw.jpg

I still dont have that at OpenSuse 42.3 and AppImage 0.18 16065. At the 15.1 the "not conda" Appimage don*t work, so i can't check with it...

Also i can't move the view of the object (by clicking the mouse wheel and move) if this kind of path is created. If i delete it moving works like it should.

Ok, will try with openSUSE Leap 15.1Beta.
Thx

[herbk]

Hi kreso

Ok, will try with openSUSE Leap 15.1Beta.
Thx

do you use OpenSuse? I try'd OS Tumbleweed also, but i get FC not running on it... Not the versions from OS repos, nor from science or the AppImage...

[kreso-t]

Hi kreso

Ok, will try with openSUSE Leap 15.1Beta.
Thx

do you use OpenSuse? I try'd OS Tumbleweed also, but i get FC not running on it... Not the versions from OS repos, nor from science or the AppImage...

No, I use Linux Mint 18.3 with Cinnamon at the moment, but will try to install openSUSE into VirtualBox

[Wsk8]

Hello,

i added the option to generate G2 arcs for helix ramp (instead of G1 segments) in PathAdaptive. Maybe some of you could test it.

mfg

[huegene]

Hi,
regarding the Path to nowhere issue, I too get this with just a simple rect. pocket. After looking into the python script and doing some "debug print" on it,
it almost seems like an issue of the python interpreter. At line 191 of the adaptive script, a print on "region" seems to yield "correct" (bounded) coordinates. A print in a for loop i.e.:
for i in region["AdaptivePaths"]:
>>>>print(i)
seems to yield bogus values.
also the for loop seems to print many more values than a plain print does. Anyone an idea what that could be?

kind regards
huegene

p.s.
OS: Debian GNU/Linux buster/sid
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.
Build type: Release
Python version: 2.7.16rc1
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)

[chrisb]

I rechecked an old issue and it is gone: https://forum.freecadweb.org/viewtopic. ... 18#p277918
I had to recreate the operation due to internal changes.

[bill]

Hey kreso,
As an option selection, what are the chances/how difficult of modifying Path-Adaptive Op to just applying the waterline path segments and no material clearing to stock.

This way one could execute a normal Adaptive Op to clear material and follow it up with a secondary adapt-op/more precise (shallow-step-down) waterline cut for finishing.

And the heck with OCL (for me); waterline would be effectively included in adaptive op.

Those top three circular paths are effectively waterline path/cuts.

The green dot on top is a false-flat-reference height to enable(fool/satisfy) the operation

AdaptiveWaterLines.png (92.92 KiB) Viewed 1267 times

[sliptonic]

And the heck with OCL (for me); waterline would be effectively included in adaptive op.

Not quite. Ocl waterline takes into account tool shape. It works accurately with ball-end, bull nose, and cylindrical cutters. Or, at least, it's capable of doing that but not all tools are fully implemented.

Adaptive only uses cylindrical cutters.

[bill]

yeah, I know what OCL does. But currently, its not living up to its potential like when I used it in HEEKs CAD.

If it is no big deal to make such a mod, its a good option/temporary solution.

Just like in an old school machine shop, the more tools, jigs, fixtures, and etc. the better; it does not change for CNC.

Let the eMachinist decide the milling strategy!

[sliptonic]

It works accurately with ball-end, bull nose, and cylindrical cutters. Or, at least, it's capable of doing that but not all tools are fully implemented.

Correction. It looks like Russ fully implemented the other cutter types when he improved surface.