A Path command for circular holes and some questions

[cox]

I do not like the idea of the helix operation be under drilling, even if it fits better with the programming, drilling is as mentioned restricted to vertical movement and any horizontal cutting with a drillbit would probably break it. Running a vertical operation with a drill bit in the machine should rather give a warning(Maybe not a popup, but some colour info on the tool or operation). . There are also special cnc drilling machines that does not have suitable bearings for horizontal cutting movement and could seriously harm the machine doing this.

My two cents : Helix operation in pocket drop-down, as circle icon in sketch workbench.

[bill]

As cox said,

Post by cox » Thu Jun 16, 2016 10:20 am
I do not like the idea of the helix operation be under drilling, even if it fits better with the programming,

From what I have ever seen, this is what is referred to as "(Helix) Hole Interpolation MACHINING" and is not a drilling operation: Closer to a BORING operation.

In no way could you ever compare their relative precision (since drills drift quite a bit depending on conditions)

It is worth a separate/wizard operation tab. Same WIZARD tab could support "Path:FACING"; additionally, any number of things macro-like (i.e. -all the other wbs) that WILL pop-up!

[lorenz]

But the lack of any decent topology information exposed to the Python layer makes all such endeavors quite painful. Does anyone know more about that, or has some hints for me?

Can you elaborate on this a bit? I don't understand what you mean.

Well, basic adjacency information: For example, given a face and one of its edges return the face that also connects to that edge. These relations must exist somewhere. Right now I loop over all possible faces, loop over each of their edges and test if one of them isEqual to the given edge. This feels a bit absurd.

[herbk]

Hi Lorenz,

By the way, I see that the profile operation has the same problem with my locale, when I open the task panel, all Gui::InputField widgets have much too large values: the commas are dropped and e.g. "10,5 mm" is converted to "105 mm"

This Problem is still there, but if i remember right it was there since the path version with sufacing includet is in major. It seams to me as will be one 0 will be addet on start depht an save high each time you open the path again.


@sliptonic: As others sayd before, also in my mind the helix operations would be better placed in pocket. Drilling is a operation with e movement in the z axis only...

[lorenz]

Another thing I noticed: Sometimes Profile inserts a full circle at tangential lines attached to an arc, I guess there is some numerical precision issue there:

I've noticed this as well but I don't know why it occurs. The libarea algorithm doesn't seem to have the problem and is generally more reliable.

I think I found the reason for this, it occurs when trying to convert a circle where the start and endpoint are (almost) the same. This is then mistaken for a full circle in the GCode representation. A tentative patch for this can be found at

https://github.com/dev-at-stellardeath- ... 66daeed8ab

[lorenz]

Something wrong with the patch? Should I make a pull-request? Or is this not necessary anyway, as the "OCC native" method is never used by anyone anyway?

[sliptonic]

Something wrong with the patch? Should I make a pull-request? Or is this not necessary anyway, as the "OCC native" method is never used by anyone anyway?

Sorry lorenz, I missed this. It looks good to me. PR would be great.

[lorenz]

Ok, done:
https://github.com/FreeCAD/FreeCAD/pull/217

Meanwhile I found a much cleaner way to detect when the generated circle is wrong: Just look at the generated coordinates directly instead to compare them to some arbitrarily defined small value, see the PR.