ASSEMBLY PERFORMANCE: Poisoned Assembly

I have an assembly that:

  1. Will rebuild in under 2 minutes.
  2. Seems normal in all other respects
  3. Can take up to 2hours 30 minutes to save.

This isn't a network issue, I have gigabit and bandwidth isn't being used The CPU is running 100% for the whole time during the save punctuated by blips of network access.

I figure something has "poisoned" the assembly. Any thoughts or questions (even the obvious) on what to look at would be appreciated.

TOP

Reply to
TOP
Loading thread data ...

any patterns?

Reply to
marektb

Yup, 3.

I know, they have to go. Add external references too. But, why at save and not > any patterns?

Reply to
TOP

Additional information. This is the journal file from the time I selected the assembly till after the save. Notice that save is not logged. It is like it hasn't started saving yet. The selectby just keeps repeating over and over.

swApp.ActiveDoc.ActiveView.FrameLeft = 0 swApp.ActiveDoc.ActiveView.FrameTop = 0 swApp.ActiveDoc.ActiveView.FrameState = 1 Set Part = swApp.ActivateDoc2 ("400459.SLDASM", False, longstatus) swApp.SetUserPreferenceToggle 119, 0 swApp.SetUserPreferenceToggle 119, 1 swApp.SetUserPreferenceToggle 119, 0 swApp.SetUserPreferenceToggle 119, 1 swApp.SetUserPreferenceToggle 119, 0 swApp.SetUserPreferenceToggle 119, 1 swApp.SetUserPreferenceToggle 119, 0 swApp.SetUserPreferenceToggle 119, 1 swApp.SetUserPreferenceToggle 119, 0 swApp.SetUserPreferenceToggle 119, 1 ' MSGBOX ' 400459 - Rebuild Errors

' MSGBOX ' Warning: 400522 has rebuild errors

' 401901 has rebuild errors

' Coincident171: Warning: One of the entities of this mate is suppressed, invalid, or no longer present.

Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050064-1@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050064-1@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-64@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-64@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-65@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-65@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-66@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-66@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-67@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-67@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-68@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-68@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-69@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-69@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-70@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-70@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-71@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True boolstatus = Part.Extension.SelectByID2("050047-71@400459", "COMPONENT", 0, 0, 0, False, 0, Nothing, 0) Part.ClearSelection2 True

Reply to
TOP

Mark,

Think you put your finger on it. If you look at the journal file it keeps repeating a select on 0500064. That is one of the patterened assemblies. As soon as this sucker completes I will put those items into a subassembly all of their own and get it out of the top level assembly. That will be the first step.

Thanks.

TOP

Reply to
TOP

How many parts? If parts change and regenerate, then they will need to save, also.

I have my options set such that references open read-only. I have a "Save Silent" macro that skips saving parts that are opened read- only. This has reduced save time.

Reply to
That70sTick

TOP: Swks 2007?

Reply to
Bo

So am I reading this correctly that component patterns in assemblies increase the save time (not just this file, but in general)? I have not heard this before, and we have lots of patterns and long save times. Any specific kinds of patterns -- feature driven vs linear, component vs subassembly? Thanks!

Eric

Reply to
Eric

Flexible Sub assemblies? I haven't used them since SW2005 when they were the apparent cause of much angst in a couple of my large assemblies, move one part the whole assy. flew apart.

T> I have an assembly that:

Reply to
wc

for some strange reasons it looks like sw2007 doesn't like pattern at assembly, either parts pattern and most futures patterns. in sw2006 assemblies with patterns were slow but in sw2007 is much much worse.I do not know why and it is just my observation Mark

Reply to
marektb

To all who helped. Thanks.

The last save before reading responses here took upwards of three hours. Thanks to the input here and on Dan Bovinich's email list we are down to 2 minutes. Pretty good results.

After hearing the pattern problems and looking at the journal and seeing it stuck on a patterned part that was the first thing I fixed. To do that I pushed patterned stuff down into a sub assembly and this by coincidence also removed some in context that probably also wasn't helping much. After a couple of crashes everything was just fine.

I just might want to look into the Tick's macro too.

Next I'll be changing nappies. :)

TOP

Reply to
TOP

So do you think it was the patterns or something extraneous like the in-context stuff? We do lots of component patterns and I don't recall ever seeing saves more than maybe a couple minutes.

WT

Reply to
Wayne Tiffany

Wayne,

If you look at the journal file it kept coming back to the same part, different instance. I dissolved the patterns and pushed them down into subs. When I did that if just kept getting faster. That process also broke some external references. So I can't say which was worse. This particular person also was in the habit of mating to patterns. Big no no there too.

I didn't have the time to check the effect of each move. At potentially 2-3hours per test that wasn't practical. I'll grant you this wasn't everyday behaviour, but when it happens, ouch.

TOP

Reply to
TOP

That70sTick wrote in news:1181137850.616362.239420 @h2g2000hsg.googlegroups.com:

Does this produce better save performance than the "Don't prompt to save read-only referenced documents" system setting? I'm sure you're aware of the setting, but I'm not sure how the macro might be different.

Reply to
Dale Dunn

Since the pattern now exists in a subassembly, can we conclude that there was a problem with that particular pattern, instead of component patterns in general? I don't want to hear later of CAD admins banning component patterns.

Reply to
Dale Dunn

Dale,

This one was complex so I would not make a generalization. Patterns will of course slow an assembly just like anything else. And with patterns there is the danger of making a mate to a patterned item which will cause a bigger hit. Ditto with in-context to a patterned item. For that reason when I mate, I do it rolled back to the mate tree. Then doing no-no's is less likely.

I will also dissolve patterns if and when they are causing a problem with performance and it can be done without causing other problems. I place the dissolved components in a folder so I can delete and recreate it as necessary.

BUT, the problem I had was with saving; it was orders of magnitude slower than it should have been, and it could have been patterns, in- context or a combination of them peculiar to this file. Ordinarily patterns don't cause the kind of major problem I was seeing.

TOP

Reply to
TOP

Paul,

Did you check on settings such as saving the mass prop data with the parts or saving tessellation data with the parts? These would both cause saving to be much slower than simply rebuilding.

Reply to
matt

Matt,

True enough and thanks, but getting the patterns out of the top level and breaking some of the in context stuff made the huge difference. I'll check on this as soon as SW stops crunching in a few hours (on a test, not a real part).

will assume means off. There are several tessalation settings there and I am not sure which correspond to the options you mentioned.

T> Paul,

Reply to
TOP

Sorry about your save issue. That is a drag, but I suppose you're email Inbox is pretty clean due to the extra time :)

However, this DOES bring up another can o' worms that I have hesitated to talk about for years.

Errr... does Ctrl+Q on the assembly level actually DO anything?

Whenever I do one, it is lightning fast, like nothing happened. Forget about the number of in-context references (a few to a relative gajillion - no difference in rebuild time that I recall), and forget about the number of top-level mates. Every time I ctrl+Q an assembly, it is over in about a second regardless of the assembly. However, switching back from editing a part in the asm at the part level and returining to the asm (even if choosing NOT to rebuild the asm, which I almost always do) it can take minutes.

So my question is, has anyone seen a ctrl+Q of an assembly take a non- trivial amount of time, which we would expect if there was a non- trivial amount of assembly detail being calculated? (caveat - I never do assembly cuts except for animations, and rarely do joins or cavities, so I am missing data on these features)

For release, I would love to have a single key combination that forced the rebuild of everything in the asm, even if I had to wait to save it the following morning. i know some folks who assume that a ctrl+Q of the assembly verifies everything, but I know that is not the case. I learned years ago the dissapointment that to check for release I have to methodically open and Ctrl + Q every single component because a top- level asm Ctrl+Q doesn't seem to do much of anything.

Anyone know what is really going on? Anyone else have a different experience that might shed some light on this? Ed

Reply to
Edward T Eaton

"Edward T Eaton" a écrit dans le message de news: snipped-for-privacy@p47g2000hsd.googlegroups.com...

NOTHING: edit part, change a dim, Ctrl+Q: nothing changes. Hit 'trafic light': geometry updates. (SW06-5.1) WTF?

Reply to
Jean Marc

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.