Rotated holes result in different sized Helix tool paths.

[bill]

Its really getting on my nerves that there is so much resistance to change in this forum, there is always a lot of blow back even when fixing things that are clearly bugs.

Deja Blues, But your not a troll; NO! A good forum moderator would have chastized you for that ignorant comment!

AFAICT the issue is not with Path, it seems to be with the model.

Try Drill OP on those same holes; you will see the same issue probably.

If you cant get into OCC code, then exercise it.
Scale (up and down) the geometries to see if error scales or is consistent, or goes away/lost in data-type rounding or something of that sort.

Ive encountered this before in drilling; no problem there, cause the drill bit knows what size it is!

[mlampert]

Its really getting on my nerves that there is so much resistance to change in this forum, there is always a lot of blow back even when fixing things that are clearly bugs.

your definition of "clearly bugs" seems to be combination of personal preferences and assumptions. How about some engineering practices, measure it, show that it's wrong, correcting it and measure it again to make sure this time it's correct?

If it's such a trivial thing it shouldn't be too hard to prove me wrong - right?

[IMback!]

your definition of "clearly bugs" seems to be combination of personal preferences and assumptions. How about some engineering practices, measure it, show that it's wrong, correcting it and measure it again to make sure this time it's correct?

If it's such a trivial thing it shouldn't be too hard to prove me wrong - right?

This is just plain absurd. An implementation detail that never needed a test suddenly needs a unit test just because i fixed a bug. A bug that is easily reproducible, has been independently reproduced many times now and the cause of which can be and has been definitely proven via code analysis.

A test would be nice sure. But writing one that is robust is hard, as the unit test would be by definition sensitive to the implantation details of the tesselation. A unit test that will be false negative or false positve in the future due to unrelated implementation changes to other components of freecad is a bad idea. If you know how to avoid this please wirte a robust unit test.

Your obstructionist behaviour only serves to alienate contributors. Its working, after fixing the safe height use so the gcode agrees with the documentation i will not be contributing to freecad path again, its just not worth my time.

[IMback!]

To allow simpler reproduction here is a procedure. Note that this procedure must be followed precisely as the tessellation is very sensitive to model and settings changes:

1. delete your freecad settings / profile
2. Create new document
3. open freecad go to part workbench
4. create cube and cylinder don't change any values
5. move cylinder to centre of cube with transform tool
6. cut cylinder and cube
7. open transformation tool on the cut
8. set the rotation increment to 31 degrees, this being a prime number is important for reliability.
9. rotate around z axis: one increment clockwise
10. go to path workbench
11. create job with cut as selected object
12. accept job defaults
13. select cylindrical face
14. create helix operation
15. observe diameter (its 3.999)
16. accept helix (ignore assert due to tool size, mlampert already fixed this in his branch)
17. go v and 6 on keyboard to view triangulation for the viewport
18. observe hole on x direction: there is no vertex at the apex of the hole.
19. mark the cut for recomputation, press F5
20. Observe how the triangulation now looks: there is a vertex at the apex of the hole.
21. Go to helix operation
22. observe diameter (its 4)

Why dose this happen?

• openCASCADE boundbox add() uses the last tesselation called on a face to determine the bound box by compering the vertex positions.
• Most of the time the last tesselation was called by the viewport, but it could be anything really.
• Currently, with default settings the viewport and openCascade happens to tesselate such that the holes have a vertex at the apex in the x direction most of the time, masking this bug.
• This behaviour is not guaranteed at all, the tesselation algorithm may place the vertex anywhere, and dose on some models, like rainharvesters.
• Changing the viewport settings will change the outputted diameter.
• Very high tesselation settings in the viewport will mask this bug via the internal rounding mechanism.
• If a tesselation was called by some other operation (like meshing) this tesselation will be used instead of the viewports for the boundbox in path, unless the viewport tessellated again afterwards.
• The above procedure is not useful as a unit test as the tesselation algorithm or viewport may change in new occ or freecad versions, silently making the test useless.

Can we please merge the fix now? Or at least acknowledge that there is a problem and fix it via alternative means? like explicitly tessellating at hight accuracy before calling the bound box?

[chrisb]

Can you please upload the file at least after Step 9 with the attributes set in the view properties?

[GeneFC]

I ran through this sequence of operations starting at step 2 and I saw exactly 4.000 mm for the diameter. I could not see any vertices before or after recompute.

Why???

The same problem comes up again and again. If someone needs precision in a case like this then it is mandatory that the "Tessellation" setting in Preferences is set as tight as possible. This setting is under Part Design, but it seems to apply generally. I keep the "Maximum deviation depending on the model bounding box" at 0.0100% all the time.

The "bug", if there is one, is that the default value for this setting is too coarse. Tighten it up and the tessellation problems will go away.

Gene

[rainharvester]

Hmm. Is the default set for gui /rendering speed/memory savings? It seems like the more accurate, actual radius should always be used for cases when it would make a difference regardless of what the default is set to. Otherwise, going with a strategy of "Just switch a default, setting" there could be a million other settings that could be messed up when a user doesn't know about them, or knows about them but doesn't realize they can affect this or that etc.
I even tried changing all the default I could find, with no luck (see OP). I'll try again later. Thanks for posting another workaround (sometimes a workaround isn't compatible with another workaround! Good to have options until it's fixed!)

[IMback!]

I ran through this sequence of operations starting at step 2 and I saw exactly 4.000 mm for the diameter. I could not see any vertices before or after recompute.

Why???

The same problem comes up again and again. If someone needs precision in a case like this then it is mandatory that the "Tessellation" setting in Preferences is set as tight as possible. This setting is under Part Design, but it seems to apply generally. I keep the "Maximum deviation depending on the model bounding box" at 0.0100% all the time.

The "bug", if there is one, is that the default value for this setting is too coarse. Tighten it up and the tessellation problems will go away.

Gene

If the operation where tessellating based on the geometry tolerance settings in path this would not be a problem, it would still be a bit less than optimal since we would be wasting computational time estimating a value that we know already. However currently the last tesselation outside of path is used, which may be of any random accuracy, depending on what operations the user did last. This happens to be the viewport most of the time, so the viewport settings apply, but its prefectly reasonable for other parts of freecad to call tesselate() on the face to perform operations. this is a problem.

[mlampert]

There's indeed something funny happening here. The original diameter for me is 3.988, and after the recompute it's 4.000, and if I open the Helix again it's 3.988, again. In fact it was 4.000 exactly once - I'm almost tempted to chalk it off as wishful thinking. My testing is rather limited, I keep segfaulting FC in the App::DocumentObject::recompute() member and probably should make a fresh build tomorrow.

[GeneFC]

Thanks for posting another workaround

I do not consider this a "workaround". FreeCAD is built on the OCC computational kernel. Everything is an approximation at some level. It is not really possible to work on a perfect circle; there is always some uncertainty, approximation, truncation, tessellation, etc.

For most users of FreeCAD the approximations are fine. If you need 0.001 mm precision (or even tighter) for Path operations then the approximation parameters in OCC need to be set appropriately.

I have no doubt that the Path Helix coding can be modifed to cover up the underlying problem that comes from the OCC operations. However, the same tessellation problem shows up in other places. "Fixing" the problem in Path Helix is just a Band-Aid for the real issue.

Gene