Method of deleting bodies that DOES NOT create parent features? "Cut this area regardless of which bodies are there"?

[DadoNoah]

TL;DR: I'm looking for a way to make a feature that deletes all bodies in a certain area (like Extruded Cut or Delete/Keep Body) WITHOUT creating a parent-child relationship with those features, such that the body-deleting feature will stay unsuppressed as features above it are suppressed and unsuppressed.

Full version:

I have a part that consists of multiple bodies and can be in its basic configuration ("O"), or it can have either or both of two sets of optional features ("A", "B", and "A+B"). Feature sets "A" and "B" (each in their own folder for easy suppressing and unsuppressing) each adds several new bodies to the list, while also changing the names of some existing bodies from basic configuration "O".
In addition to these feature configurations, these bodies are also mirrored about the right plane, and the part is intended to be configurable to include just the left-hand bodies ("LH"), just the right-hand bodies ("RH"), or both ("L+R"). My goal is to create two body-deleting features--one to delete the left-hand bodies and isolate the right, and the other vise-versa--so that I can switch between “LH”, “RH”, and "L+R" just by suppressing/unsuppressing each of these two features as needed. The problem, though, is that I'm finding that body-deleting features (including Delete/Keep Body and Extruded Cut) will automatically establish a parent-child relationship with the features/bodies they affect, such that as soon as one of those features is suppressed, the body-deletion feature is suppressed as well.

Here's an example of what that looks like: Say I'm in configuration "O/L+R", and I want to get it to “O/RH” by deleting the left-hand bodies: I'll sketch a rectangle on the Right Plane that encompasses the whole part, then use it to create an Extruded Cut pointing left, checking "all bodies" under Feature Scope. Now the left-hand bodies are gone and we're in configuration “O/RH”, and when I highlight the new Cut feature to see its parents, it points exclusively to the "O" features. Now I want to switch from “O/RH” to “A/RH”, so I unsuppress the "A" folder, and voila. The Cut still works, deleting all left-hand bodies old and new. So far so good. At this point, highlighting the Cut again shows that it has parents not only from the original "O" features, but also from the "A" features folder. Now, if I want to go back to “O/RH”, I just re-suppress folder "A", right? NOPE, the Cut has fully (autonomously) latched onto the "A" features as parents, so when I re-suppress folder "A", the cut is suppressed too. Where I wanted to see “O/RH”, I'm left with "O/L+R", and if I try to unsuppress the “RH” cut, it brings the "A" features with it.

Is there any way to make a body-deletion feature that doesn't automatically establish those parent-child relationships? It seems like such a simple function: I want to cut away all bodies in the path of an extruded cut, regardless of which preceding features they came from or how they might change; in other words, every time the part is rebuilt, I want the cut to behave as if I'd just made the feature and checked "all bodies" for the first time. Any help is much appreciated!

[matt]

TL;DR: I'm looking for a way to make a feature that deletes all bodies in a certain area (like Extruded Cut or Delete/Keep Body) WITHOUT creating a parent-child relationship with those features, such that the body-deleting feature will stay unsuppressed as features above it are suppressed and unsuppressed.

The only way I can think of doing that is to have the data import such that each body is a feature in the tree, and then you can delete the feature in the tree. If you delete a body in a body folder, you'll add features in the tree. If you use an extrude or a sketch you'll add features to the tree. (only read the tl;dr)

[bnemec]

I hate that SW forcefully suppresses dependent features; I think that's in the Mavric style TTL here at CADforum.net.

Anyway, have you considered using Boolean feature Combine/subtract instead of a cut feature? Ie. extrude the body as a solid "tool body" I don't think they are dependent on the previous bodies/features so they aren't suppressed.

Edit: Never mind, it appears that SW allows cutting only one body at a time, can have multiple tool bodies but only one target body. In Solid Edge you can "Subtract" one or more tool bodies from one or more target bodies.

[DadoNoah]

I hate that SW forcefully suppresses dependent features; I think that's in the Mavric style TTL here at CADforum.net.

Anyway, have you considered using Boolean feature Combine/subtract instead of a cut feature? Ie. extrude the body as a solid "tool body" I don't think they are dependent on the previous bodies/features so they aren't suppressed.

Unfortunately it looks like that also requires selecting bodies, so it also creates those pesky parent/child relationships. Though admittedly I don't use the Combine feature often enough to be sure I'm doing it how you meant me to-- I'm open to keep trying it if you have any more pointers!

[bnemec]

Unfortunately it looks like that also requires selecting bodies, so it also creates those pesky parent/child relationships. Though admittedly I don't use the Combine feature often enough to be sure I'm doing it how you meant me to-- I'm open to keep trying it if you have any more pointers!

I think you have it. I don't use boolean modeling methods frequently, but when needed they really open the door to simpler and robust models, at least when I implemented that in Solid Edge. I just tried it in SW and when the target body is suppressed the boolean feature "Combine" is also suppressed. Then I went to SE and tried the same and the boolean feature just fails but is fine once the target body is unsuppressed, unlike SW where it remains suppressed. Here's the difference in SE, when there are multiple target bodies and only one is suppressed the boolean feature marches on just fine. SW does not support selecting multiple target bodies.

Sounds like Matt's idea is the winner.

[DadoNoah]

The only way I can think of doing that is to have the data import such that each body is a feature in the tree, and then you can delete the feature in the tree. If you delete a body in a body folder, you'll add features in the tree. If you use an extrude or a sketch you'll add features to the tree. (only read the tl;dr)

I'm not sure I understand. How would deleting the feature from the tree help? The goal is to have the smallest possible number of features that I need to suppress and unsuppress to get the configurations I need, so as to make my workflow less tedious. If I deleted a body/feature entirely to get rid of it, then to make it reappear I would have to import the body and constrain it all over again, which would be even more tedious than my current tedious solution, which is to have 6 different cuts targeting different bodies.

[matt]

I'm not sure I understand. How would deleting the feature from the tree help? The goal is to have the smallest possible number of features that I need to suppress and unsuppress to get the configurations I need, so as to make my workflow less tedious. If I deleted a body/feature entirely to get rid of it, then to make it reappear I would have to import the body and constrain it all over again, which would be even more tedious than my current tedious solution, which is to have 6 different cuts targeting different bodies.

You're going to spend more time and energy trying to figure out how to push the software to do something it probably won't do than you would just doing it. And you're asking people to do it for you who usually get paid to solve problems like this.

I think the restrictions you're putting on a solution are probably unrealistic. Of course, I haven't read all of your long post. If you want to delete bodies, but have the ability to get them back, Delete Bodies is the only feature or function in the interface that does that. But you want to do it without a feature, which you might do through the API. Every restriction you put on the solution complicates it another level.

[DadoNoah]

You're going to spend more time and energy trying to figure out how to push the software to do something it probably won't do than you would just doing it. And you're asking people to do it for you who usually get paid to solve problems like this.

I think the restrictions you're putting on a solution are probably unrealistic. Of course, I haven't read all of your long post. If you want to delete bodies, but have the ability to get them back, Delete Bodies is the only feature or function in the interface that does that. But you want to do it without a feature, which you might do through the API. Every restriction you put on the solution complicates it another level.

I think we might be having two different conversations-- I really don't think the restrictions I'm putting on the solution are all that unrealistic. If there are 20 bodies in the path of an extruded cut and I select "All Bodies," it cuts all 20 bodies. All I want is for the cut to still work if there are 21 bodies in the path, but I'm finding that "All Bodies" functions exactly like "Selected Bodies" in that circumstance. My only option is to have a separate cut for every possible set of bodies that could be in its path, and painstakingly suppress and unsuppress all of them, which makes my part more and more error-prone the more configurations I have. And to be clear, I'm not just sitting here idling-- I've already done the annoying brute-force solution I just described, but I'm hoping to learn of something better so I can improve my model and make it a more robust design.

(I'm also not sure of your point about how I'm "asking people to do it for me who usually get paid to solve problems like this"... I'm not asking anyone to do anything beyond answer my question about whether there's a SolidWorks feature that does what I've described. Are you asking me to pay you? Or are you saying the SolidWorks forums on cadforum.net are the wrong place to go with questions about SolidWorks?)

EDIT: Sorry, I've been having a crappy morning, didn't mean to sound so abrasive. I do appreciate any advice you're willing to provide.

[SPerman]

I'm finding that "All Bodies" functions exactly like "Selected Bodies" in that circumstance.

I've found that to be true in several places in SW. "All Bodies" just means all bodies available at the time of the feature creation. It does not keep up if other bodies are added. (Convert entities behaves similarly.)

[Austin Schukar]

The only feasible route - I hope someone can correct me - to avoid creating parent/child dependencies is to create new bodies via a macro feature (or import, like Matt said). This macro feature could theoretically check a sketch, find all bodies that fall within its bounds, and remake them via API. The macro feature could perform Delete/Keep bodies on the new bodies created within that feature, and that's all the dependencies that would be created.

I'm sure that there are obvious issues with this approach - first one that comes to mind is actually creating the macro feature. However, it would rebuild dynamically, and can be configured such that a normal feature would, without creating dependencies to the original bodies.

https://www.codestack.net/solidworks-ap ... o-feature/

[zxys001]

Other than Combine maybe also consider using Intersect?

[mattpeneguy]

Other than Combine maybe also consider using Intersect?

Yep, Interesect is a swiss army knife. Combine is a simpler, but less versatile tool.

[DadoNoah]

Other than Combine maybe also consider using Intersect?

Would you mind clarifying how the intersect tool can help me? I've been playing around with it, but it seems to be giving me the same parent/child issues as the other features I've tried.

[zxys001]

Would you mind clarifying how the intersect tool can help me? I've been playing around with it, but it seems to be giving me the same parent/child issues as the other features I've tried.

Hello DadoNoah,... so, I read back on the thread and yeah, no,.. this will still create parent/child relations. (bcuz, SW is a relational modeler in general).

As everyone else,.. if you don't want parent/child relations.. once you make changes,.. save the bodies as parasolid (native) and continue the cycle of export/import dumb bodies.
, ..and as Austin Schukar suggest, maybe a quick macro to scrub all relations and see only bodies in the feature tree?

[DanPihlaja]

...

Question, are you removing entire bodies? Or removing portions of bodies?

If the former, then you might get some versatility out of the delete bodies command, but instead using the "keep bodies" button.

This way, you can select all the bodies you want to KEEP and it will delete all other bodies regardless of how many are added before the step.

Then you can create configurations in which you suppress the keep bodies and replace it with a new one.

[berg_lauritz]

Question, are you removing entire bodies? Or removing portions of bodies?

If the former, then you might get some versatility out of the delete bodies command, but instead using the "keep bodies" button.

This way, you can select all the bodies you want to KEEP and it will delete all other bodies regardless of how many are added before the step.
image.png

Then you can create configurations in which you suppress the keep bodies and replace it with a new one.

Combine this with split. I think that's one of your most stable choices here. You can always put it at the VERY end of the feature tree for each split & suppress/unsuppress as you need it for the cfgs.

This will not prevent awkward things from happening (i.e. if you add a body etc.). But it's IMHO the most stable option.


Also make sure you use keep bodies - otherwise every body you add will automatically be in every single cfg, @DadoNoah .

[berg_lauritz]

example here:

split example.SLDPRT

(190.7 KiB) Downloaded 96 times

I did this back at my old company for different sheet sizes.