Assemblies - I'm confused...

Edward_Goodwin

Please could someone point me in the direction of a tutorial for using assemblies in Onshape which does not involve mates which move? I understand the advantages of how Onshape can create moving assemblies etc. But I'm struggling to find a tutorial to help me understand simpler non-moving assemblies!  For instance:

I have two part studio which I'd like to assemble. None of the parts needs to move relative to one another. In each of the parts studios there are lots of parts/instances (one of the parts studios was created in Onshape, the other was imported from SW). 

In one of the parts studios I've created an assembly and have inserted all the parts/surfaces from that studio there. I've fixed those parts. I've then inserted the other parts from the other studio. All the parts are now not fixed - they are floating and even if I insert the parts via a second assembly, they are all still floating. Am I missing something? When I create mates, the parts in the inserted assembly move independently. 

So, if anyone has any tips I'd be grateful to hear them. Or, perhaps simpler, if someone could point me to an assembly tutorial that is not about mates which move that'd be super!

Thanks!

larry_hawes

Did you try 'grouping' the parts you want to stop floating?

daniel_cook

You need to use Fastened Mates or make them into a Group. Same principles as all the other mates, just they'll be locked in place and won't move.

Don't just "fix" all the parts in an assembly - you can fix one part and then use Fastened mates from there for the rest. I personally don't fix any parts, and will instead fasten one part to the origin instead.

KatieHuffman

Please see the Group video in the assembly course of the Learning Center. Also check out the video on the Fastened Mate. This might be useful if the part is not in the correct position as you insert it into the assembly.

shouldNotBePosting

One thing that I'm discovering is that I'll make an assembly of the part studio before inserting into my top assembly. This replaces the need for grouping parts in the top assembly. I just don't like all these definitions in the top.

Many of my part studios/sub-assemblies have motion in some fashion like an air cylinder which I don't won't to define it's motion in the top assembly. So, as a design pattern, I'm creating folders for part studios and adding an assembly. This is my basic building block: a folder, part studio & assembly. I rarely put part studios inside the top level assemblies. The exception are the parts I'm making, in this case, I'm using in-context and a part studio for make parts. Turns out the make parts are a small number compared to the overall part count.

Many complain about the use of sub-assemblies as a gathering/grouping mechanism, but I think they're here to stay. Pseudo assemblies that won't have numbers assigned to them and won't show up on BOM's. I just don't see these going away.

part studio => sub-assembly => top assembly

May seem like an unusual amount of sub-assemblies, but for a project structure, it's the best I've found.

The next step after part studio => sub-assembly => top assembly is the document and trying to control a release state for your documents. It seems to me that a project is larger than a document. A document isn't the top, at least not for me. I'm now using folders to define project structure that contain documents. A document is no longer the container for a project, I'm using folders.

I'm currently breaking out assemblies from documents into their own document once they mature and making them have a release state. You want to do this after the design is stable and changes are now minimal. I'm finding moving assemblies from a document works very well and I can do it without breaking any references. It does take planning though.

Once you figure out a design pattern for part studio's & assemblies, the next step is to decide when to move them into their own document. Moving assemblies from documents seems to be working best for me.

This approach scales nicely. It starts out simple and grows as your project grows. Although my current projects in OS are fairly simplistic now, I don't see any issues with controlling huge projects with many engineers using this approach. I do believe this will require planning and management to allow it to grow properly, but I think it can be done.

There's many other tricks I've come up with to keep projects organized. I'm interested in comparing notes with someone.