Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Tipps for oragnization of documents
Hi guys,
just wanted to ask how you organize your big projects.
For example, you have a big machine with 20 different assemblies that are all dependent on each other.
Every assembly consists of 10 Part Studios and 10 sub-assemblies and few other tabs (drawing, imported parts, etc.) - so big enough for its own document.
But, for me the problem with different documents is that I must make a version of the document to see the changes in another document. This applies to every single change in the document (also for just adding a thread, hole, chamfer, ..). This function is good in a later status of the design process. But at the start you have a lot of small changes in the different assemblies and sub-assemblies you want to see live without making a version.
So therefore, I am curious how you organize your documents or am I the only one with these problems?
Comments
Early in the design process, it can make a lot of sense to have everything all in one document, except maybe purchased parts or anything else you know isn't likely to change. However, it does slow things down. It really depends on how much you're waiting for rebuilds. If the performance hit isn't making you miserable, it may be fine to keep things in a single document as long as you can. Within a single document you can switch derives and assembly instances from workspace references to version references and back, if you want. This can help control some of the rebuilds and get you ready for splitting out the tabs into separate documents later.
Keep in mind that a document has one history tree. You can branch and merge, which is powerful, but this affects every tab in the document. At a certain point, even as a team of one, you'll run into things where it would be nice to have some things in separate documents to have more fine-grained control over this.
You can also try splitting out tabs into other documents and if it's too annoying, you can move them back.
Without seeing the complexity of your parts or part studios, it's hard to tell how much pain you might be creating with a single document, but things like imported parts and drawings do start to sound like you really could split things out. Imports are typically pretty static. Drawings aren't live anyway (you have to refresh them manually).
Keep in mind that versions are free. I often make several in a day just to mark major progress, so if I really screw something up, I have a clear place to revert to. I leave the "Vxx" in the name and just add a short reminder of what changed in the name. Sometimes I'm lazy and just leave the "Vxx". It really takes a second or two. Updating all the dependent tabs to the latest references can be tedious, but getting used to this process is valuable.
To some degree, this all depends on how you are prototyping or releasing your parts for production. When you start making prototypes, you don't want to make new parts that have the same geometry just because some references got updated. You'll want to be more deliberate about revisions. Certainly once tooling is involved, things get a lot more expensive to change and you don't want a part to change without notice.