Hello forum,
To me it makes a lot of sense to store off-the-shelf assemblies (let’s say a pneumatic cylinder) with all its component saved as virtual; that is less files to deal with, no waste of serial numbers, you don’t have to worry about excluding parts from showing up in BOM, cleaner file and folder structure in PDM, etc.
At my current workplace, this approach isn’t being used, and I’m considering bringing it up with the team. Before I do, I wanted to ask if you’re aware of any downsides to this method, particularly any issues that could arise within the context of PDM?
I started doing this when virtual parts were added as a feature back in SOLIDWORKS 2012. Absolutely zero downside or problems. One little thing is training users to download the models to a location outside the vault. Then make the subassemblies/parts virtual and finally save the assembly into the vault. Otherwise the vault is polluted with subcomponent part models that no one remembers to delete.
4 Likes
Thanks Jim, that’s a good confidence boost knowing you had zero issues with them in the past.
Somewhat related to this:
What has been your experience with saving purchase components that are assemblies as just multibody vs assemblies with virtual components. I think quick rule for me is if they have moving parts then assemblies is the way to go. But there’s a counterargument that a multibody part opens faster (is this a fact?) and you can always make movement happen using move/copy bodies (though it’s not as versatile as mates).
I don’t know what’s the threshold (as far as number of bodies), but at certain number imported multibody parts with large number of bodies are always struggling for me.
I haven’t had any issues with Virtual Components in assemblies within PDM. I normally use it in the context of wires within a cable assembly.
For COTS downloads, if it comes from the vendor as an assembly I will normally Save As a multibody part (after stripping away any unnecessary parts). For anything like a pneumatic cylinder almost all modelling scenarios I needed to worry about just needed an “open” and “closed” configuration, it’s rare any intermediate positions were needed.
2 Likes
There of course is a third option. You can save the non-moving stuff as a multibody part and then create your assembly adding in the stuff that needs to move. I’ve done all three, depending on what the part actually is:
- Split shaft collar — multibody part
- Door hinge — assembly
- Electrical box with hinged door — multibody/assembly hybrid
Move/Copy bodies to simulate motion typically isn’t an option for me. The stuff I design has a lot of moving/adjustable axes, so I use a lot of flexible assemblies.
2 Likes
I would look at how often those purchased parts are used in the assemblies. I have 2 different motors that go on most of my models varying in frame size hp ect. Those files we keep in the vault and locked down to keep them from being changed. Then I have other models that need to change that go in each assembly like wire rope, that I make virtual so that when I make some changes it does not affect the other locations that it is used and stays with the assembly.
The major problem I see with making purchased parts virtual in the assembly is the reuse of those parts. If it is a one time thing, or a reference file for clearance fit, I am all for it. If I am going to need that file in all one or more of my sub assemblies then I want it in the vault.
I also don’t like to make the actual purchased item (the one that goes on the BOM) virtual, rather the CAD components that are within a single OTS model that you would not normally procure by themselves. Let’s say a grease fitting that comes by default when you buy a bearing block or something, those are the ones I always like to make virtual.
1 Like
We use virtual components for purchased assemblies as well, no problems. The multi-body part approach is nice and clean solution too in my experience.
One other case that we’ve tried to implement is when there are a bunch of variations of the same type of purchased assembly, seat belts in our application, where they share a mix of common components that make up the outer boundary or function of the purchased assembly. If all those parts were real files we can find all the variations of those purchased assembly by Where Used of a part. This also makes maintenance much simpler when there are hundreds or thousands of where used of the purchased assembly. But we’ve found that keeping all users corralled into one method is tough, so in the end the simplest (not easiest or most efficient) method tends to win out just for the sake of consistency.
1 Like
One thing I just realized that is somehow related to this discussion.
I saw it recently in one of @Alin presentations (not sure which year…)
If you are trying to simplify a multibody model with lots of parts (including washers, bolts, and all sort of other tiny components), doing that within multibody might not be super fun.
His workaround was to save your model as an assembly or set your settings to begin with so it imports as an assembly, then take advantage of selection tools (selection by size specifically) which allows you to select small parts in one shot. You still have the option to save it as multibody once you done (very helpful in large conveyors, or similar systems provided by vendor, sometimes they come with all sorts of hardware that you don’t care about).
The reason to go through this process is that currently these custom selections are not available in multibody environment. Of course you still can delete features within multibody to begin with but I found with large number of bodies it’s not a quick process (scrolling through a large feature tree, etc.)
For PDM there are no big risks. If you decide to create a virtual sub-assembly then insert non virtual components into that virtual sub-assembly, it works but the PDM Where-used for that component will not sure the virtual sub-assembly. It is in the DB though so you write a report that shows it. Otherwise we’ve been using Virtual for years and its pretty stable now.
Two ways I see to deal with commercial parts/assemblies:
1. Import as assembly and make children virtual.
- Can take advantage of assembly tools to defeature, suppress or delete components not needed, etc.
- Can make flexible for use in higher assemblies.
- Might need to rename child files as some can get quite long and you run into the Windows file path limit.
- Large file, all children are embeded, although you can delete what you don’t need.
- It’s an assembly and is slower to load compared to a single part file as it must unpack all of the virtual files to a temp folder, then load the assembly.
- PDM does recognize the virtual children and stores that data which might slow things down when check-in/out and expanding hierarchy.
2. Import as multibody part file.
- A bit faster to load than an assembly, just one file instead of assembly plus children.
- File can get large, expecially if you add configurations.
- Part level defeature tools not as robust as assembly defeature. I think its better in 2025 though.
- If you need to manipulate large amounts of bodies, selection tools are not great and selection is slow.
3 Likes
@jcapriotti Thanks for the detailed response! Good to know about long file path (had that issue before, not with virtual but with files that are embedded into many sub-folders).
I guess one way to make it last longer before you hit that limit is to change the prefix from copy of^ to just C^, saves a few character lol.
Out of curiosity what’s a scenario that you would want to do that, i.e. non-virtual children inside virtual sub-assembly?
The prefix is a welcome option. I haven’t tried it at work since we are still on 2023. Ideally I wouldn’t include any prefix if it allows it. It already adds the assembly filename as a suffix so it’s not needed.
Two uses cases I can think of off the top of my head:
- Assembly has a fairly flat BOM structure but it makes sense to build sub-assemblies for managing in SolidWorks and performance. So we use virtual sub-assys then set the BOM option for children to “Promote”.
- We use a vendor assy but insert some of our parts into it. So the internal vendor parts and sub-assys are all virtual and we need to put our parts in some of the sub-assys.
1 Like
how do you manage multiple configurations for movable things like air cylinders? flexible?
we lock down catalog assemblies and our legacy method is to use only the first component to get BOM info.
Yes. Flexible. And it’s a nightmare. I have a long, well-documented love/hate relationship with them.
2 Likes
we have a very raw way to avoid flexible: catalog assy is an assy and its components are named with a _1 _2 _3. _1 is the only one with a datacard and counted in the BOMs. engineers are free to copy the assy for their projects and use it as they want. just renamed as project name catalog name.
Not ideal, but stable at least.
flex is a nightmare and there are a lot of hidden configurations involved (and due to a bug they were shown inside the parent property dialog iirc)
So basically you have a master, cleaned up model and engineers are allowed to use the master part from library itself or if the need specific configurations they make a copy of it?
yes they can use it as is or make the configurations by themselves, referenced components are locked in the catalog folder.
best would be making the copy of the master assembly as virtual inside its project parent assy.
1 Like
flexible is good until it decide it had enough and explodes in your face.
1 Like
To add some considerations to what I said above, virtual components could get corrupted and they could increase the loading time since they must be unpacked from inside their assy and cached outside the vault into the user temp folder.
you need to read their 3d data from inside their assy, write them on disk, read them again as real files to mate with other components.
There are cases virtual components are very useful, like Orings (to fit non circular cavities), springs, flanged flexible pipes. All of them require an out of shelf shape and use specific data.
In those cases we use virtual parts for the actual deformed shape together with an empty (or just a sketch) non virtual component for data card management and basic geometry reference for the virtual part.
Far from perfect.
Same experience in the past, but I do feel its much more stable than it used to be. Like with anything with mates, its easy to get the mates wrong or have redundant mates that can cause issues. Then adding flexible with another sub-assy level compounds it those mate decisions.
Parallel is a good example, a lot people create them to do an initial alignment, then add a coincident later that makes the parallel redundant. I always delete it so the solver doesn’t have to consider it.
1 Like
