I think I have found another detrimental change (bug) in 2004. If my memory & testing are correct, in 2003, you can add items to a component pattern after the fact, even if they are "lower" in the tree. Upon trying it in
2004 SP2.1, it won't let me - everything lower is greyed out, and the model in the graphics area disappears when the "higher in the tree" pattern is opened for editing, which prevents even selecting out there to add them.
So, I figured I could reorder the patterns, even though you get the "no way" cursor symbol. In one 2004 test assy, I can do the reorder. In my main lift assy, it will not let me reorder the top one below any of the other patterns, even though it already contains items from those "lower" patterns, making it a child of them. I think the only reason I could do it originally is because at the time I created those patterns, I was still on 2003.
Please check this out on some existing assy's and let me know. Thanks.
Whoa. The only things "lower" in the tree than a component pattern are assembly features and more component patterns. These are history based features. I'm not really clear on what you are saying, but it sounds like you're talking about patterning a patterned instance of another component pattern.
If you were able to do this in 2003, then the bug has been fixed.
Do you have any problem with assemblies being slower than they should be?
Your approach makes intuitive sense, but I don't think it works from the SolidWorks point of view.
Everything south of the mates paperclip is history based, just like features in a part, but SolidWorks to some extent is playing fast and loose with some things in part to keep from confusing newbies but also I think to keep from frustrating existing users. The price we pay is that there are things going on behind the scene that don't match what we think is happening.
Here are the things SW has removed or hidden in the last few releases to make life "easier":
- separate mate groups
- update holders
- mate error messages
I grant that it is much less confusing now, but that is because there is no way of telling from the display what is happening. In the end, I think people get themselves in more hot water, like deadening your nerves and walking on broken glass.
Mates have to position the parts. Incontext, assembly features that relate to parts and component patterns cannot be solved until after the mates are solved. A component pattern which is dependent on another component pattern has to wait for the other pattern to be solved. This is why the parts list is not history dependent, but everything after the mates is. This is why it is bad practice to mate to an incontext feature, assembly feature that relates to a part or a component pattern. SolidWorks must still be using multiple mate groups behind the scene and just whitewashing the "confusing" logic from the tree. You get cyclical rebuilds, and assemblies function slowly, not to mention you might get some strange behavior with parts or features moving with each rebuild.
This is also a reason why modeling in context can have some strange effects when you make relations to incomplete parts. If you come back later and add a fillet to an edge that is referenced by another part, you'll get a dangling relation. So the state of the parts when the incontext features are added is not history based, but the incontext features themselves are.
Anyway, I'm completely confused now and hardly remember the question, but I think the answer will turn out to be that the way you remember it was the bug, and now it works the way it "should".
What do you do to work around it? I don't know, get used to thinking about things after the mates in assemblies as being history based, the way it is meant to work, I guess.
matt
"Wayne Tiffany" wrote in news:c1ohk3$1l3st7$ snipped-for-privacy@ID-201804.news.uni-berlin.de:
Yes, patterning a pattern is something that was added for 2003 that I think should have always been there. Whether or not the "mate groups" are still there in the background or not is an interesting thought. Yes, obviously, the patterned instance used in another pattern must be defined to be able to be used, but how they did it, I don't know. If the item to be used was created higher up in the tree, it shouldn't be any problem to use it, as it already has been defined - that one's pretty easy to understand. It would make some sense that when it hit the item in the pattern that was actually created lower in the tree, it would either jump to that reference and solve it, like a file on a hard drive - random access, and then come back to where it was. Or it would leave that one unresolved, go to the end and then go back and make another pass through to pick up the missing ones. Either of the latter 2, I would agree, would logically seem to produce slower results than a one-time pass through. However, both of us are speculating.
..........
Maybe so - I noticed the change and was intrigued as to the reason for the difference.
The best workaround this time was to delete the big pattern and recreate it at the bottom. Agreed, this probably is the best thing to do anyway, but it was a bit of a mind bender to not be able to do something that I was pretty sure we used to be able to do.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.