FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
chimaera
Posts: 4
Joined: Sun Jun 21, 2020 1:41 pm

FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by chimaera »

A bold title for my first post but apt I think. Some background before I get into the meat of it.

I am a mechanical design engineer. I use Solidworks 5 days a week for new product development and enhancement/refinement of existing products in a small manufacturing company that specialises in high end digital tools for automotive, aerospace and other industries. Throughout the last 23 or so years of my career as a student and as a professional I have used a large variety of 2D and 3D CAD tools. For the last 10 or so, those have been primarily Draftsight for 2D, and Solidworks for 3D. I would like to think I have a good handle on what is involved in designing mechanical parts using parametric CAD tools (hubris perhaps?).

A core reality in the engineering design process is that it is iterative and cyclical, involving frequent modification of part designs until the desired specification is reached. This can mean adding new features to a part, modifying existing features, or removing features that are surplus/redundant. I have found that with a little care, Solidworks is robust at enabling this workflow: all of these modifications can be accommodated reasonably well, and the odd thing that breaks can be fixed quickly. Like any good tool, it gets the job done and doesn't get in the way of doing a good job efficiently.

As much as I would like to say the same about FreeCAD, I simply can't. There is a fundamental bug in FreeCAD that upends the whole top-down parametric design methodology. I am referring to the behaviour whereby feature references are changed throughout a model when a modification is made and the changed references are not propagated and updated on child features. This seems to have been a bug since at least 2014 without being addressed as this post from 2014 shows: https://forum.freecadweb.org/viewtopic.php?t=6236 and once again raised in a post from 2018: https://forum.freecadweb.org/viewtopic.php?t=29901. I daresay I could find more if I went digging deeper.

I have spent a maddeningly frustrating week with FreeCAD trying to work around this. Several times I have had to undo hours worth of work and start over or repair existing work to get back to the point I was at.

I have done everything to relate things to master sketches only, largely successfully, but I dare not touch those master sketches beyond adjusting a driving dimension for my model for fear of breaking everything again. As I got to a point last night where I could start moving my design process forward for this project I had a realisation that I had left out something from my master sketch that turned out to be important and my heart sank. Luckily I had the feature in a child sketch further down the tree and could reference it there. If that had not been possible, I was looking at another hours work to make the change on the master sketch and re-reference all of the child geometry driven from it again just to be back where I was when I realised I needed a change. In Solidworks it might have taken 2-3 minutes to make the change and continue working.

Ultimately a task that would have taken me a few hours in Solidworks has taken about 20-30 hours in FreeCAD, and with a huge amount of stress and frustration thrown into the equation. Some would argue that Solidworks can play fast and loose with its implementation of parametric design best practice, but it largely stays out of the way and lets me get the job done quickly and satisfactorily, both vitally important when my time is costing my employer a lot of money.

I understand that part of this problem originates from the Open Cascade Core code and that having that code changed is probably beyond the scope of the FreeCAD development team. Nonetheless the FreeCAD code is within their control and I would like to propose a solution.

Starting from the reality that the underlying CAD engine is going to change feature IDs around as the model is edited and updated, FreeCAD needs to be able to capture these changes and update the model features that depend on them. The process should be something like this:
A user edits a feature (possibilities: edit existing, remove existing or add new)
This edit results in a new ID for the feature in question
It may or may not result in changed IDs for other existing features
When the user commits the change FreeCAD now has to capture 3 sets of information and map them together somehow:
Existing feature IDs prior to the edit
What those feature IDs change to as a result of the edit
What child features depend on these feature IDs
At this point the set of child features must be updated so that changes introduced by the edit are propagated throughout the model

I don't doubt that this is a serious challenge, but it is one IMO that must be met if FreeCAD is to ever be taken seriously as an engineering tool. I'm willing to offer some help for testing but my free time is limited.

A second serious bug I've encountered is unpredictable undo behaviour. Expected behaviour is that hitting undo/ctrl+z will undo the last action e.g. remove a line segment that was just added or restore a deleted dimension. In practice I've seen it undo several layers of changes in one fell swoop such as reverting changes to three sketches at once. I've lost an hour's work to this bug on more than one occasion. I'm not 100 % sure if this is version specific or not: I've used 0.18.4, 0.19-21622 and am currently using 0.19-21654, and right now I'm willing to deal with the frustration of breaking my models again to figure out where this might have crept in.

For the sake of completeness and to satisfy the curious, the project I'm using FreeCAD for is to design a trailer. I have bought a caravan chassis which has the core components I need for my trailer (braked axle and coupling with overrun brake) and a nice galvanised steel chassis. The basic idea is cut up the chassis and shorten it, reusing all of the cut off portions as a starting point for the new trailer: this involves cutting off the A-frame drawbar assembly from the front of the chassis, removing some additional material from it, and welding it onto the straight sides of the chassis at a point further back, using the remnant portions of the A-frame as cross members.

There are two key design variables which I need the model to be able to accommodate: the final length of the drawbar, and the length of the load bed. An additional constraint is the attachment point of the A-frame to the sides: it must not get in the way of the axle beam's mounting points. My master sketch is devised so that these two variables are key driving dimensions, with all other measurements deriving from them.

For a given load bed and drawbar length, the master sketch is able to tell me where to cut off the A-frame and how much to remove from it, and update the child models to represent the pieces in the 3D model. After much work, the model is finally doing this properly and letting me move on with the next steps of my design. Fingers crossed it will stay working as the design moves forward. I've attached the model file at the end.

All of this is aimed at letting me see the impact of differing load bed and drawbar dimensions on the net weight of the chassis as this will determine the payload capacity of the trailer (the axle rating is limited to 1300 kg gross and my car is limited to 80 kg tongue weight). Parametric modelling should let me measure the total amount of material used and how it changes when I change the basic dimensions of the trailer.

System specs are:
OS: Ubuntu 20.04 LTS (X-Cinnamon/cinnamon)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.21654 (Git) AppImage
Build type: Release
Branch: master
Hash: ddf0cf3136a6c5a459abae4bf1f9c714f6f45c86
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United Kingdom (en_GB)
Attachments
new_chassis_2.FCStd
(834.29 KiB) Downloaded 49 times
drmacro
Veteran
Posts: 8982
Joined: Sun Mar 02, 2014 4:35 pm

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by drmacro »

chimaera wrote: Sun Jun 21, 2020 6:51 pm
So...have you checked out this forum at all?

Your point is well taken. It has been thrashed about here over, and over, and over...many times with comments like yours starting the discussion over again. 8-)

It is not ignored and is, in fact being looked at.

And, there are those that simply learn the techniques that avoid it.

I, and many others, do iterative design. My models don't break. It's just a workflow that many have developed.

Is it annoying that you can't attach to generated geometry willy-nilly, maybe. But, in the end, the model is actually better for it.

It's always funny that people come here, understandably frustrated, and decry that FreeCAD can't be used for "serious" engineering.

While others simply do engineering with the tool and somehow work past the issues.

I know Solidworks, and many other CAD packages. Guess what, those companies have rooms full of salaried engineers.

FreeCAD has a handful of volunteers. Maybe you could volunteer to help code? ;)

Sorry if I seem blunt...but. I'm in a cranky mood and your post is taking the brunt. :oops:
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
TheMarkster
Veteran
Posts: 5513
Joined: Thu Apr 05, 2018 1:53 am

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by TheMarkster »

I think your idea of using ID's is on the right track and is what realthunder is doing in his branch to address the toplogical naming issue. I believe his work will likely make it into the 0.20 development cycle, but that is not for me to decide.
User avatar
M4x
Veteran
Posts: 1481
Joined: Sat Mar 11, 2017 9:23 am
Location: Germany

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by M4x »

We've just talked about it a few days ago. Check out this thread, I think this should answer all your questions regarding the topological naming problem: could the lack of non destructive editing be called a bug?

I'd like to quote the first answer in that thread here:
chrisb wrote: Tue Jun 16, 2020 6:12 am You are right, and it is the most serious problem of FreeCAD. The issue is widely discussed and well known as the topological naming problem.
However since version 0.17 you can model in a way that mostly prevents models from breaking: have a look at this page, especially the paragraph about creating stable models.

There is a branch from realthunder with improvements in this area. It will hopefully be integrated during the next development cycle after 0.19 is released.
User avatar
Forthman
Veteran
Posts: 2668
Joined: Fri Apr 27, 2018 11:23 am
Location: Tarn-et-Garonne (82)

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by Forthman »

my father said "there are no bad tools, there are only bad workers" :roll:
chrisb
Veteran
Posts: 54197
Joined: Tue Mar 17, 2015 9:14 am

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by chrisb »

I appreciate that you accompany your criticism with a constructive proposal. You are right that the problem is known since many years. And it is very well known here, so you could have made that part shorter.
Instead I would have liked to see your proposal more elaborated. The problem is: FreeCAD sees some IDs before and some IDs after a change. While it is very easy for a human to decide what is the same as before it can be extremely difficult for a computer. Imagine a simple cube and from one state to the next you have slightly changed the dimensions and you have slightly turned it. Imagine further that you get completely different IDs, so the real problem is to find the mapping from old to new IDs.

Or imagine a cube and you see some IDs. You turn the cube by 90° and you see a completely different set of IDs. How can you determine the mapping of the IDs from before and after.
Of course it is possible, but in many cases it would mean to rebuild the whole geometric kernel, which is currently out of discussion.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by vocx »

chimaera wrote: Sun Jun 21, 2020 6:51 pm ...
For the sake of completeness and to satisfy the curious, the project I'm using FreeCAD for is to design a trailer.
I didn't read the entire rant, but I feel a very similar post was posted recently. Maybe my memory betrays me. (could the lack of non destructive editing be called a bug?)

Anyway, I just picked this up, and remembered two threads about designing mechanical components for cars.
* Trailer Deck
* Pickup camper build

The topological naming problem is well known, but until a real solution is provided in the source code, people have to manage. It's not that hard but you need more than a week of experience with the software.

V0.19 Benchmarking--Intermediate Level Tutorials
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
chrisb
Veteran
Posts: 54197
Joined: Tue Mar 17, 2015 9:14 am

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by chrisb »

vocx wrote: Mon Jun 22, 2020 12:22 am I didn't read the entire rant,
You should read it before calling it a rant. It's different from many previous rants in so far as it contains a proposal for improvement.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
tonyaimer
Posts: 242
Joined: Mon Sep 30, 2019 4:17 pm

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by tonyaimer »

I would like to throw in my 2c worth on what is a difficult issue.

As a beginner I am aware of the topological naming issue ( TNI issue ) and the need to use
datums which are offset from the global X Y and Z axes instead of sketching on a face.

I am more than willing to adopt work processes that may differ from Solidworks or other
high end CAD products because of the 'free' in FreeCAD. I am not prepared to pay a monthly
subscription or work in the cloud for what is essentially for me a hobby tool.

I have one question about which I am a bit confused. Is the TNI a function of the graphics
engine underlying FreeCAD, or an issue the FreeCAD developers can actually address?

The developers have stated somewhere that FreeCAD is not yet ready to start a version number
series of 1.0 as a result of their concerns about not being quite up to the level of commercial
software just YET. I have emphasised 'yet' because the program is improving all the time and
I do hope we will not reach 0.99 down the road.

Put another way it is unfair to compare the commercial packages like solidworks, catia or
adesk inventor with Freecad as it is serving a very different purpose.

I am 100% on board with the development goals and hope to be able to contribute something
in due course.

Regards


Tony Aimer
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: FreeCAD Is Fundamentally Broken: Topological Naming Inconsistency Problems

Post by GeneFC »

tonyaimer wrote: Mon Jun 22, 2020 8:56 am
I have one question about which I am a bit confused. Is the TNI a function of the graphics
engine underlying FreeCAD, or an issue the FreeCAD developers can actually address?

Actually this very question was addressed on the forum a couple of years ago by both a long-time FreeCAD expert and one of the OCC experts. It was agreed that the bulk of the problem needed to be addressed in FreeCAD. It is certainly possible that some of the behavior of the OCC kernel could make the job more difficult, but that same kernel is used in OCC commercial products that have much less problem with TNI.

The key issue is that it is a very complex problem to solve. Realthunder (especially) and others have spent a lot of time working on improvements. Stay tuned.

Gene
Post Reply