Help: Pad: Result has multiple solids

[insomniux]

OS: Debian GNU/Linux 10 (buster) (KDE//usr/share/xsessions/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.17499 (Git) AppImage
Build type: Release
Branch: master
Hash: 6b1be38f35686faf21e1015bf562520929890870
Python version: 3.7.3
Qt version: 5.9.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedStates (en_US)

I'm working on an enclosure for a development board and harddisk, to be 3D-printed. It's going to be modular so you can choose to add a harddisk, fan or other elements. In the past I've designed other objects with FreeCAD using sketching and the part-workbench only as the part-design workflow has been somewhat obscure to me. For this design I decided to go for the 'recommended' route, using the part-design workflow. However I get stuck after just one or two steps. To make sure all modular elements are in sync I'm using a MasterSketch on which all bodies will be based.

At this stage I've made a 'bottom plate' and I'm on to creating the outer wall by padding a sketch which is based on the surface of the bottom plate. So I'm trying to pad the outer wall (sketch5, connected to Face5 of Pad02) on a bottom-plate.

Case-image-001.png (68.28 KiB) Viewed 3330 times

Olinuxino-Lime2-modular-case-v001.FCStd

(110.79 KiB) Downloaded 26 times

When I pad Sketch5, I get the error

Code: Select all

Pad: Result has multiple solids...

I can pad the image in the Part-workbench indicating that the Sketch is valid for padding.
What am I doing wrong?
Thanks for your advice.
Mike

[Willem]

Delete the holes in this sketch and it will pad. Make a separate sketch for the holes to pocket them

[insomniux]

Thanks Willem, that indeed enabled me to pad the sketch. Is this a bug or is it desired behaviour.

By the way, the object now turned black, I assume that is because of the OCCT bug described earlier.

Is it a better approach, in this case, to make a solid box and create the inside as a pocket?

[vocx]

Thanks Willem, that indeed enabled me to pad the sketch. Is this a bug or is it desired behaviour.
...

PartDesign Body requires a single continuous solid. There cannot be disconnected solids in the same body.

[chrisb]

Your Sketch005 pads without problems here and I see no reason why id should not. This seems to be a bug in 0.18. Please retry with a current 0.19, it contains less errors - and more features (program features, not PartDesign features).

[chrisb]

PartDesign Body requires a single continuous solid. There cannot be disconnected solids in the same body.

The single solid concept seems not to be the issue here. If I make a full recompute of the whole document the sketch shows errors. If I recompute just the sketch they are not shown.

[chrisb]

Did you use a 0.17 version to build this? Please attach your FreeCAD infos here. A full recompute shows the same errors in 0.19. I have to delete all references to external geometry and rebuild them.

Or perhaps you have hit the topological naming problem by some changes to previous objects, e.g. to the master sketch.

[chrisb]

Giving a closer look, I suspect some issues with silently removed constraints. I have rebuilt the constraints to connect to external geometry and now the file can be recomputed, and Sketch005 can be padded. Please give it a try.

[insomniux]

Thanks Chris, the modified version does pad the sketch5. What exactly should I do to avoid this kind of problems?

I'm using version 0.19.17499 AppImage.

[chrisb]

Abdullah, you asked if there is something which has to be done in the 0.19 cycle. I think this is one of them. We had similar things before, I will look if a ticket exists
It concerns silently removed redundancies. If I take the original model above, and open Sketch005 I can remove the vertical constraints 53 and 21, and the sketch is still fully constrained.
If I close the sketch and make a full recompute, then redundacies are shown, and if I remove e.g. the proposed redundant constraint 27 the sketch even becomes unsolved.

I don't think anymore that this is due to topologiacal naming, because I had removed and rebuilt all constraints referencing external geometry and then it works, even surviving flawlessly a full recompute.

ping