FreeCAD
FreeCAD copied to clipboard
Toponaming: Data compatibility issue (RC2)
Is there an existing issue for this?
- [X] I have searched the existing issues
Problem description
I found a data compatibility issue in FreeCAD 1.0 RC2.
I attach two examples.
When opening them in FreeCAD 1.0 RC2, a recalicuration error occurs in each file. When opening or recalicurating them in FreeCAD 0.19.3, 0.20.2 and 0.21.2, there are no errors.
It may be related to #16934.
Full version info
OS: Windows 11 build 26100
Word size of FreeCAD: 64-bit
Version: 1.0.0RC2.38806 (Git)
Build type: Release
Branch: (HEAD detached at 1.0rc2)
Hash: 3d63fc6c2f665a8d5e6468845a419bcac80756c7
Python 3.11.9, Qt 5.15.13, Coin 4.0.3, Vtk 9.2.6, OCC 7.7.2
Locale: Japanese/Japan (ja_JP)
Stylesheet/Theme/QtStyle: FreeCAD Dark.qss/FreeCAD Dark/Fusion
Subproject(s) affected?
PartDesign
Anything else?
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Can confirm. @CalligaroV is this TNP related?
My findings, Example1.FCStd, minor issues in Report View which can be corrected by user to stop them reoccurring:
15:24:50 PartDesign_Hole - There is a duplicate circle/curve center at 75.00 : 30.00 : -10.00 therefore not passing parameter
15:24:50 PartDesign_Hole - There is a duplicate circle/curve center at 75.00 : 30.00 : -10.00 therefore not passing parameter
15:24:50 PartDesign_Hole - There is a duplicate circle/curve center at 75.00 : 30.00 : -10.00 therefore not passing parameter
15:24:50 PartDesign_Hole - There is a duplicate circle/curve center at -75.00 : 30.00 : -10.00 therefore not passing parameter
15:24:50 PartDesign_Hole - There is a duplicate circle/curve center at -75.00 : 30.00 : -10.00 therefore not passing parameter
15:24:50 PartDesign_Hole - There is a duplicate circle/curve center at -75.00 : 30.00 : -10.00 therefore not passing parameter
Example2.FCStd more serious and looks like TNP algorithm has moved edges around for Chamfer003, expected result:
actual result:
Thanks @maxwxyz for the ping and @Syres916 for this first demonstration.
Looking at the screenshots looks indeed TNP related but ATM I'm more focused in reviewing/testing another PR.
I'll dig into this ASA I end my actual task, likely in the next days / weekend. Maybe that will help solving / solve also this issue.
If I don't come back to this issue please don't hesitate to ping me again!
Maybe I found the cause of the issue. Do a Chamfer after a Revolution, edges are moved.
I attach Example3.FCStd. Example3.zip
0.21.2:
1.0 RC2 or weekly build 38923:
I'm pretty sure I'm affected by the same problem (or at least one with very similar symptoms) but none of the bodies in that project use chamfers (some use fillets, though, and it's mostly fillets applying to the wrong edges) and none of the affected ones use a revolution.
I'll dig into this ASA I end my actual task, likely in the next days / weekend. Maybe that will help solving / solve also this issue.
If I don't come back to this issue please don't hesitate to ping me again!
CC @CalligaroV
@luzpaz, coming back to this right now while I wait replies about another issue.
Unless something more serious comes out in the meantime, this will be my main task for now on.
Thanks @marbocub and @AnyOldName3 for your feedback, hopefully those will help me narrowing the research.
@AnyOldName3, could you share more info about you issue? File, screenshots, screencasts, steps you do to trigger your issue, Report View messages... without info I can analyze only @marbocub's issue
@luzpaz, @marbocub, by now I can give a couple of quick updates:
First: I can confirm also @marbocub's https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2409852508
Second: No issues when trying to open Example3.zip with LS3 Usually this is good and means that some part of Toponaming code have not yet been imported into main yet.
Now searching for the missing code.
I'm doing some work on one of my 3D printers, and have been learning FreeCAD as I go, so lots of this file is made in questionable ways. In 0.21.2, it looks like this:
and everything computes fine (although the final subtractive pipe on NozzleInlet isn't doing what I want, but the project was misbehaving in the 1.0 RC before I'd started on the nozzle). Nothing's printed to the report view when it's loaded.
When I load it with the 1.0 RC2, and it tries to recompute as part of the migration, I'm met with a wall of errors in the report view:
Click to expand
23:00:16 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:16 PositionBySupport: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:16 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:17 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:17 PositionBySupport: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:17 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:17 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:17 PositionBySupport: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:17 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:18 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:18 <Exception> AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:18 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:00:18 <Exception> AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:29 Fillet002: BRep_API: command not done
23:00:29 Fillet006: BRep_API: command not done
23:00:29 Cylinder: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:29 Cylinder002: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:00:29 Sketch087: Solving the sketch failed
23:01:27 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:01:27 <Exception> AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:01:28 <Exception> AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 Fillet002: BRep_API: command not done
23:01:28 Fillet006: BRep_API: command not done
23:01:28 Cylinder: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 Cylinder002: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 Sketch087: Solving the sketch failed
23:01:28 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:01:28 <Exception> AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis.
23:01:28 <Exception> AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 Fillet002: BRep_API: command not done
23:01:28 Fillet006: BRep_API: command not done
23:01:28 Cylinder: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 Cylinder002: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
23:01:28 Sketch087: Solving the sketch failed
One of the obvious problems I've been able to identify is with Fillet002 on the first stepper motor:
It's decided to assign edge names differently, so obviously the fillet can't be applied as some of the edges are too near other things.
I've also tried to identify the cause of the first error that's logged, the AttachEngine3D::calculateAttachedPlacement: path curve second derivative is below 1e-14, can't align x axis. one, and it seems to be because an edge name that used to refer to a circle now refers to a straight line, so the attachment for an additive cylinder doesn't work.
Many thanks @AnyOldName3 for your detailed info.
I can partially confirm what I said in https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2442656682 about @marbocub's Example3.zip: LS3 handles yours issue-demo.zip with almost no issues.
The issues I found there are related to NozzleInlet.Sketch092, Stepper.Fillet004 and Stepper001.Fillet008.
Not sure about what's causing the issue there too but surely this will be a good test file to improve both main and LS3.
I'll report my updates as soon as I make progress.
For now thanks again!
@luzpaz, @Syres916, @maxwxyz, I think I found out why on LS3 @marbocub's files update correctly.
The following code is missing in GeoFeature::updateElementReference() on main:
auto version = getElementMapVersion(prop);
if(_ElementMapVersion.getStrValue().empty())
_ElementMapVersion.setValue(version);
else if(_ElementMapVersion.getStrValue()!=version) {
reset = true;
_ElementMapVersion.setValue(version);
}
AFAICS, while debugging LS3 this, if reset = true the elements are updated with their MappedNames in the element map.
I already tried to import that code but looks that there's still something missing (main doesn't set reset = true).
Going on with the research.
Side note: as for my previous https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2445431099, does it make sense to create another issue for @AnyOldName3's file?
@luzpaz, @Syres916, @maxwxyz after quite some fighting I think I found how to fix this issue.
There's some code to import from LS3 but, after importing it, all the example files shared by @marbocub looks working correctly AFAICS.
I pushed a new branch on my GitHub repo: https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3
Can someone please test it and give me feedback (both with the same test files and/or with other files)? If positive then I'll open a PR on main.
TIA!
Can someone please test it and give me feedback (both with the same test files and/or with other files)? If positive then I'll open a PR on main.
I compiled your branch and tested the 4 files attached here. I'm still getting recompute errors for the first example (Example1.FCStd) and the last one (issue-demo.FCStd) but the other two are working fine.
@FEA-eng many thanks for looking at this.
I confirm your analysis, at least for @marbocub's Example1.FCStd.
Haven't focused on @AnyOldName3's issue-demo.zip because, as for my https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2445431099, I'm aware that the modifications in https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3 don't handle 100% correctly that model.
However, in my local tests, the recompute error with @marbocub's Example1.FCStd triggers only if I test it in a Conda Environment.
If I test it with a classic Debian-derived environment (i.e. with the libraries installed according to https://wiki.freecad.org/Compile_on_Linux#Single_command_for_Python_3_and_Qt5) I get no errors.
Haven't investigated much about that but my guess is that the error is caused by different versions of the dependencies used in a classic Linux environment and the dependencies used in a Conda environment.
Regardless for that, after more careful analysis, I noticed another thing:
Example1.FCStd, even if recomputed without errors, doesn't produce the same model of v0.21.
The Chamfer on the right side on the model is different, both with main and with LS3
v0.21
v1.00
LS3
Activating/Deactivating the Refine options in Preferences->Part/PartDesign->General don't change the outcome.
ATM, looking at Example1.FCStd's tree, my guess is that there are some issues related to Chamfers built on top of other Chamfers
Therefor @marbocub sorry, I told you only a half-truth (Example1.FCStd doesn't rebuild 100% correctly in main/v1.0) :confounded:
Summarizing To fully fix this, and other related issues, more work is needed, mainly regarding the Chamfer operations.
The quest continues.
@marbocub, I have an update:
The issue described in my previous https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2481277952 is caused by the absence of the following line in PartDesign::Hole::execute(), present in v0.21.2 but not in main nor in LS3
https://github.com/FreeCAD/FreeCAD/blob/b9bfa5c5507506e4515816414cd27f4851d00489/src/Mod/PartDesign/App/FeatureHole.cpp#L1901
Adding it restores correctly also Example1.FCStd's Chamfer007
The modified code is in a new branch, https://github.com/CalligaroV/FreeCAD/tree/pd-hole-restore-missing-refineShapeIfActive, based on my previous https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3 (needed to correctly restore Example2.FCStd and Example3.FCStd).
Both branches are rebased on top of Nov 22, 2024 commit https://github.com/FreeCAD/FreeCAD/commit/b5a43eb2208b91feb76b2cc363e3956922c3ad75
As always, I kindly ask if somebody can test this new branch (the one related to PartDesign::Hole::execute()) and give me a feedback before I open a PR.
TIA to everyone!
@FEA-eng can you test after your vacation?
@FEA-eng can you test after your vacation?
Yeah, sure
I retested with the new branch. Now the first example works (examples 2 and 3 still work as well) but the last one (issue-demo.FCStd) shows errors:
15:50:42 Fillet004: BRep_API: command not done
15:50:42 Fillet008: BRep_API: command not done
15:50:42 Cylinder014: AttachEngine3D::calculateAttachedPlacement: Frenet-Serret normal is undefined. Can't align to TN plane.
15:50:42 SubtractivePipe: Base shape is not valid for boolean operation
Many thanks @FEA-eng for retesting!
Good to know that also Example1.FCStd now works.
I'm going to open a dedicated PR for the PartDesign::Hole::execute() issue, as that is a regression (in v0.21 it used to work, as reported in the first screenshot of my https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2481277952).
In the next days I'll open another PR with all the code imported regarding the _ElementMapVersion property (I'd like to add some tests before opening a PR, but for that I'll need some more time to develop them).
Any hint would be very appreciated!
Regardless for that, thanks again for testing!
ETA: about issue-demo.zip I haven't figured out yet why it's not working, therefor I'll need more time to analyze it and find a possible fix.
@marbocub can I reuse your Example3.zip to develop an automatic test for the CI?
I'm trying to create a model with v0.21 that generate the same error but haven't figured out yet what should be in that model.
Therefor I'm thinking about developing the test using the files you provided and IMO Example3.zip is the best candidate as it's pretty simple, lightweight, generates the error and, according to https://github.com/FreeCAD/FreeCAD/issues/17124#issuecomment-2517662019, is fixed by my https://github.com/CalligaroV/FreeCAD/tree/toponaming-ElementMapVersion-code-from-LS3.
The file will be added to the FreeCAD repo, most likely somewhere inside https://github.com/FreeCAD/FreeCAD/tree/main/tests/src/Mod/PartDesign/App and the test will try to open it.
So it ok for you if I use Example3.zip for this purpose?
TIA!
@CalligaroV Yes of course.
Sorry for being away from this issue and testing, by an important event in my life.
@marbocub don't worry, I hope your event was an happy one!
Anyway thank you very much for allowing us to reuse your file! I'm going right now to finally open a PR with the code discussed until now.
Thank you very much again!
My issue demo file still doesn't work perfectly in today's dev build, but this issue's been closed without there being a definitive statement that my file needed a separate item on this issue tracker. Whether that means this issue wants reopening, or a new one needs creating, there's still a regression here.
which file is not fixed? The PR mentioned it fixed both of the files in the .zip. @CalligaroV FYI
The one in issue-demo.zip. Both isn't quite the right word when it only dealt with two out of three.