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.

As designers what are we really doing with assemblies?

traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO

I thought it would be interesting to look at what tasks around real assemblies and subassemblies we need to accomplish without worrying about the mechanics of the CAD tool.

In talking about mates, @bill ended his post with "...it's about creating a tool I can use." This is the bottom line for me.

My grandfather taught me to really treat tools with respect. I remember very clearly him tearing into me the first time I grabbed a crescent wrench, the nearest thing with heft, to bash a lever into place. "Damnit! Use the right tool for the job and get up off your ass to get the right one if it's not handy".

However, a good toolmaker becomes intimately familiar with the context his tools are used in. He knows that we have work to do and a good tool enables that work as transparently as possible. 

I'm sure Onshape has done their homework in developing the requirements for their assembly models. Nevertheless I think it  would be interesting to lay out what assembly related tasks we need to accomplish. Here are the things that jump to mind. I'm really curious what you guys are dealing with; please add your own items to the list or put your perspective on the things below.

  • We manage BOMs
For BOMs I need to group parts and subassemblies into assemblies. I need to be able to associate information with parts and assemblies and be able to run automation (scripts) tools on the whole thing. Some information needs to be extracted from the model (mass properties, part counts, material) and some information the model needs to extract (descriptions for drawings, ...). For myself, manipulating this info in a common format with common tools (JSON/YAML, Python) is preferred to database api's and proprietary tools.

  • We manage documentation for fabrication and assembly.
As an assembler, I want to understand the parts, tools/jigs and consumables I need to put the assembly together. Sequence of steps, exploded views, key assembly specs (bolt torque) and checks all help. An entirely 3D interaction could be nice however my experience has been that over-the-shoulder snapshots, a manual of standard techniques, and a few assembly specific notes is the quickest way to document low volume stuff.

  • We check the assemble-ability of parts within the assembly as a whole as we design them.
For checking the assemble-ability of parts ("can the parts be assembled together"), I need to start accurately defining their position relative to each other. At minimum I need to lock groups of parts together and move the different groups relative to each other. Theoretically, this could be done automatically with a path planner. Tools and fixtures have to be verified.

  • We design the mechanical interface between parts.
Checking the mechanical interface features... Do holes line up? Does the assembly still work when you stack up manufacturing variations? Here we need LMC and MMC configurations of the parts and mates to the surfaces rather than some datum as the surfaces are what changes. 

  • We use motion studies to verify kinematics and dynamics during the design.
Rigid body analysis is the norm here. I have to admit that I'm not up to speed with the latest tools here. I usually extract mass properties from the model and run them through my custom tools. The ability to export the kinematic chains and loops would be helpful. In the past motion study tools integrated with cad were too simplistic. I have not checked this in a while.

  • We generate materials for marketing and design review
Maybe we generate animations using the motion study tools. Maybe we export the model in a format that graphic designers can import. I have been blissfully uninvolved with marketing in my career.

  • We evolve the design as it progresses
No project is static. Changes are being made often, and with every change we need to make sure we are not breaking something. I hinted in previous posts how I have used the mate solver as a tool to detect issues. 

What else? I know I'm missing things...

Tagged:

Comments

  • Ed_DanzerEd_Danzer Member, Mentor Posts: 13
    When we design things we assign part numbers. Every part or assembly needs an unique identifier so it can be manufactured or purchased and can be stored and found. If you build products with a long operating life replacement parts are required to be inventoried to keep customers happy and purchasing new products. The customer needs to be able to call and give a part number to order the part with from his owners manual. Having a good part numbering scheme and storage method is essential for success in selling parts and keeping the customer happy.

    We reuse existing parts and subassemblies as much as possible. It works best to have part models built without in context features. It seems to work best to use reference geometry for mates in SolidWorks for long lasting assemblies. I have a SolidWorks assembly with parts created in 2011 that blows up in 2015 that are mated with edges. 

    We make the next iteration of a product. This is where we fix the problems with the prior design. The objective is to continuously improve a product. End user manuals need to be updated at the same time. Again the goal is to reuse as much work as possible.

    We make a new size of a product. This is where we take an existing product and increase or decrease it operating parameters to meet a new market or customers request. Some of these products will only be built once so it is critical to be able to leverage existing products and manuals to reduce the cost of production.

    We determine material requirements. To build a product the purchasing and production people need to know what to use to build the product. This can be inventory material or purchased material.

    We may determine where to get a product or material. During the design process if a part or material is new to the company or difficult to find we mas specify a vendor to purchase a product from.

    We specify fits. Many designs require operating fits with minimum and maximum ranges for manufacturing to meet so a product will function properly.

    To find items to reuse is a significant problem if you make lots of different products of different sizes. This is where I use a semi-significant part numbering system to help out. I never use a Rev number always a new part number starting with the product being sold so 20 years later I don't have to wonder what Rev part was used in that product. This may seem difficult but if you have a good method it goes quickly and will save time and trouble years later when the product value is low.
  • julian_lelandjulian_leland Member, OS Professional, Mentor Posts: 59 PRO
    I think that the discussion of "where to get" different items/managing BOMs through assemblies is really important. Two features in this realm that I'd love to see:
    • Some ability to classify parts by type (custom mfg, OTS, hardware)
    • Building off of that, integration with inventory and purchasing software. If our inventory management system (which, in the case of MISys, can be cloud-deployed) could be linked to our CAD infrastructure, it could automatically keep up with/notify for rev changes, link POs directly to "public release" part and drawing files, provide cost information to designers on the spot (something I wind up having to track down a lot), simplify ordering, and lots more. This is probably most relevant in the context of an assembly, but is applicable to parts/a user or organization's collection of documents as well.
    Finally, to simplify part re-use in the case of simple parts (especially hardware) - in the wonderful, shining future where McMaster, SDP-SI, and all the other major industrial parts suppliers provide OnShape models of all of their hardware directly through the OS interface, it would be great to have the part geometry and ordering data (supplier PN, cost) remained linked to the supplier's copy of the part, even if the end user changes some aspects of that part (for example, assigns an internal PN)
  • brucebartlettbrucebartlett Member, OS Professional, Mentor Posts: 1,878 PRO
    edited February 2015
    In a lot of case's I can see the only need for an assembly would be to get a BOM listing on the drawing. Depending how the drawing package works ,rigidly assembled parts, could be done with only a Part Studio. There would need to be a multi-instance part mode. ie. identical parts will have a count on a Part Studio BOM and be seen as instances in the Part Studio parts list.
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
Sign In or Register to comment.