SW2004 & patterns

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.

WT

 

I think I have found another detrimental change (bug) in 2004. If my

You can still do that.

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

 

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.