Odd behavior when attempting PartDesign Boolean

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!
Post Reply
cme_linux
Posts: 5
Joined: Mon Jul 22, 2019 11:52 pm

Odd behavior when attempting PartDesign Boolean

Post by cme_linux »

Hello,

In a particular .FCStd file (URL below), I have the following problem:
  1. I have a PartDesign Body called MiterPieceA_LH. I double-click this in the project tree to make the Body active (bold).
  2. I have another Body called GPO_MPA_LH, which is a clone of a Body called GluingPocket. I click GPO_MPA_LH in the project tree to select GPO_MPA_LH (the background of the name in the project tree turns dark). GluingPocket is in the middle of the list of project-tree items, and GPO_MPA_LH is at the very bottom.
  3. In the PartDesign workbench, I click the Boolean button so I can do a Cut (removing GPO_MPA_LH from MiterPieceA_LH).
  4. Odd things happen:
    1. In the Tasks pane, both GluingPocket and GPO_MPA_LH are listed, even though I had only selected GPO_MPA_LH.
    2. When I click Cancel in the Tasks pane, now the project tree shows GluingPocket as being right above GPO_MPA_LH.
    3. In the project tree, several items are shown as needing to be recomputed (dark-blue icon superimposed on each object icon).
I have done a few PartDesign Boolean operations in this project file, and I don't remember (a), (b), or (c) happening before.

I confess that I've used Tools > Project Utility... several times to re-sequence items manually in the project tree (by moving blocks of text in the Document.xml file). It seemed like that didn't cause any issues until the current problem; I don't know if the current problem is related to my manual changes to the project file.

The .FCStd file was too big to upload to this forum, so I put the file on a file-sharing service:

http://www.mediafire.com/file/rw15sec4a ... FCStd/file

I suppose something needs to be corrected about the internal structure of this file?

I'm troubleshooting a problem in which several clones (the descendants of MiterPieceA_LH) were at unexpected locations. My experimenting with different Placement values, and with clone hierarchy, has put some of these clones in disarray, so if you make many of them visible, the 3D view will look weird. :roll:

Hopefully someone can provide some constructive feedback about my situation.

OS: Linux Mint 18.3 Sylvia
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.1.
Build type: Release
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)
Sincerely,
cme_linux
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Odd behavior when attempting PartDesign Boolean

Post by chrisb »

Hi and welcome to the forum!

If you make a recompute of the whole model you see in report view several messages "Links go out of the allowed scope". I would guess that these are the source of your issues.

Usually I would have a look at the dependency graph; alas, in this case it fails to produce an image - which might have been difficult to read anyway due to its enormeous size.
If it works on your side the offending references should show with red arrows. With your better understanding of your own model you may be able to fix these issues without the dependency graph. They occur on two occasions:

1. You refer in a Part boolean operation some internal feature of a body. Fix: use the whole body instead.
2. the other way: you reference something e.g. with external reference which is not inside of a body. This can happen if you drag and drop a sketch outside of a body, or - as you describe - if you tinker in the internals of the model tree.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
cme_linux
Posts: 5
Joined: Mon Jul 22, 2019 11:52 pm

Re: Odd behavior when attempting PartDesign Boolean

Post by cme_linux »

Thank you so much for your reply, chrisb.
To answer some of your points:
  1. The "links go out of the allowed scope" messages have been happening since early in the development of this file, and Booleans have worked all right during that time. These messages might be because MPA_RH_Base, which is a Mirror from the Part workbench, is based on PartDesign feature MPA_LH_GlueLineAtNonMiteredEnd instead of the Part (MiterPieceA_LH) that contains that feature.

    To prevent these warning messages, I would clone MiterPieceA_LH at step MPA_LH_GlueLineAtNonMiteredEnd and manually repeat the 2 subsequent PartDesign steps on the clone, deleting them from MiterPieceA_LH. Then I would base MPA_RH_Base on (probably renamed) MiterPieceA_LH, and the several things that are now based on (the tip of) MiterPieceA_LH I would base on the clone (which I may rename to "MiterPieceA_LH").

    I think that structuring the project that way would be against PartDesign's objective of making the model tree less "bushy." But I can try it.

    Ironically:
    • MPA_RH_Base (the thing that seems to be "going out of the allowed scope") is the basis of a Part called "MiterPieceA_RH", which consists entirely of 2 Booleans, which don't have any problems.
    • The descendants of MiterPieceA_RH also don't have the mysterious wrong-placement problem (a different issue than the odd Boolean behavior) that the direct descendants of MiterPieceA_LH do.
  2. When I choose Tools > Dependency graph... I, like you, get a popup that says, "Graphviz failed to produce an image file".
  3. The two Booleans I know of that could be influencing the one that has the "odd behavior" are MPA_LH_GPR and the "odd behavior" Boolean itself, which are based only on PartDesign Part objects, not on features within those objects.
Sincerely,
cme_linux
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Odd behavior when attempting PartDesign Boolean

Post by chrisb »

I don't understand your rather complex model very well, but some general remarks may be helpful.

- I have seen very few cases where you really need booleans in PartDesign. Instead of using Union you can just add the features and instead of cutting you can subtract them.
- I can see no advantage in having a body with only a clone as base feature and nothing else in it. Use the clone directly.
- Instead of repeating the construction of almost identical objects consider using a clone instead (MntgPlate_CutPath vs. Faceplate_CutPath)
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
cme_linux
Posts: 5
Joined: Mon Jul 22, 2019 11:52 pm

Re: Odd behavior when attempting PartDesign Boolean

Post by cme_linux »

Hi chrisb, I'm grateful to have some discussion of this 3D model with an expert :ugeek: like yourself, so I can learn FreeCAD better. Thank you for taking the time to look through my design & offer some ideas.
  1. About booleans in PartDesign. In general, I agree that the additive section of the toolbar (Pad, Sweep, Additive Primitive, etc.) seems meant to replace Boolean Union/Fuse in most cases, and the subtractive section (Pocket, Subtractive Sweep, etc.) seems meant to replace Boolean Cut in most cases.

    About my design specifically, I gather you're referring to GluingProng (which I abbreviate GPR) & GluingPocket (which I abbreviate GPO). My thinking was: These 2 features each consist of 2 Pads - I might call GPR & GPO "compound features." The number of places where these 2 features need to be added into another component (prior to cloning of the whole component that includes these features) is about half a dozen. Every one of those places should get identical copies of these 2 "compound features," and GPR & GPO are one of the details that's most likely to change during prototyping, since they are one of the few things in this FreeCAD design that actually does anything. :lol: So I wanted to have a "master" instance of each, which is then duplicated by cloning into every place where that compound feature is used, so that a change in the master instance is automatically reflected everywhere else in the model.

    The alternative to my current approach seems to be: For every instance X[ i ] of a part "X" that these compound features are supposed to be on, I should add the 2 pads (or 2 pockets in the case of GPO) separately. It's not clear to me how this would provide just a single instance that I could add design-updates to, that would be copied automatically to all X[ i ] in the model. Maybe I could clone the sketches that are the basis of the pads & pockets, but this seems like more setup work, since I'd have to clone the sketches (which I might abbreviate as SGPR1, SGPR2, SGPO1, SGPO2) by hand for every X[ i ]. Also, the geometric relationship between, e.g., SGPR1 & SGPR2 is an important design detail that would have to be duplicated by hand for every X[ i ].
  2. Aha, in response to your suggestion, I tried making a Draft clone of one of my 3D objects, and it works. :o I had thought Draft was for 2D objects only, so I had been using PartDesign Clone, which makes "a body with only a clone as base feature and nothing else in it."
  3. You are right that MntgPlate and Faceplate are currently identical (as are their CutPaths). I plan to put a future version of this design onto the Web so that others can modify it for their own needs. Faceplate needs to be made of a clear material, but MntgPlate does not. If a user wants MntgPlate to be a different material than Faceplate, then both the material thickness & the kerf width may be different between the 2 objects. (Different materials might need different equipment for CNC-cutting - currently I expect Faceplate will be acrylic, which can be laser-cut, but MntgPlate could be rigid PVC, for instance, which is hazardous to laser-cut.) Once the kerf width is different, then the CutPaths are different.

    Also, in prototyping, I may find a reason that Faceplate & MntgPlate should be different sizes.
My plan is now to try to remove the "links go out of allowed scope" as mentioned, as well as replacing PartDesign Clones with Draft Clones, which may help with the "unexpected locations of the descendants of MiterPieceA_LH" problem.
Sincerely,
cme_linux
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Odd behavior when attempting PartDesign Boolean

Post by chrisb »

In this case it seems reasonable to reuse a whole body.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
cme_linux
Posts: 5
Joined: Mon Jul 22, 2019 11:52 pm

Re: Odd behavior when attempting PartDesign Boolean

Post by cme_linux »

1. Yes, the problem seems to have been solved by chrisb's suggestion.

To summarize:

The biggest problem I noticed, and that has been solved, is that some clones of an object were at unexpected coordinates.

As chrisb suggested, this seems to have been caused by operations (such as Booleans from the Part workbench) referring to one of the modification steps within a PartDesign Body, rather than referring to the Body. (Referring to the Body will do the operation on whatever modification step of the Body is currently set to be the tip of the Body.)

The problem isn't one that would be expected to follow from the cause, but I believe "unexpected results" are indicated by the wiki page that says that you shouldn't refer to the modification steps within a PartDesign Body.

Thank you very much @chrisb.

2. Now that this issue has been solved, I'm removing the .FCStd file from where I uploaded it to. That file was a work-in-progress (obviously, since I had to ask for help with it). My own copy has been improved since the version that I uploaded. The uploaded version is not approved for distribution or modification; except for: this troubleshooting, and if any developer wants to get ideas from the file about how to improve FreeCAD.

This applies retroactively to anyone who has already downloaded the file. This is reasonable since the context was obviously just to troubleshoot the few issues stated, not to release the file to the world as a product. If you think I'm not allowed to specify retroactivity, then the file needs to be distributed in copyleft fashion, keeping the source code (such as .FCStd as opposed to .STL) available and crediting that your version of the file was modified from a work by "cme_linux".

Yes, the file was in turn modified by me from a work by "kisolre". Only very few concepts from that original work are used in my version. And I did think of all these things when first creating this forum topic, but didn't bother to mention them because:

...Since the uploaded file was full of bugs, you shouldn't use it anyway; and I hope to release an improved version of it in the future under some open-source license.

Thank you for your understanding & courtesy.
Sincerely,
cme_linux
cme_linux
Posts: 5
Joined: Mon Jul 22, 2019 11:52 pm

[SOLVED] Re: Odd behavior when attempting PartDesign Boolean

Post by cme_linux »

I don't know how to add [SOLVED] to the subject line of the whole forum topic, so I'll do it just to this one reply.
Sincerely,
cme_linux
kisolre
Veteran
Posts: 4164
Joined: Wed Nov 21, 2018 1:13 pm

Re: [SOLVED] Re: Odd behavior when attempting PartDesign Boolean

Post by kisolre »

cme_linux wrote: Sun Oct 06, 2019 9:29 pm I don't know how to add [SOLVED] to the subject line of the whole forum topic, so I'll do it just to this one reply.
You can edit your posts (first gray icon on the right of posts title) and doing so you can also change the subject. Just edit the subject of the first post.
Post Reply