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.