Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Restructuring Assemblies?

S1monS1mon Member Posts: 3,039 PRO
Related to this discussion about BOMs and this improvement request about promoting parts to higher assemblies, I have another challenge...

If subassemblies are in the same document as a current assembly, it's easy to drag parts from one level of the structure to another. What's the easiest way to deal with this if the subassembly is a "Versioned assembly from another document"? Do I temporarily move these subassembly tabs into the main assembly document to drag things around or do I just manually re-insert and mate things and delete things?

This is the first time I wished there was a way to temporarily have the active workspace instead of the versioned thing assembled, so that I could manipulate it live without having to move things from document to document.

Comments

  • eric_pestyeric_pesty Member Posts: 1,947 PRO
    One way I've dealt with dissolving a sub-assembly is to select all the parts of the sub assembly and copy and paste to the top level.
    This will preserve all the mates between the copied parts (by copying them all in one step) so it saves some time compared to re-inserting everything...
    You can then delete the assembly but of course you might still have a fair amount of cleanup to do... It would be nice to have some sort of "local dissolve" (not sure what it could be called: dissolve copy, copy dissolve, unpack sub assembly?) that would remove the assembly and replace it with it's child parts without modifying the original one (so that it would work with a versioned one).

    Hadn't really read what you said before I started typing... If you just want to move some things back and forth then moving it temporarily to the same document seems like the best way to do this... I've done this as well when editing drawings if the part/assembly was in a different document. It feels a bit weird but it's pretty quick and easy to do, the only real downside I can think of is that it makes the "history" hard to follow for the assembly that gets moved out and back in...
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,071 PRO
    edited April 2022
    This is what I've found... Multiple docs shouldn't be part of the design environment and I tend to keep those things that are changing in one document.

    As soon as you reference anything outside a document, then you have to deal with versioning. Using multiple documents is for items that are near completion, a standard stockable item and something that can be used on other projects.

    Is the document level important? Yes but it's not a day to day thing that should be part of dynamic design effort. I'd keep things between assemblies & part studios as long as possible. Let's say your team has developed a complex assembly and another team would like to use it in their new project. That's when you move the assembly into its own document and give it a life of its own.

    Well that's crazy? This highly desirable assembly now has a life of its own and can supply both projects. But, when they reference the assembly they have to declare which version that want to use. 

    One of the main benefits of documents in a project structure is to allow both projects to access this highly desirable assembly but also allow changes to that assembly using versions. One guy can easily add something the other guy doesn't want. If you branch the this desirable assembly, it can be a desirable thing with minor variation to handle everyone's desires.

    FYI all my library parts are in other documents and before I promote them to this library status, I make sure they are stable. You don't want to be making a lot changes to references outside your document otherwise you'll start complaining.



  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,071 PRO
    edited April 2022
    @eric_pesty I do a lot of what you're recommending.

    Have you had issues with moving assemblies from document to document? I'm thinking moving an assembly into a document so I can easily work on it and then moving it back to another document is not for me. I could be wrong. I'm thinking that moving an assembly to its own document is a very special event and requires many considerations.


  • shawn_crockershawn_crocker Member, OS Professional Posts: 869 PRO
    @S1mon if your goal is to actually take away from one assembly and place into another, I would definitely move the tab into the active document. When I was starting with onshape, I wasn't fully wrapping my head around all the power of the versioning system and started taking a route of moving everything into there own documents just before submitting releases. I have stopped doing that and I now try to keep as many things as possible in the same document. If items from one assembly need to leave that assembly and exist in a different one, I think it's fair to say those two assemblies are related enough to exist under the same roof. As a design gets released and then revisited for changes, items in the top level that are sure not to change can still be updated to an older version of the document or a release and the performance benefits of referencing versions returns even though the items haven't actually left. I find it more comfortable to update an item to reference the document workspace then I do to move it from one document to another. In fact, most of the time these days, I'm moving items only because I want them back into a top level document to repair my error of having moved them out.
Sign In or Register to comment.