[Problem] Part: Problem in using the sweep function

[FreeCAD-Bug-Importer]

Issue imported from https://tracker.freecad.org/view.php?id=4651

• Reporter: Daniele75
• Date submitted: 5/1/2021
• FreeCAD version: 0.19

Original report text

I found a bug when making springs that occurs in version 19, while up to 18 it worked smoothly.

ref: https://ibb.co/1dN5CMq

Steps to reproduce

1° new file
2° goto "Part" ambient
3° creates parametric geometric primitives
4° Propeller
5° set dimension: pitch 0,75 ; height 3mm ; radius 1,3mm
6° Create Propeller ( Ok )
7° goto "Sketcher" ambient
8° Create new Sketcher
9° Select XZ floor
10° Create circle
11° Set constraints... radius 0,2mm ; height from y axis 0mm ; distance from x axis 1,3mm ( same than radius of propeller )
12° close
13° goto "Part" ambient
14° select Sweep utilities
15° Select Sketch from list available profiles
16° bring to selected profiles
17° select all the propeller in the draw ( black to green color )
18° check create solid + frenet
19° OK

the sweep obtained is corrupted.

Other bug information

• Priority: high
• Severity: minor
• Category: Bug
• OS: Windows 10 Home 20H2
• Updated: 5/13/2021

[plaes]

I ran into this issue when using 0.21.2 / git 33771 / b9bfa5c (Flatpak image).

It seems to be caused by certain multipliers for helix pitch (for example 3mm and 6mm):

Steps to reproduce:

1. Part WB -> Create Primitives -> Helix: Pitch 6mm (or 3mm), Height 30mm, Radius: 8mm
2. Sketcher WB -> Create Sketch: Create a circle on Object's XZ plane, then select helix as external geometry and use lower endpoint of helix as center of circle.
3. Part WB -> Sweep
4. Observe broken spring in 3D:
   
   

If I change Helix pitch to any other value (tried a lot different values from 2 .. 9mm), result looks ok:

Some other broken values: 3.01 and 6.02 (but not 6.01).

Part here compressed as ZIP:
spring.zip

[luzpaz]

@plaes can you also test on the 0.22 development build ?

[plaes]

@plaes can you also test on the 0.22 development build ?

Yes, still present with latest one from https://github.com/FreeCAD/FreeCAD-Bundle:

FreeCAD 0.22.0, Libs: 0.22.0devR35209 (Git)

[luzpaz]

@bgbsww want to take a swipe at this ?

[bgbsww]

Well, I tried, but I can't figure it out. If I follow the instructions ( with Object XZ, is Object XY a typo? ), I end up with a file that doesn't seem to have the bug. But if I open the example file it does. spring2.zip

Working in the broken file, If I replace the sketch or the helix in the original sweep, it doesn't change the problem. But if I create a new sweep, including creating one using the original sketch and helix, the problem goes away.

If I explode the two FCStd files and look at the pieces, I see differences in the circle position in the sketch, where exactly 8mm occurs in the bad file, and the good one is a tiny bit bigger:

<                             <Circle CenterX="8.0000000000000000" CenterY="0.0000000000000000" CenterZ="0.0000000000000000" NormalX="0.0000000000000000" NormalY="0.0000000000000000" NormalZ="1.0000000000000000" AngleXU="-0.0000000000000000" Radius="1.0000000000000000"/>
---
>                             <Circle CenterX="8.0000000000000018" CenterY="0.0000000000000000" CenterZ="0.0000000000000000" NormalX="0.0000000000000000" NormalY="0.0000000000000000" NormalZ="1.0000000000000000" AngleXU="-0.0000000000000000" Radius="1.0000000000000000"/>

There is a corresponding difference in the brep files for the circle:

$ diff PartShape1.brp ../x2/PartShape1.brp 
10c10
< 2 8.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 1.00000000000000000 1.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 1.00000000000000000 0.00000000000000000 1.00000000000000000
---
> 2 8.00000000000000178 0.00000000000000000 0.00000000000000000 0.00000000000000000 0.00000000000000000 1.00000000000000000 1.00000000000000000 0.00000000000000000 -0.00000000000000000 -0.00000000000000000 1.00000000000000000 0.00000000000000000 1.00000000000000000
19c19
< 9.000000000000000 0.000000000000000 0.000000000000000
---
> 9.000000000000002 0.000000000000000 0.000000000000000

The "Good" sweep refers to "Helix[Edge1]" as the Spine. The "Bad" sweep only has "Helix1" ( or "Helix" ) even when you change the property, and I can't see a way to refer to the edge inside. I'm suspicious of this.

Also, note that toggling Frenet to true corrects the view in the "Bad" sweep.

I'm stumped. If someone has a pointer to where to look, I'll try again. Thanks for the tag, @luzpaz.

[luzpaz]

Thanks bgbsww for sleuthing this as far as you could. @FlachyJoe can you weigh-in ?

[FlachyJoe]

3. Sweep in Part workbench (Translation increment 2mm, rotation: 10 degrees)

What does this mean:question:

[plaes]

3. Sweep in Part workbench (Translation increment 2mm, rotation: 10 degrees)

What does this mean❓

This is actually irrelevant, as the bug will show up with default sweep settings (but you can find them by double clicking on the Sweep feature in the model treeview).

I also updated my "walkthrough" and also fixed the XZ plane typo.

[bgbsww]

Does that translation increment / rotation dialog actually do anything? Or does it just come along for the ride as part of the ... --> ViewProviderExtrusion --> ViewProviderPart --> ViewProviderPartExt --> ViewProviderGeometryObject --> ViewProviderDragger inheritance path? Oh, I see, that opens the transform widget, and those control what the transform widget does, but never affects the actual object directly. Learned something today :)

[bgbsww]

Yeah, I can't let go of this bone. So, I think we're at this:

FreeCAD/src/Mod/Part/App/PartFeatures.cpp

Lines 539 to 541 in 94ca51b

	BRepOffsetAPI_MakePipeShell mkPipeShell(TopoDS::Wire(path));
	mkPipeShell.SetMode(isFrenet);
	mkPipeShell.SetTransitionMode(transMode);

and there are a bunch of setMode options: https://dev.opencascade.org/doc/refman/html/class_b_rep_offset_a_p_i___make_pipe_shell.html#a0e026a22a00587b3d36faffbcb68a2c9
The simplest option would just be to force isFrenet, but I'm not sure about the cases where this would cause a problem.

I still don't really understand this, just adding data points. Just for good measure: https://en.wikipedia.org/wiki/Frenet%E2%80%93Serret_formulas

[FlachyJoe]

Even if isFrenet is false, the Frenet orientation is used for simplest path. A "corrected Frenet" is calculated in other cases.
The corrected Frenet aims to smooth the profile rotation along the path in order not to get sudden direction change which cause solid break.
In practice, the introduced rotation seems random and I can't see a use case. I agree isFrenet should be set true by default.

For ref:
https://github.com/Open-Cascade-SAS/OCCT/blob/588ee924e4772389438621106d37144abb694b14/src/GeomFill/GeomFill_CorrectedFrenet.cxx#L337-L367

Standard_Boolean GeomFill_CorrectedFrenet::SetCurve(const Handle(Adaptor3d_Curve)& C) 
{
  GeomFill_TrihedronLaw::SetCurve(C);
  if (! C.IsNull())
  {
    frenet->SetCurve(C);
 
    GeomAbs_CurveType type;
    type = C->GetType();
    switch  (type) 
    {
    case GeomAbs_Circle:
    case GeomAbs_Ellipse:
    case GeomAbs_Hyperbola:
    case GeomAbs_Parabola:
    case GeomAbs_Line:
    {
      // No probleme isFrenet
      isFrenet = Standard_True;
      break;
    }
    default :
    { 
      // We have to search singularities
      isFrenet = Standard_True;
      Init(); 
    }
    }
  }
  return isFrenet;
}

[bgbsww]

OK! I'm not crazy. @luzpaz assign me please, and we'll get this knocked out.

[luzpaz]

Thanks to everyone invovled (especially @bgbsww for stepping up with a fix!)