PartDesign: setting Tip property leads to incompletely featured body

[uwestoehr]

Setting the Tip property in the Part Design WB can lead to a incomplete body:

- open this simple FC file:

Tip-setting-problem-original.FCStd

(22.97 KiB) Downloaded 30 times

It is a body with 3 features. The Tip is currently at the feature "Pad".

- now save a copy of the file
- in the original file, select the body in the model tree and change in the Data tab of the combo view the Tip to "Pocket"
- in the copy file, select the feature "Pocket", right-click on it and select "Set tip"

as result both files should be in the same state. But this is not the case. To see the difference, select the body in the model tree and create a mesh of it using the Mesh WB. You can see that only in the file where you used the "Set tip" method", the mesh contains all features - including the pocket. Alternatively you can import both files to an assembly using the A2plus WB. The reason is that the method of setting the Tip via the properties did not really lead to a changed tip.

This is an annoying bug since it cost me an hour to find out why my files look incorrect in meshes and assemblies.

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15860 (Git)
Build type: Release
Branch: master
Hash: 3b708c7f84b0425076b520e1d95627b20fd75fe0
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: German/Germany (de_DE)

[chrisb]

If I follow your advice by setting the Tip in the data tab it works exactly the same as in the other case. Here is an image of the mesh of the non-copy version:

Bildschirmfoto 2019-02-20 um 00.56.45.png (16.17 KiB) Viewed 1285 times

You probably were mislead by not making the last feature visible, or you used a feature instead of the body, or did not perform a recompute, when the model reqested it.

OS: Ubuntu 16.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15860 (Git)
Build type: Release
Branch: master
Hash: 3b708c7f84b0425076b520e1d95627b20fd75fe0
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

This is an annoying bug since it cost me an hour to find out why my files look incorrect in meshes and assemblies.

I appreciate it, if new users come with a fresh look, and help improving FreeCAD. But I would appreciate it very much if you would work through some (more) tutorials and create some (more) models to learn more about FreeCAD and how to use it for modeling.

Of course it is a pity that you lost one hour. But see it from the other side. That's only one hour for one person, while a report of a non existing bug costs many more people considerable time.
Read the post, replay the example, boot another OS, replay again, try to understand what you did, where your mistake might be, create a (non native language) answer: it costs 10 to 15 minutes. And probably not for me, but for others as well. Probably not quie as much, because they give up earlier, but it's time lost anyway. So if ten of the forum regulars try to handle your so called error report there is more time lost than one hour.

[uwestoehr]

You probably were mislead by not making the last feature visible, or you used a feature instead of the body, or did not perform a recompute, when the model reqested it.

The bug persists here. I made correctly the last feature visible and I also performed recomputation even if it was not requested by FC. Before I posted here I also asked the A2plus author and he told me it is no bug in A2plus but in FC since with the Data tab method the Tip property is obviously not correctly set and A2plus imports only features until the tip.

I appreciate it, if new users come with a fresh look, and help improving FreeCAD. But I would appreciate it very much if you would work through some (more) tutorials and create some (more) models to learn more about FreeCAD and how to use it for modeling.

Well, I did already a lot, I wrote the A2plus manual: https://www.freecadweb.org/wiki/A2plus_Workbench , I reported about 20 bugs and about 15 are now already fixed. Furthermore I used FC intensively to produce real-life objects successfully. So I think I am not reporting nonsense. And of course I google around before I ask here for help.

[uwestoehr]

From another thread:

Did you forget the recompute? It is not performed automatically on my Linux version while it is on MacOS.

Ah, this is the problem: With the Data property method FC requests no recompuation and does not invoke it automatically. One has to mark the body to be recomputed after one changed the Tip property in the Data tab.

I reported this now as issue #3850 since FC should trigger the recomputation since it is necessary.

[chrisb]

Perhaps another Windows user can confrm, although I would think it is independent from the OS.

[GeneFC]

This has been discussed numerous times. Auto recompute is sometimes a big time waster.

I tried your file and found the following. I opened the file, selected the body, changed the tip from Pad to Pocket.

Immediately the model tree showed the need to recompute. It did not do an automatic recompute, but that is a feature, not a bug.

Capture.PNG (4.86 KiB) Viewed 1272 times

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15860 (Git)
Build type: Release
Branch: master
Hash: 3b708c7f84b0425076b520e1d95627b20fd75fe0
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

Gene

[uwestoehr]

Immediately the model tree showed the need to recompute.

That would be fine with me but here it does not show the need to recompute.

[uwestoehr]

Immediately the model tree showed the need to recompute.

That would be fine with me but here it does not show the need to recompute.

I updated to the latest available Win build 0.18938 and now I correctly get the mark from FC that the body must be recomputed. I tested this now on 2 different PCs. So the issue is fixed for me now.