Due to the sheer number of posts on this subject, here's a handy guide to all of them.
#1 - Associative Copy/I-DEAS Baseline
#2 - Derive Component Part
#3 - Top-Down Design
#4 - Blocks
#5 - Design Library
#6 - Assembly Cut
#7 - Part Configurations
For the most part, terminology between I-DEAS and SolidWorks is really close. Either the terms are exactly the same, or they are close enough to figure out without too much trouble. For some reason, this one really bothers me, but honestly I can't come up with a good reason why. So I'm just going to be nitpicky about it.
The topic for today's part-to-part relationship study is called "Top-Down" design in SolidWorks terminology. Top-Down design, to me, refers to a method of constructing the hierarchy (BOM), an alternative to Bottom-Up design. Basically, if you start with parts, and gradually build your assemblies - starting with lower level subassemblies - you are doing Bottom-Up design. If you don't have any parts, and start by creating empty assemblies instead, that is Top-Down design. It's more of a project manager function than a designer function. I'm going to start with a Car assembly, and then it will need a Chassis subassy, an Engine subassy, some Wheel assemblies, etc. Here, Mr. Designer, take this empty Wheel assy and put some parts in it.
In reality, it is very hard to be strict about one way or the other, so the end result is usually some sort of hybrid. I taught these methods for years in I-DEAS, and as far as I can tell SolidWorks can do both methods in a similar fashion. But SolidWorks doesn't call it Top-Down design. I'm not entirely sure I have an I-DEAS term for what I'm about to show, but I think the most logical term would be "In-Context" assembly design. I'm referencing other parts in my assembly to make a new part; that is in-context design. But enough nitpicking, let's begin.
Before going too far, I should point out that as I have practiced this method, I've managed to do something horribly wrong several times. The end result was basically a broken connection between the target and source parts. I don't think I was doing anything wrong, per se, and I think I know how to avoid it, but if I'm correct it is subtle enough to be really irritating and has me nervous about recommending the method to coworkers. I'll point it out in just a moment.
If it can be called a mistake, I think I was making it right here. As far as I can tell, SAVE THE ASSEMBLY BEFORE PROCEEDING. During practice, when I saved right here it worked just fine. I think the occurrences of broken relationships happened when I saved later, after the new part/relationship was created. I'm not sure if I want to be right or wrong about this. If I'm right, then this is a stupid, stupid, stupid behavior for the software to have. When I save should not have any bearing on the success of the relationship. However, if I'm wrong, then I was breaking it for other reasons that I haven't figured out yet, and that makes me nervous.
So, I'm saving this assembly RIGHT NOW as "context_topdown".
I want to create a new part, so I will do so by inserting a component, then choosing new part.
It's not a topic I really want to get into now, but SolidWorks has this interesting capability of storing parts within the assembly file. In other words, there is no separate part file. I will cover this more in-depth at a later time, because I can see a lot of potential for it. At this point however, it is simply worth noting that the part I have created is internal to the assembly.
The [ blah ] indicates that it is internal to this assembly. I'll rename it:
And now I'll save it to an external file:
Here we encounter some curious UI. I'm presented with a customized Save As dialog box:
First of all, hitting the OK button does nothing. Bad UI! Bad! Disable non-functional buttons! No biscuit! The box directs me to select a path. That's funny, I thought I was working with parts, not paths, but I'll play along. The three grayed out buttons are something of a clue that some context is needed, so I'll select the part. At this point, the "Same As Assembly" and "Specify Path" buttons light up. In this case, I would like the target part to be in the same place as the assembly, so I'll hit that button. When I do, the "Internal To Assembly" button lights up.
Now let's think about this for a minute. I arrived at this form by choosing an option called "Save Part (in EXTERNAL FILE)". Why would I go to that form, and then choose to save it internal to the assembly? If I arrived at the form accidentally, that's what the Cancel button is for, right? Seriously, what is the difference between the Cancel button and Internal To Assembly? The end result is the same, so I don't need 2 buttons.
This should be a standard Windows Save As dialog box, perhaps with a handy "Same As Assembly" button added. No biscuit!
Note the lack of [ ]'s, indicating that this is now an external part. At this point, what we have is essentially the same as an Empty Part in I-DEAS. The default planes are there, but otherwise no geometry yet.
Because assemblies can own geometry for themselves, you have to specify if you want to work on individual parts. I would like to work on my new part, so I first select it, and then choose to Edit Component.
SolidWorks makes the other items in the assembly translucent, which is a nice touch. The line items for the current component are changed to blue in the BOM list for handy reference. I'll sketch on the front plane of the new part, which happens to be in the middle of the source part:
I'll convert the end face edges. Again, Convert Entities is similar to Focus, but it just let me associatively project edges between 2 parts, something Focus won't do. I'll extrude this sketch:
Note the new extrude is in blue on the left, as it does indeed belong to the new part. The rest of the assembly will remain translucent until I toggle off Edit Component, which I'll do:
Mmmmm....a little gray on gray action. Jumbo would be proud. Oh, how I long for the color wheel.
Ok, I'm ready to save and close these files. Saving the assembly file produces a dialog box:
Some other items have been modified, and should be saved. Makes sense, although the terminology is messing with me. Referenced models, to me, would refer to the source part, which I haven't touched. I'm hoping this is speaking only of the target part. Checking the modified dates on my part files reveals this to be true.
At this point, we've wound up approximately where we would be if we had done a derived part. This way is taking longer, but I've got significantly more control over what I'm copying. I'm not going to need to bother with deleting surfaces, because I only have what I want and nothing else. Let's investigate the relationships, and work on propagating a change.
First I'll open up the target part, and see if we get any useful information about the relationship.
Uh oh. No mention of the context assembly or the source part, and the question marks make me nervous. And for good reason, it seems. Here is what the online help has to say:
The suffix ->? means that the reference is out-of-context. The feature is not solved or not up-to-date. To solve and update the feature, open the assembly that contains the update path.
Yeah, I figured that much. But where is the assembly? Find References didn't do me much good with a derived part, but let's give it another try:
Hot dog! Tells me which assembly, where it is, notes that it is not currently open. Only real complaint at this point is that it doesn't provide me a way to open that file. I'm going to have to remember where the file is, and go open it manually. Since I already know the part is in the assembly, no point in asking the assembly if knows about it, since it, uh, does. The bad news is that, just like with derived part, the source part does not seem to provide any means to find out where it used. Find References again does not report the assembly or the target part. That's bad.
Let's make a change to the source part and see what happens. Same idea as before:
Save and close, now let's open up the target part and see what happens.
Figures. Actually I guess this is roughly the same as I-DEAS. You would have to set up a specific set of circumstances in order to find out that a target part needed to process changes from the source/context. And SolidWorks does have a handy option here:
You can edit the feature in context. Curiously, this option does not appear if you select on the actual part at the top of the list. In my head, I want to update the part, not just the feature. Oh well. Anyway, choosing this option opens up the assembly, where you are instantly presented with a dialog box:
This is much more in-your-face than I-DEAS is, and I would say it is a good thing. I-DEAS tends to rely on color alone to convey information, and that is sometimes a bit too subtle. I'll let it rebuild, and then I'll choose to edit the component so that the results are clearer:
The perimeter did indeed grow to match, but I'm still missing the half-moon. Same problem as derived part. I'd say this is fundamentally an issue of how sketches behave, and it is going to take some getting used to. We as I-DEAS users are really going to have to be careful how we define things, and take extra special care in inspecting any updates to make sure that we got what we want. Frankly, I consider this to be a major flaw.
And to be clear, I don't really have an expectation for the half moon to show up on the target part. It is new geometry, so the software would have to make some kind of assumption in order for it to get there. What I have an issue with is that some design intent is broken here (the complete circle is now an arc), and the software is not alerting me to this fact at all. This is how changes get missed.
I'm pretty sure the issue here can be traced all the way back to trimming. Recall back to the post on trimming; I-DEAS does not care about sketch curves, only the section. If you Focus (project) a circle, you are getting the entire circle. It cannot be trimmed, because there is no reason to allow it. If your desired section only involves part of the circle, you are going to have to draw geometry to establish intersections on the circle to define the arc you want. If the source circle that you Focused from gets broken up (turned into an arc), I-DEAS will bark at you because something has been lost.
It will let you proceed as-is, and will use the previous geometry in the meantime, but you will be alerted that there is an issue every time the part is updated. It's not a construction problem, it's a design intent problem, and I-DEAS makes sure you know about it. That's A Good Thing.
So how does this relate to trimming? Well, keeping in mind that SolidWorks really wants you trim away extra geometry, the designers had to figure out a way to allow associativity to other features (or parts, in this case) while allowing curves to be trimmed. They have to allow for the case where I will Focus/Project/Convert an entity, and then not want to use the entire entity, and trim away what I don't need. I'd be willing to bet that behind the scenes, SolidWorks is keeping track of "completes" on both ends of the Conversion. In this case, what I picked was a complete circle, but I bet that doesn't matter. Even if it was only an arc, behind the scenes it makes a note "ok, there's a circle here, but I'm only using this much of it." And then on the converted sketch geometry, it does the same thing. So when I go in to trim away parts of the circle, it says "Well, ok, there's still a circle here, and it came from that circle there, but I'm using less of it." So as long as the "complete" circle exists on both ends, SolidWorks doesn't see any difference in the arc lengths as important. If I removed the hole from the source part, or made it a square, THAT would cause an issue.
This is of course all speculation on my part. I could be completely wrong, and there's something I'm missing. If anyone can shed some insight on this for me, I do try to understand how these programs think, and I'd appreciate the education.
Anyway, sorry to go off on a tangent (zing! CAD joke...). In order to finish propagating the change to the target, I simply need to edit the sketch, convert the new edge, and trim (IRK!) the circle.
At this point, I've got something that is basically the same as I would have in I-DEAS. The source and target both exist in the context assembly, changes are propagating, all is good. What we will do at this point in I-DEAS is suppress the source part. This isn't a software requirement, more of a working practice. Our users would accidentally or deliberately wind up breaking the relationship, and our solution was to make the context assembly very important (often the context assembly would get deleted, thus destroying the relationship). The drawing for the cut-to-length part is actually generated off of the assembly, not the part. This requires that part changes be processed through the context assembly in order to see the results on the print. Convoluted, yes, but very robust. And when I want to use the cut-to-length part in other assemblies, I do not insert that piece directly, I insert the context assembly. This means that the raw extrusion is also getting placed into my main assembly. So we suppress it. We don't want its mass properties contributing to the assembly.
I'm really not trying to be a moving target here, but I wasn't able to describe this yesterday since the derived part was not in the context assembly. The concept didn't apply.
No problem, SolidWorks allows parts to be suppressed just like I-DEAS does.
And here's what that looks like:
Note the item grayed out in the list, and of course the part is not displayed. So far so good, in essence the same as I-DEAS.
After creation, all of our Associative Copies exist like this. So if any changes are necessary, this is the mode we will be in. I'll save and close all documents, then go make another change to the source part:
I will now open up the context assembly:
Uh oh. Clearly the target part has not changed. And if you were paying attention to the first go-around, I got a dialog informing me that things needed to be updated. I didn't get that dialog this time. I'm going to guess that Suppress in SolidWorks clamps down harder than Suppress in I-DEAS, because I absolutely would know right now that I-DEAS wants to process the change. Let's test this assumption by Unsuppressing the source part:
(I changed the display of the raw part so the results could be seen) As soon as the raw part is unsuppressed, the change is instantly propagated. Well, aside from the lack of design intent warning, I mean. That's going to take some getting used to. I'm going to make a guess (not worth exploring right now) that I can get around this by using an extra assembly configuration, but that's additional work. Suck.
I suspect I'm not even scratching the surface of what can be done with Top-Down/In-Context modeling, but I think these sketch-driven examples are all I have seen and currently know how to do. As always, if there's a better way, I'm all ears. I think we'll be using this method a lot, but will need to get some kinks ironed out.
Good: More specific selection of items to copy, fine-tuned control over relationship.
Bad: Don't know where the source part has been used.
Bad: If the source is suppressed, target won't update.
Bad if true: That deal about when to save, possible broken relationship
I'll be curious to see how all of this plays through PDMWE.