It’s happened to all of us. You’re bakin’ up sweet 3D assemblies in SolidWorks when all of sudden your supervisor walks over, scratches their dry chin skin over your keyboard and challenges you to 1) not vomit and 2) create 5 other version of the same assembly.
All psoriasis and skin flaking antics aside, creating usable assembly versions in SolidWorks is challenging, especially in a design environment where ideas float around like immunological diseases in need of a heavy dose of anti-inflammatories.
However, there are ways to do it, and probably a few things you’ve tried yourself. Here, we look at the question that prompted a look into three options and get your take on which works the best or if there are other ways to prove you are a design iteration master. It’s ON.
What would you say to someone that told you this:
I’m cranking away on a large assembly, but I’m designing as I go for a lot of details. I’d like to be able to fork off into a new design and run it parallel to another concept I’m trying, or at least have points that are easy to move back to if an idea doesn’t work out.
How do you create versions in SolidWorks? Even more, how do you create versions you can work with simultaneously? Here are three options I’ve used…
Option 1: Use Pack & Go
Using File, Pack and Go… you can copy and add a prefix to the assembly files.
Option 2: Save the assembly as a part
Using File, Save As… you can save an assembly as a part to try different things.
Option 3: Configurations
Insert copies of parts, suppress other parts, flip back and forth between configs.
Option 4: Virtual Parts
Insert representation of parts, copy parts, make copies independent and save to external file.
The best way to create versions of SolidWorks Assemblies? Pack and Go allows you to select what files you want to copy and add a prefix or suffix to them. (Click to Enlarge)
I’ve done each. Pack and Go, no doubt, works the best to create and open multiple version of the same assembly. Virtual parts allow you to work in a single assembly between copies of parts. But are there ways or methodologies you’ve used to do assembly versioning better?
Update: I just want to clarify. How do you make versions without a PDM system? It’s easy to assume everyone can use a PDM system (Enterprise PDM or Workgroup) to retain version of files, but that’s not always the case. This is really something that should be available outside the realm of file server/vault and outside the need to upgrade a Standard SolidWorks license with installation and training of a database.
Loading ...
SolidSmack is a very small behemoth of an online community about 3D CAD, technology, design, robots, and ninjas… Ok, maybe not ninjas so much, but those guys are COOL so there just might be something about some dang ninjas.
{ 21 comments }
manually with file names or folders, the best way, use Enterprise PDM
yeah, EPDM makes sense if you have it (or workgroup) but that requires an upgrade to SolidWorks Standard, plus knowledge and training on the delicate nature of SQL servers and vaults.
What would you do, if you didn't have EPDM?
Josh, I also use Option #1, with variations in filenames like -REV-01 or -TEST-01. Even if you have a PDM system, it is easier to do it outside the system if you're still in the “concepting” stage of design. Requires more work, but it doesn't gunk up anything as badly either.
Cool to hear Bruce. I'm thinking that's going to be the way most do it. There's just nothing i know of that allows you to create and mix iterations of different designs. Inventor Fusion has some functionality when you bring in parts that have been exported from Inventor to Fusion, which allows you to choose what features to bring in. Rhino has part version you can create.
I kinda picture it like duplicating a layer, like in Photoshop (but with a separate history) that you can try different stuff on.
Option 3, configurations combined with virtual parts and sub assemblies, tidy it all up with tree folders, then delete the unwanted parts and configurations when done.
When modifying parts i have already modeled to try a different concept, i'll often 'save as' a copy and insert it into the relevant config, then i drop or add features as i go.
@Andrew H – I really like the idea of using virtual components. I haven't worked with this capability much yet, but I think it circumvents many of the problems inherent in renaming files (by not having the files in the first place).
@Josh – Without sounding like a smartaleck, I'd like to point out something about your question. I know I am a data management guy, so my perspective is slanted, but aren't you essentially asking, “How can I manage my data [in case XYZ] without using data management software?” Although I can appreciate that this is sometimes necessary, I feel it is important to point this out.
There are far too many people that consider PDM to be “something IT should handle” or just a clerical detail that engineers shouldn't have to mess with. From my perspective, managing data is almost as important as creating it in the first place, such that engineers and designers should see PDM as another tool in their toolbox, not as some nuisance or superfluous add-on (I don't mean to imply that this is your opinion).
I can appreciate your question and I recognize there are reasons why not everyone can have PDM. However, I think it is important to challenge this notion (before resorting to manual techniques for file naming) since someone has already written a software tool to solve the problem you're trying to overcome – all you have to do is buy it and use it.
Great convo happening here. I've played with the Pack and Go method, but the problem I run into is that it really limits you to one iteration before you start stacking prefixes or suffixes. “assembly-1-2-3-4.sldasm”
I'll have to play with options 2 and 3 as well as the suggestions by Andrew.
I agree that using as PDM system is the best, and I'm a complete data management nut, but I know that I'm personally in a situation where I can't add that software to my setup in the short term, even though it is a long term goal.
We use DBWorks to manage files, so mainly we use their Assembly Duplication Wizard for versioning (sp)…
…But if we feel like REALLY getting some work done (DBWorks is slooooooooooooooow) pack 'n go is how our regulators mount up. Then later, back into DBWorks with the new children and parents.
Thanks Jonathan. I gotcha, but this is getting more at a functionality issue inherent in every modeling program I've used and can think of. I'll go back to a statement I made in the comment back to Bruce.
“I kinda picture it like duplicating a layer, like in Photoshop…”
If you're familiar with Photoshop, you can duplicate a layer, modify that 'version' of the graphic and decide to use that one, merge it with the previous or go back to the other one. It's not a perfect analogy, but it gets the concept out there.
Virtual parts in SolidWorks are another option for a specific workaround – they really helps with conceptualizing assemblies, but it just doesn't go far enough to aid in a ideation process.
Instead of revolving around controlling versions of files, this is about being able to control different iterations of features within those files and how they affect the overall aesthetics of the design.
It definitely doesn't take away the need for a great data management solution – or someone to help implement it
so that's why I say it's more on the functionality side of things.
Hopefully that gets the idea across a little better. yeah?
Andrew, has a good method. With the virtual parts you can copy (hold ctrl and drag the virtual part below another part in the FeatureManager) then separate that part from the other (right click, Make Independent.)
You can also right-clikc on your existing parts and select Make Virtual.
This way you can branch off from the design and go a different direction, create some configurations and then choose the one you want to go with.
Hope this helps you!
Bingo. Thanks Andrew! This is a great option and one I'd choose when starting a concept. Good options, but would like to be able to merge independent parts together.
In theory you can do this with the combine (part) feature (although i would never do this in its current state), alternatively it might be possible to do something with multi-body solids and configs of parts with hidden or removed bodies then when done you could use the combine body feature and remove the ones you don't want. Another option might be to insert a part as a base into another part and then modify to get your new iteration.
All these options are pretty messy though and i wouldn't really recommend them, it would be sweet if it was possible to dissolve a part within a part as in: insert part-dissolve part (break relations and show as features within the part as opposed to a part within a part) kind of like dissolve sub assembly…
Being able to 'dissolve' features into (or out of) another part would be sweet. The Combine or more often Join feature has always been a final step in the workflow for me, but it would be interesting to play with it and see how it would handle changes from the referenced parts. good stuff man.
I'll be playing with virtual copies for this.
In the meantime, I realized that the Save As… dialog inside of Solidworks actually offers a bit more power for this use than Pack and Go in Solidworks Explorer. When in the Save As… dialog, you can hit the References button and you get controls for adding a prefix or suffix to the file names, as well as Find/Replace, which takes care of the trailing suffix issue of Pack and Go. It's pretty manual, but not as manual as renaming each part by hand.
Interesting that you comment that the “functionality issue was inherent in every modeling program I've used and can think of.” I can think of one that doesn't have this problem- NX. NX has builting versioning rules and the ability to load files in different locations (from directory, As Saved, or Load Latest). This functionality has been around since UG V10 and for those out there that would be around 1992'ish.
The versioning rules tells the system what part of the file name is the version mechanism which determines the latest version and combined with the file location rules this is a snap. Although, you wouldn't be able to open the different versions up in the same NX sessions (the system see a part version already loaded).
BTW you might want to get that last post removed..nothing like adult content sneaking onto sites..
(and sneak it did… thanks.) I think the word 'version' I used is a little misleading. NX versioning is still a file management type of versioning, whereas the versioning I'm speaking of here is a configuration or tree type of version that allows you to explore different ideas. make sense?
Sounds like a folder and reference nightmare!!!!
The idea of managing member parts through the top level single file assembly is a very cool idea (saves a lot of messy folders). This is the typical stuff that happens on a designers desktop.
I want to check an idea with everyone. I think of these variations as “representations”. Imagine a case where three alternatives of Assy_A (which has a set of design requirements, issues and tasks) are evaluated using one of Josh’s methods. Each solution being evaluated is a representation of Assy_A and therefore each has a common set of requirements, issues and tasks. But each variation is also stand alone and therefore has additional issues and tasks specific to only it. Thoughts?
yeah, that's why I steped through the virtual Part process some mentioned above.
It allows you to make other representations without having to worry about folders or references.
But I see what you're saying. A part can have any number of representations, be it geometry or other data. What's important though, from a design process (at least the one where I explore a lot of different concepts) are systems that have the ability to adapt to the ideas being generated without directly influencing the flow.
This is one of the things we are exploring with Vuuch. How do these representation work and how do they work without impacting the user habit in a negative way. This leads to how Vuuch allows structuring of Vuuch pages (parts). For example you might have a parent page (represents a part) which has sub pages (represents potential solutions for the part) or you might simply have a page for each solution you are looking at and these pags are related through specific activities. Or you may have a single Vuuch page for the part which has multiple part files related to it.
yeah, that's why I steped through the virtual Part process some mentioned above.
It allows you to make other representations without having to worry about folders or references.
But I see what you're saying. A part can have any number of representations, be it geometry or other data. What's important though, from a design process (at least the one where I explore a lot of different concepts) are systems that have the ability to adapt to the ideas being generated without directly influencing the flow.
This is one of the things we are exploring with Vuuch. How do these representation work and how do they work without impacting the user habit in a negative way. This leads to how Vuuch allows structuring of Vuuch pages (parts). For example you might have a parent page (represents a part) which has sub pages (represents potential solutions for the part) or you might simply have a page for each solution you are looking at and these pags are related through specific activities. Or you may have a single Vuuch page for the part which has multiple part files related to it.
Comments on this entry are closed.
{ 2 trackbacks }