How To: Speed Up Mating in Assembly Mode

[jmongi]

It may just be this particular assembly, but...

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

[AlexLachance]

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.

[jmongi]

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.

[Tom G]

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).

[SPerman]

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.)

[Dwight]

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.)

Good list. Also, don't mate to a patterned component (unless you really, really have to).

[Alin]

It may just be this particular assembly, but...

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

Is this happening only on one assembly? You made me so curious. I imagine you cannot share the file set, but I would love to dissect it.

[jmongi]

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.

[Alin]

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).

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?

https://www.engineersrule.com/the-ultim ... ody-parts/

[AlexLachance]

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?

https://www.engineersrule.com/the-ultim ... ody-parts/
image.png

Yess!!!! Good point Alin!

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.

[JSculley]

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.

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.

[berg_lauritz]

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.

[JSculley]

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.

[berg_lauritz]

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.

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.

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.

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!

[Tom G]

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.

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.

[Alin]

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.

Then... you must love the new "Q" keyboard shortcut.

[berg_lauritz]

Then... you must love the new "Q" keyboard shortcut.

I cannot wait for a stable version actually.... So many small & good improvements

[SPerman]

What is the new "Q" shortcut? I didn't see it in any documentation.

[berg_lauritz]

What is the new "Q" shortcut? I didn't see it in any documentation.

here you go!

[Dwight]

Does the Q shortcut show reference geometry that is hidden in the FeatureManager? I wouldn't think so.

[DanPihlaja]

Check your graphs in your Task Manager (the performance Tab).

Do the thing that causes the lag and see which graph spikes.

If I were a betting man, I would say it will be your Ethernet graph.

Check it out and report back.

[Alin]

What is the new "Q" shortcut? I didn't see it in any documentation.

"Q" is crazy good for those of us who want to work as close to 100% in the graphics area and avoid wasting time digging through the FetureManager tree.

In a nutshell, if your mouse is over a component, pressing Q will temporarily reveal all the reference geometry of that component, so you can select one or more of those entities. If your mouse is hovering over the empty area, the reference geometry from the current document is revealed.

Example use cases:
1. Mate default planes:
a) hover over a component, press Q and select a plane
b) hover over another component, press Q and select a plane
c) from the Quickmate toolbar select coincident
d) click somewhere else to hide the planes

2. Mirror something about a plane
a) press Q to reveal the planes
b) select a plane
c) start the mirror command

and so on...

[Glenn Schroeder]

Does the Q shortcut show reference geometry that is hidden in the FeatureManager? I wouldn't think so.

Yes, it does.

[Glenn Schroeder]

"Q" is crazy good for those of us who want to work as close to 100% in the graphics area and avoid wasting time digging through the FetureManager tree.

In a nutshell, if your mouse is over a component, pressing Q will temporarily reveal all the reference geometry of that component, so you can select one or more of those entities. If your mouse is hovering over the empty area, the reference geometry from the current document is revealed.

Example use cases:
1. Mate default planes:
a) hover over a component, press Q and select a plane
b) hover over another component, press Q and select a plane
c) from the Quickmate toolbar select coincident
d) click somewhere else to hide the planes

2. Mirror something about a plane
a) press Q to reveal the planes
b) select a plane
c) start the mirror command

and so on...

@Alin,

I didn't know about that, so thank you. I plan to use it often. However, there are a couple of things about it I'm not fond of. Maybe some of your 5% stuff?

1. When I do that, it not only shows the planes for the Part my cursor was on, but it does it for all instances of the component in the Assembly. I'd much prefer it to do it only for the one component.

2. In addition to making the planes visible, it also makes the origin of every component in the Assembly visible, which I definitely don't like. Does it do that for everyone, or is that one of those little tricks SW saves for me because I'm special?

[berg_lauritz]

@Alin,

I didn't know about that, so thank you. I plan to use it often. However, there are a couple of things about it I'm not fond of. Maybe some of your 5% stuff?

1. When I do that, it not only shows the planes for the Part my cursor was on, but it does it for all instances of the component in the Assembly. I'd much prefer it to do it only for the one component.

2. In addition to making the planes visible, it also makes the origin of every component in the Assembly visible, which I definitely don't like. Does it do that for everyone, or is that one of those little tricks SW saves for me because I'm special?


image.png

Let me take a guess here:
1. I wish it would do that - but I think 'Q' just shows ALL reference geometry on part level (which means it shows it for every instance in the assembly)
2. It just shows all. Maybe they can add a setting to exclude some ref. geometry?

[MadMike]

Check your graphs in your Task Manager (the performance Tab).

Do the thing that causes the lag and see which graph spikes.

If I were a betting man, I would say it will be your Ethernet graph.

Check it out and report back.

My ethernet graph is spiking while trying to run simple mates. What does this mean? Can I transfer everything off our network drive and have better luck?

[SPerman]

I remapped the Q key to something else years ago. What is the name of the command that is being called?

[DanPihlaja]

My ethernet graph is spiking while trying to run simple mates. What does this mean? Can I transfer everything off our network drive and have better luck?

I don't know why it is spiking. I took all of my settings (file locations) and changed them to my local hard drive, and then made sure that the part that I was working on was also on my local hard drive.

My ethernet was still spiking.

If I unplugged my ethernet cable, then the lag went away completely.
SO, Solidworks was communicating something whenever I clicked on a part in an assembly. But it doesn't NEED to.

I pushed this to my VAR and they either didn't understand what I was talking about or couldn't figure it out. And apparently it didn't warrant sending it to Solidworks.

I pointed this out to my IT department and they decided to nuke it from orbit and reinstalled windows.

The problem is still there, but only periodically.

[jcapriotti]

Are the files loading from a network location? Are files loaded lightweight? I know SolidWorks will only load a small amount of data lightweight, then stream additional data as needed. Mates may need additional data causing the spike.

[Alin]

I remapped the Q key to something else years ago. What is the name of the command that is being called?