What settings affect performance when mating in assembly mode? Before when I’ve had slowdowns it was an assembly issue in general (lots of components, visual complexity, etc) and that affected everything dynamically dealing with the visuals in realtime.
This, doesn’t seem to be exactly that. I can spin my assembly around with minimal lag and do all sort of things relatively snappily. But, when I go to mate a component, I can go through the whole process, SW even adjusts the part to the new mate and then…LONG pause (we’re talking 10-20 seconds with a SW spinny wheel). I’m not sure what it’s doing. This also starts to happen when I go to edit an existing mate. For example, I select two surfaces to mate a certain distance. I select mate, i select surface 1, then surface 2 and SW automatically assumes coincidence, moves the part and then…chews. I click on the distance mate button…wait…finally it updates…then I try and click in the entry field to specify the distance…wait again.
I have a larger more complex assembly that is working fine (detailed threads and expanded metal, things that traditionally eat up your hardware resources). Any tips on what to look at?
This is on SW2022 SP 2.0, but it was doing the same thing on SW2021 SP4.0
Using a lot of advanced mates, using flexible assemblies are both things that tend to make assemblies heavier.
The long pause after is that there is something somewhere that is mated/referenced accordingly and needs to rebuild itself accordingly.
Lots of in-context doesn’t help also. You can check if that is the cause by locking all external references from the master assembly and then redo the same and see if the rebuild continues. If it does, perhaps it has to do with mates that relate to whatever moves.
It just seems strange because the larger assembly has MORE in reference items and MORE advanced mates and I tested out a few different mate edits. Added some dummy parts and played around with them and no issues whatsoever.
There are a few enough parts in this subassembly that I may just reassemble it and see if the issue reappears.
Approximately 98% of my mates are NOT to faces. Since changing to primarily mating reference entities to reference entities, I have had overall better performance. This absolutely requires a little more attention in the components, but it works out better downstream in assembly and in drawing.
I could be wrong, but in order for it to mate to faces (unless it’s only a dumb solid), it has to solve for that face, then solve for this face, then produce the mate. Then introduce complications within, and you get more delays.
OR, it could be a temporary hiccup with something else (restart, rinse, repeat).
There’s lots of good info on this topic in this forum, but I can’t remember which threads to search.
Breaking assemblies into smaller sub assemblies always helps. I think this is due to how the SW solver works. It is much easier to solve 3 equations simultaneously 10 different times, than it is to solve 30 equations simultaneously once.
Using patterns for multiple instances (fasteners for example) is a big improvement.
I also think about the complexity of the relations I am creating. (I’ve never done any testing to see if this makes a difference, but I feel like it should.)
Mating Part A to Part B has to be easier on the solver than mating Part A to Parts B, C and D. The latter options requires many more equations to be solved simultaneously than the first option. (That’s my theory anyway. I’ve never taken time to test it.)
Alin,
I’ll see what I can do. The really odd part about this is that the presumably root cause is in two different assemblies, one with the issue and one without. I’ll elaborate.
The presumable root cause is a natural gas compressor that is fairly detailed with external features but no internal ones (received from the vendor). I have placed the basic version in an assembly of the whole compressor package. Lots of pipe and tube fittings, coolers with fins and expanded metal grates, internal to the assembly pipe and tubing sweeps. Lots of things that traditionally impact assembly performance, but, no issues (so far).
This particular compressor is frequently used with an unloader option that didn’t come modelled by the vendor. So, the problem assembly is this same compressor being made into a subassembly that contains the various bits and bops that come along with the unloader option. Then, I was going to swap the basic placeholder for the newly minted subassembly when completed. It’s this subassembly that is being cranky.
As far as face vs. reference geometry, someone will have to explain why a mate to a face that requires “solving” is worse than a mate to reference geometry BASED ON the same face. Doesn’t SW have to “solve” the reference geometry and then “solve” the mate to the reference geometry? I"m not saying that can’t be true, but in these situations it would be nice to have a rational explanation for it.
Is the simplified version of the compressor a multibody part?
If it is, can you please check the number of face-level appearances (actually the number of faces with face-level appearances) in this part?
The evaluate tool is such a strong tool to help alleviate files. If the file still is “slow”, then you can push further with the “Visualise assembly” feature, but you need to know what to look for, though it’s rather common sense I’d say.
So, start with the evaluate tool. If it’s an assembly, just updating all files to the new version could make things better.
Next, have a look at the number of triangles generated. If some parts are generating too much, can you simplify them? Can you turn their quality down?
Next, look at the appearances as Alin stated. I’ve had a multibody part once become slow because the appearance had applied itself to all faces, rather then the body.
There’s a “Performance rebuild” that you can have a look at in there that could perhaps help you spot what slows everything down.
It will also mention if some part’s image quality is set too high, if there are you should set those to a lower setting.
If it’s a part, then the evaluate tool is a lot less complete, as it speaks of the features and sketches only, but you can still spot from there which could be heavier. Sometimes it can give a tip
You can still pretty much do a similar inspection by looking at the number of triangles and the part appearances too, but there’s no feature to facilitate it.
The ‘Best Practices’ article in the SOLIDWORKS knowledge base considers faces and planes to be equivalent with respect to mate solving. Don’t fret about it.
My most hated slow mate problems in an assembly (in no particular order):
virtual parts that are mated and not fixed in place
Flexible assemblies (I only use them for testing)
chain mating (Assembly to part a to part b to part c to part d to part e…)
mate to patterns (just don’t!)
parts with external references in that assembly that get mated (bad practice!!!)
mating to parts with external references (almost as bad as virtual parts imho)
too many advanced mates
mating to points/edges
mate to assembly features (cut something off in an assembly & mate to the face that is cut off i.e.)
If you avoid those the number of mates without having a serious performance impact is pretty high.
The most subtle thing is chain mating and virtual parts in my opinion. We recently reduced one assembly opening time by about 60% by changing our mate scheme to use almost not a single chain mate and getting rid of every single virtual part. Every part was mated to the assembly planes/origin or to the most basic part.
I fail to see how a mates to a virtual part with mates would cause performance problems. The only explanation I can think of is that you are opening assemblies lightweight. If a virtual part is in there and has mates, SW is perhaps resolving the part, which means it has to unpack it from the assembly file and generate a real SW file in the temp directory, which takes time.
Chain mating and flexible assemblies are pretty much required in my work. Highly asymmetric, highly articulated multi-axis machines that drive themselves on a track. Do flexible assemblies cause mating problems? Absolutely. Especially when combined with configurations.
100% correct - that is what happens more often than not. If you have a virtual assembly with virtual parts in it - PDM almost ALWAYS shows a ‘modified on open’ for that assembly because it does exactly what you describe.
So yes, it does slow it down. Additionally virtual parts get this ‘modified on open’ tag if you change almost anything in the assembly - which means they get rebuilt. We still have some low level purchased parts that can not be loaded lightweight because they have virtual parts in them. That means it opens like 6 levels of an assembly partly not light weight. It’s painful - I would not recommend virtual parts for large assemblies. I do however still make use of them esp. in the designing phase.
I know that it’s sometimes unavoidable. If you use a lot of flexible assemblies there was a very good talk from Alin about how to make it WAY faster. If you haven’t watched it - do it!
Ideally, my reference is not based on the face. The face is based on the reference. The reference is not a result or an afterthought. It is a start. Not everything that I use has achieved this ideal. If I had to start my library from scratch, there’s many things I would do differently.
I am blessed with standard components which live on primary planes. The Primary planes generate most applicable axes in the part template, and most applicable face planes are normal to a primary plane. In an ideal part, the face planes are driven from primary references, then faces use them as Extrude end conditions.
Add complications, or coworkers, and this may not apply.
