Can 3d Pocket deal with ballend toolbits?

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
User avatar
pathfinder
Posts: 315
Joined: Mon Oct 04, 2021 10:27 am

Can 3d Pocket deal with ballend toolbits?

Post by pathfinder »

I'll go out on a limb and assume that the answer is no, but I thought I'd ask whether maybe I'm missing something.

I machined a piece with a roughing pass with an endmill and a finishing pass with a ballend, using 3D pocket to generate the toolpaths. I noticed that even with considerable offset, the ballend wouldn't get rid of the marks the endmill left, so I investigated. The shapes I cut are supposed to be half spherical holes, but they didn't turn out to be spherical at all.

To check, I generated toolpaths on a half spherical hole with a regular endmill and a ballend toolbit and they are the same. I didn't notice before because I gave the roughing pass an offset. So I wonder whether this is expected behavior or whether maybe my toolbit isn't configured properly. I used the toolbit library of an earlier version or the linkstage branch.

As for the version I'm using to genreate the toolpaths:

Code: Select all

OS: Arch Linux (XFCE/xfce)
Word size of FreeCAD: 64-bit
Version: 0.20.28872 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 9057658)
Hash: 9057658ae5d638f6903bc831b53ceb349c2870a2
Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3
Locale: English/United States (en_US)
I'm looking into using 3D surface instead, but the toolpaths are either very different from the ones 3D pocket generates or take ages and unreasonable amounts of ram.

TIA
Russ4262
Posts: 941
Joined: Sat Jun 30, 2018 3:22 pm
Location: Oklahoma
Contact:

Re: Can 3d Pocket deal with ballend toolbits?

Post by Russ4262 »

pathfinder wrote: Sun May 22, 2022 12:23 am I'll go out on a limb and assume that the answer is no, ...
Evening.
Correct. The answer is no.
Profile, Pocket, MillFace, (I think .... Helix), Adaptive, Slot, and 3D Pocket are all calculating paths based on a standard endmill shape.

Russell

Code: Select all

OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.20.28914 +9 (Git)
Build type: Release
Branch: master_prs
Hash: 372c0025e2d72d8f06bcd74eb9b8b393db965f92
Python 3.8.6+, Qt 5.15.2, Coin 4.0.1, OCC 7.5.0
Locale: English/United States (en_US)
Installed mods: 
  * FC_SU
  * Z_MacroStartup
User avatar
pathfinder
Posts: 315
Joined: Mon Oct 04, 2021 10:27 am

Re: Can 3d Pocket deal with ballend toolbits?

Post by pathfinder »

Thanks for the reply; I guess I'll have to use 3d surface then.

I managed to get roughly the shape I want in 3d surface by using the offset pattern, but I'm having issues with computing time and RAM usage. This is the shape I'm working on:

Image

Every hole takes roughly 4 minutes to compute and takes roughly 25 GB of RAM. I ended up using arrays to get the other holes, but I'll probably have more irregular shapes upcoming where arrays won't work as easily, and I already dread it.
User avatar
pathfinder
Posts: 315
Joined: Mon Oct 04, 2021 10:27 am

Re: Can 3d Pocket deal with ballend toolbits?

Post by pathfinder »

Addendum; I'm not sure whether this is of interest, but maybe there's something in it for others to explore:

I couldn't let the 3d pocket thing go and since the base shape (a half sphere) is rather simple, I had another go at it. My thought was that if I had the shape of the endmill and the ballend as an overlay, I could cut the hole in a way that the path workbench would generate a toolpath for the endmill shape, but that would cut what I want it to cut using the ballend. So I made a rather convoluted sketch:

Image

What I am working with here are 6mm endmill or ballend toolbits. The half sphere is 26mm in diameter.

The first interesting thing is that I can draw a three point arc that pretty much covers all the points where the endmill would touch.

The second interesting thing is that the diameter of that ark is exactly 20mm, which is the diameter of the half sphere minus the tool diameter.

This approach comes with a pretty obvious flaw: the last 6mm of the bottom stay flat, even though the ballend toolbit would be able to shape it. Same goes for the first 3mm(?) of depth.

Nonetheless, I think it's an interesting observation.
memfis
Posts: 586
Joined: Tue Nov 15, 2016 7:58 pm

Re: Can 3d Pocket deal with ballend toolbits?

Post by memfis »

Greetings to a colleague from ArchLinix!

I believe you are going the right way - it is about the last sketch that shows the movement of the end of the circular cutter over the surface. The 25gb is creepy. But in your case, IMHO, it's simple - g-code, using LinuxCNC as an example, has perfectly implemented loops. All the contact points in the cross section you drew are easy to calculate, simple trigonometry. I (if I were you) would implement each cavity as a cycle - decreasing circles depending on Z.

Something along the lines of

o<rad> sub
how you plan to do the radius (for the finishing pass) or the entire plane inside the radius (roughing pass)/ It can be a few lines of code forming any profile, where the height of Z execution is used as Z[#1]
o<rad> endsub

#1 = 10000 (Zmax)
#<_z_min> = -1000
o<glubina> while [#1 ge #<_z_min>]
#<r> = функция[ #1 ]
o<rad> call [#1] [#<r>]
#1 = [#1 - #<_dz>]
o<glubina> endwhile


And no gigabytes.

You can change the algorithm for changing the diameter of the circle as Z changes, just by making different cycles with different content (logic) for different height zones. But really, if we have a cutter end circle and a circumference of a given pocket section, the contact point (tangent) is easily calculated and the Z step should be made variable based on the calculated distance between the tangent points (= wavelength) or the allowable size of the bump (wavelength height).

Essentially you just need to know the mathematics of the cutter end tangent circle point trajectory and the profile of the slot section + the coordinates of the slot centers on the entire workpiece, organize the cycles. This is an economical, simple and reliable solution, without any magic and dependence on unknown logic.
Last edited by memfis on Mon May 23, 2022 8:57 am, edited 2 times in total.
memfis
Posts: 586
Joined: Tue Nov 15, 2016 7:58 pm

Re: Can 3d Pocket deal with ballend toolbits?

Post by memfis »

Russ4262 wrote: Sun May 22, 2022 2:46 am
Evening.
Correct. The answer is no.
Profile, Pocket, MillFace, (I think .... Helix), Adaptive, Slot, and 3D Pocket are all calculating paths based on a standard endmill shape.

Russell
Sorry for the immodest question - then why do we set its shape when selecting a tool, if (if I understood the answer "no" correctly) this set shape is not taken into account when calculating the trajectory?!
User avatar
pathfinder
Posts: 315
Joined: Mon Oct 04, 2021 10:27 am

Re: Can 3d Pocket deal with ballend toolbits?

Post by pathfinder »

memfis wrote: Mon May 23, 2022 8:38 am Something along the lines of

o<rad> sub
how you plan to do the radius (for the finishing pass) or the entire plane inside the radius (roughing pass)/ It can be a few lines of code forming any profile, where the height of Z execution is used as Z[#1]
o<rad> endsub

#1 = 10000 (Zmax)
#<_z_min> = -1000
o<glubina> while [#1 ge #<_z_min>]
#<r> = функция[ #1 ]
o<rad> call [#1] [#<r>]
#1 = [#1 - #<_dz>]
o<glubina> endwhile


And no gigabytes.
Hello, thank you for your input!

Sadly, when it comes to math and programming, I am basically illiterate, so I have a hard time understanding what you are trying to say. For the current project, I will go ahead and build a model that has the holes as I sketched them. It would be great to have a way to automate this in the background, or even use it to calculate the correct offset for ballend toolbits on non-spherical 3d shapes, but I won't be the person implementing it; that is outside of my abilities.

As for RAM, this is something I had happen quite often with 3d surface. The object I'm working on is considerably bigger than it looks in the first image I posted, which I think is part of the issue here. Even though I want the 3d surface to be applied to only one face, it seems like the function is taking the whole object into account. I tested it by building the object with only one hole, the RAM usage is considerably lower, although still in the GB range. Another thing is that RAM isn't freed up efficiently. When I do a second operation on a different face, the RAM usage increases by a few GB with every new operation, so I'll have to eventually save, close and reopen FreeCAD to have it work properly again (only closing the project doesn't seem to work; I need to close FreeCAD completely).
memfis wrote: Mon May 23, 2022 8:51 am
Sorry for the immodest question - then why do we set its shape when selecting a tool, if (if I understood the answer "no" correctly) this set shape is not taken into account when calculating the trajectory?!
Well, I think part of the answer is that for any 2.5d operation such as facing, adaptive, helix and so on, it technically doesn't really make much of a difference, but if you would want to use a ballend for that function, you need to be able to set it to have it shown in the gcode, be it for an automatic toolchanger or to remind you of the tool you were planning on using.

However, what would have been nice to have is a disclaimer in the 3d pocket dialog stating that the ballend will be treated as an endmill, like a popup stating "Non-endmill shaped toolbit detected; toolpath may be inaccurate for 3d pocket/facing/…" with a "Don't show again" option.
memfis
Posts: 586
Joined: Tue Nov 15, 2016 7:58 pm

Re: Can 3d Pocket deal with ballend toolbits?

Post by memfis »

pathfinder wrote: Mon May 23, 2022 10:38 am
Sadly, when it comes to math and programming, I am basically illiterate, so I have a hard time understanding what you are trying to say. For the current project, I will go ahead and build a model that has the holes as I sketched them. It would be great to have a way to automate this in the background, or even use it to calculate the correct offset for ballend toolbits on non-spherical 3d shapes, but I won't be the person implementing it; that is outside of my abilities.
Don't demonize the complexity :) - it's simple rectangular triangles and simple loops.
If it is a real and not very urgent task + you work with the machine in LinuxCNC, then I can write these dozens, a few dozens of lines of code (for free, of course, by the end of this week or next week) - just contact me by mail.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Can 3d Pocket deal with ballend toolbits?

Post by sliptonic »

memfis wrote: Mon May 23, 2022 8:51 am
Russ4262 wrote: Sun May 22, 2022 2:46 am
Evening.
Correct. The answer is no.
Profile, Pocket, MillFace, (I think .... Helix), Adaptive, Slot, and 3D Pocket are all calculating paths based on a standard endmill shape.

Russell
Sorry for the immodest question - then why do we set its shape when selecting a tool, if (if I understood the answer "no" correctly) this set shape is not taken into account when calculating the trajectory?!
Tool shape is taken into account for the OCL based operations (surface and waterline) and also for v-cutter engraving (vcarve). For the ops Russ listed which use libarea/PathArea, only the tool diameter is used.
Post Reply