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.
Part Identity & Design Workflows
MarkGibson
Member Posts: 3 ✭
First off, hello to all of my old friends from SolidWorks! And second let me say that I'm really impressed with OnShape so far. It's great to see that you guys are thinking about new ways to make a CAD system beyond just putting it in the cloud.
Anyway, I have two questions:
The first is about whether parts have an identity beyond their bodies. At present "parts" seem to be a loose construct where if some features in the Part Studio create a separate body, that becomes a part. However, it seems that if that body goes away later, so does the part, then the mates fail, the assembly "can't resolve" the part anymore, etc. I'm wondering if that's an inherent way the system works, or just a temporary thing? Stepping back from CAD, I think of a part as having its own design intent and identity that's independent of the solid/surface body. I would tend to build in refgeometry as guides to model from, then build solids. But I'm wondering if you have a better way of thinking about this.
My second question is about design workflow. In my work, I use a hybrid of what in SolidWorks would be "part" and "assembly" functionality. Part instancing, patterns, mate-constrained drag, imported models; but also layout sketch and parts built off of the layout. The Part Studio seems like a really nice way of doing parts off of layouts. But 60% of our components are purchased and the models are imported, then mated to the layout or to each other. So my question is, what's the OnShape way to design (vs. modeling up already-known parts and assembling them)? Should I be looking to import/mate/instance/drag parts within the Part Studio, or should I be looking for geometry capability in the Assembly environment (i.e. sketches, parts with refplanes, etc)? Or am I stuck in the SolidWorks "box" in my thinking and there's a better way? I'd like to use OS for a design project at the moment, but even though our geometry is super-simple, I'm having trouble with the "design" part.
Thanks!
Anyway, I have two questions:
The first is about whether parts have an identity beyond their bodies. At present "parts" seem to be a loose construct where if some features in the Part Studio create a separate body, that becomes a part. However, it seems that if that body goes away later, so does the part, then the mates fail, the assembly "can't resolve" the part anymore, etc. I'm wondering if that's an inherent way the system works, or just a temporary thing? Stepping back from CAD, I think of a part as having its own design intent and identity that's independent of the solid/surface body. I would tend to build in refgeometry as guides to model from, then build solids. But I'm wondering if you have a better way of thinking about this.
My second question is about design workflow. In my work, I use a hybrid of what in SolidWorks would be "part" and "assembly" functionality. Part instancing, patterns, mate-constrained drag, imported models; but also layout sketch and parts built off of the layout. The Part Studio seems like a really nice way of doing parts off of layouts. But 60% of our components are purchased and the models are imported, then mated to the layout or to each other. So my question is, what's the OnShape way to design (vs. modeling up already-known parts and assembling them)? Should I be looking to import/mate/instance/drag parts within the Part Studio, or should I be looking for geometry capability in the Assembly environment (i.e. sketches, parts with refplanes, etc)? Or am I stuck in the SolidWorks "box" in my thinking and there's a better way? I'd like to use OS for a design project at the moment, but even though our geometry is super-simple, I'm having trouble with the "design" part.
Thanks!
0
Answers
These are two great topics for discussion. Generally, you have identified two areas of our system that we have given a lot of thought to but have not completed.
With respect to part identity and independence, we will fully support the flexibility to build single parts per document (we currently have the ability to create single parts per part studio) to be used in assemblies which may be in it's own document or part of a document containing other assemblies or part studios. When we support links between documents (the ability to insert parts from separate documents into an assembly) you will be able to combine, reuse and reference components very easily. We also will soon have an origin in our assembly which allows you to place parts via datum reference. You can use mate connectors created in the part studio as you can today and the placement can be relative to a global datum in the assembly, making it more independent of the geometry (though the mate connector will still be tied to some geometry from the part studio). The bottom line is that, though it is not in the system yet, we will make a huge leap in workflow flexibility, design reuse and data manageability when we support linking.
The second issue will be addressed when we allow you to create and edit a part studio in the assembly context. We have given a lot of thought (really a LOT) to how we do external reference management (references made between part features in the context of an assembly) and have designed a system to be extremely robust, flexible and controllable. It will support layout and top down workflows and eliminate the brittleness and headaches caused by conventional approaches to external references.
Be patient. These are big projects and will not be available immediately, but are very high on our "to do" list.
/Scott
FWIW, while editing in and among other parts is important for my work near-term, I could easily live without actual updating external references for some time. Like many users, I use them sparingly -- not just because of the fragility of previous systems but because as various components get made it is imperative that that they don't update anymore.
Mark
Thanks for the feedback. Updating will not be done automatically, you'll be able to reference and update, but you'll be able to control how and when things update.
John
Great to have your insights and comments since I know how hard you worked on this topic your last days with Dassault. I've had a lot of "off-line" discussions about this topic with Joe and I have not said anything here because like Scott mentions "they're coming." I too question the logic of building Parts in a part studio when it seems that they are little more than multi-bodies. I do see the advantage of when you bring a part studio into an assembly context that the Bodies are now automatically Parts, but like you allude to, my workflows for productization require that Parts have more individual identity.
I also believe that OS will not be able to be successful (especially in consumer product design) without having a solution for Master Model. Master Model Technique is a sound and proven workflow. Part into Part and Parent to Child Part (really the same thing) has real value and it doesn't have anything to do with CAD necessarily but more to do with how PD teams collaborate together and the value of authorship.
The trend that I see is that Master Model used to be something that only Consumer product design used, but more and more I see machine and mechanism designers using it - probably because SW did such an awesome job with Multi-body implementation. OnShape has a good start on this, but I believe that as the product matures for production use, separation between Author (parent) and Team member (child) needs to be an optional workflow.
I'm interested to see how Scott and Team deal with the whole issue of building in-context with other "Parts" and yet incorporate mates for motion. Unless they have something up there sleeve, you won't see motion in the Part studio but that will be reserved for the assembly.
Mark
Regarding Master Model for machine designers, I suspect that you're right although I wonder if that might be as much due to people getting burned by external references. I've definitely sifted through a maze of SW refs and thought "screw movement, wouldn't MM be nicer?". But in the end I need drag-motion too much, and my assemblies have too many parts, to use MM as it exists in SW.
I hope I didn't imply that I don't want to build parts in the Part Studio. It seems like a natural for layout-sketch-based design, especially if the system can distinguish movement from geometry change and limit the rebuild accordingly (without which it's not scalable).
To be honest, I don't care whether I work in a "part" or "assembly" environment, because design intent consists of both variational and history-based elements and I need both. SW blurred the lines by adding in-context modeling in assemblies and multi-body with "mate" features in the part environment. But it's still two different environments, and the fact that we still debate "MM vs. in-context" is a symptom of the fact that neither really solves the problem. IMO the "holy grail" is to integrate both seamlessly. Based on how close you and I got in our work at DS, and that guys like Dave, Tommy and Scott have been crunching on this for a long time, my hunch is that OS is going to nail it and we'll all be really happy with the results.
The answer? No idea. But if I was doing this I would be focussing on a unified part and assembly mode, so modelling is like multi body. Could OnShape, with its versioning, not enable a part version, an assembly version . What I mean is take a part with multi bodies as the standard build method ( as it is the most logical). Then switch to assembly version, where the bodies are linked to parts (assigned automatically or by the user) and where you can apply movement mates (because that is primarily what assemblies offer).
Another serious pain point in SolidWorks at least is doing in context assemblies where you use lots of patterns and rely on cutting parts in the assembly to create the shapes you need. AEC requires a lot of this ( think modelling a roof structure...lots of the same parts but often cut in different ways). Frankly there is nothing good on the market that handles this for the modelling and drawing production of the whole "assembly" then the individual parts with lots of custom cuts. We invariably end up modelling in context assemblies then using this as a reference to recreate parts for drawings. Not great.
So to sum up, in my experience the pain points are assemblies with lots of common parts that need to be defined in context, and require in context trims. The other big pain point is designing anything in context that moves. I have not tried SolidWorks Mechanical Conceptual (not through lack of effort in asking either!) so don't know if that works better, but designing linkages and interlocking 3d parts in SW is a pain. I invariably stick to using blocks in a master sketch for assemblies.
Got lots of thoughts on this but its late, and tomorrow I have to drive 500 miles!
In both cases though, to create drawings you could just select a body and create a drawing of that body. The SolidWorks approach of drawing creation doesn't really offer that flexibility. To be frank, over 12 yrs on and we have not improved the basics of these fundamental modelling and file organisation processes.
I think possibly the nearest to ideal I've seen recently was Spaceclaim. But of course that fell flat as it had no really associativity so didn't have to content with internal or external references.
Dries
The workflow you described above does seem to fit the current Onshape workflow. I am sure you already know this. But I just wanted to spell it out as clearly as a can. In Onshape today:
Part Studios tabs are for in-context design
Assemblies tabs are for motion
Any part studio, in its entirety or its constituent parts can be referenced within an assembly. Each part in an assembly can move, and or be mated. BOMs can also be created.
We have currently focused our efforts to make the incontext capabilities of a Part Studio, such that they do not impose the typical limitations associated with multi body design. The separation of state, is motion. if you want true dynamic assembly motion, you put the parts in a assembly tab.
There are a couple big milestones to come with incontext referencing and more of the concepts of "derived" parts. So this is just the basic starting point.
The unified environment
I have yet to see a system that has true in-context associative relationships and at the same time brings motion into to mix in an "unified" environment. Since if you build something in place, then you move it using a mate, you are telling the same thing to be 2 different things at the same time. Is it built in place? Or is it moved? Or is it built in place, at the new position of the parts?
Mark and Mark can chime in if they want. Since they are two of the smartest guys I know on this topic.
Here is a basic workflow that describes the typical conflict.
Joe
The thing is though, moving parts usually have a function, or a working requirement. A door closing mechanism has an open and shut state, then perhaps clearances to other parts. Maybe we need to change the design process to be functionality based rather than contextually based. But this I mean, you know the start and end and bits to avoid. Ultimately we don't care about anything else. To be honest, I think this is a nut that will only be cracked by incorporating non CAD related functionality. Have you seen Graficalc? Terrible terrible interface but very useful. Why this stuff has never been properly integrated into a core CAD system is beyond me.
Like I said, I'd like to try SWMC to see if it does really offer anything new, you guys probably know the answer to that!
Good discussion. Mark nailed it when he mentioned that the adoption of Master Model is probably more due to the painful alternative of in-context modeling. One criticism I have of SW since '95 is that although in-context modeling was built into it from the early days, it never really was scaleable for a lot of situations and as users when from novice to moderate and advanced, they learned to avoid it. Hence several years later, SW finally acknowledged this and added the "No external references" button on the Command Manager ribbon (LOVE THIS FEATURE because it final makes in-context modeling somewhat bearable.) For me the "line of demarcation" is motion. The Master Model technique golden rule holds today as it did 20 years ago: "any feature that is shared by two or more parts represents a MM feature, and feature shared by only one part does not belong in the MM." Master Model is simply an extension of the History-based parametric paradigm for part model that extends beyond the part itself. Because of this demarcation, I use it to separate the state of in-context modeling from motion. So even thou I do not get motion with a MM part, I use the derived assembly to verify the motion. This is not ideal but it works for me (and others.) Like Kevin mentions, I use blocks early in the design process to get to the heart of the design problem early and quickly (so that we can avoid the complexity of many features and there assocativity and focus on the key problem at hand.) this works well for what I call "single-plane" motion which probably comprises 80% of motion problems. This is what we set out to do with SWMC and I think it does it pretty well - with the addition of a few other surprises.
No doubt that Tommy, Dave and especially Scott (since I talked my face off to him to the point of annoyance :-)) about these issues, but my point from the beginning is that Master Model is not a CAD feature but a workflow that has important value in the PD process allowing authorship, separating motion for in-context modeling as well as other aspects I won't go into here.
Like Kevin mentioned, I do quite a lot of both MM and in-context modeling especially when there are stock or shared parts involved.
I would like to write more about my thought, but all of you - keep'em coming. I need to get to work because I'm "on the clock" with my clients :-)
Mark
FWIW, I always thought there was a need for 3D blocks, rather than just 2D blocks. 3D blocks would allow a quicker layout tool with fewer blocks created. I requested this in SolidWorks. It seemed like a natural with the 3D sketcher, but the 3D sketcher seemed like a second class citizen next to the 2D sketcher. Laying out the basis for mechanism design with just planar 2D blocks seemed too limited, or too involved to get to a 3D layout using them. Food for thought.
As a long time Solidworks user I'agree about generally good workflow, with pain point of modelling parts in an assembly and getting failure prone in context links.
We CAD users all design different stuff: swoopy consumer products thro' to complex mechanisms & machines and at many different stages: of R&D, concept, development, production and beyond. Making tools for all these people and scenarios must add big hurdles for CAD developers - kudos guys !!!
Unlike Kevin, often in Solidworks, I do make parts 1st then add to assemblies. .. As I simply find this more robust compared to modelling in assemblies. BUT with a twist / workaround:
1. 1st make a single part, which is just a multitude of driving planes sketches,
This is the master model, or driving sketch part.
2. Then import this 'part' as the 1st feature of each main part of the assembly (or save-as to make new parts).
3. Then modifying the underlying1st part (using either right mouse 'edit in context' or opening the 'driving sketch part' ALL the parts update.
I find this method super robust .. Much more so than other top down or sketch in assembly methods. But as above we are all modelling different products/stages ... I'm using this for a new folding bike for which I've got to 'bench test' several differing layouts / concepts as well as producing part files and QA drawings for external prototype making.
I guess sharing this aims to help onshape team and add to discussion... We all find different ways of holding our pencils :-)
1. Where the parts are static, but need to be designed in context for easy editing, we use a single part and multi bodies, then save bodies with create assembly on. We find this quite robust for editing parts and also for creating assemblies where you need to tweak relationships between parts (think moulded screw thread)
2. Where parts have to move in context, we tend to either do it all in assembly from a driving sketch and design parts in the assembly. A lot of the time here though we will rough things out then rebuild parts as standalone.
3. Where the assembly is a structure and static, think building, we start in assembly and create driving sketches and planes then build up parts from that. Editing sketches, all parts and planes update.
4. The single part config. Here we creat a single part and use configs to show different elements. We then creat assembly and mate the different configs. Has some uses!
Its fascinating to see how we all hold our 'pencil' tools in different ways ;-) . I too like single parts with multibodies and am a big user of configs in SWKS for different scenarios - yet use assemblies differently. I guess different products also call for different CAD techniques.
Apart from many minor niggles, the Big tool I'm constantly missing in solidworks is something like catia 'imagine and shape's powerful, yet simple, easy interfaced surfacing tool .. I know there are addins and work arounds but here's dreaming :-)
Normally I jump in a SW assembly and work out the mechanics/layout/sizing of my machines with assy sketches (I did try use the layout sketch and block system but never really got the hang of it) generally get what you need with standard sketches on 2 main planes, then start mating parts/assys to the sketches to get a visual feel for the design, these might be existing parts in other machines or standard purchased components e.g. wheels, from here i start blocking each component out, working from assembly down. Merge and dissolve works well as the design changes along the way. I try not to have too many in context links and get rid of these be to just in the local assemblies not drilling back to the top layout assy as these alway end up with trouble. Normally I would set configurations for the different working positions and a free config to get movement, quite often this also involves a number of flexible assy's (these tend to fall over pretty easily especially when done in multi levels driven by the top sketch but can work well). I use multi-bodies alot for purchased parts where no BOM or flexibility is required, sometime these will have configurations for different lengths positions if need be.
Onshape requires a different method, and I am happy for other ideas on how I could improve my work flow. I am starting within the parts studio for my initial layouts, the mechanics can be worked out using sketches but theses are not visible in the assy and therefore can not be used to drive anything outside the parts studio. The parts then have to be mated using features modelled into them. To get them mated you can not grab any thing from your layout sketches and at this point you only a have a few main parts so have to start block out parts with mate feature which will be removed later as you get more detail. I will keep persisting but looking for more functionality in this area, which I sure will come with time.
I also can not seem to find an offset mate for clearances between faces.
Also are the part studio's going to have BOM's? and if so will you be have to be able have repartition of parts, e.g. drag another instance out of the tree would be good. It seem to me that any ridged assembly, like weld frames, even bolted assemblies should be completed in the parts studio and BOM and drawing created from here.
Bruce
Twitter: @onshapetricks & @babart1977
You made a part, a part was a file and then you put multiple parts into an assembly, which also was a file. From this structure, extrapolation of engineer-y types of things, like BOMs was straightforward. Over time things like configurations, in-context, top down, PDM systems provided additional wrinkles.
The user-interface goal is to strive for transparency and self-evident operation. With a minimum of effort it should be clear to the user what steps and actions are required to produce a given end result - and I remember sitting in class for days, still unsure how to get ProE to do what I wanted.
I remember putting a lot of effort into coming up with digitizing tablet menus (ComputerVision CADDS4) that were designed and organized with workflow usage in mind. I tried to go beyond simply grouping similar graphic commands in close proximity but rather sought out tablet layouts that would have instructional value and would step someone through the part creation process. I then remember seeing a Macintosh running MacDraw for the first time. Self-evident operation and it was clear to me how CAD systems would look from that point on.
Perhaps it's possible to come up with a few workflow scenarios that illustrate the power and flexibility of the software?
Maybe there's a GUI solution (like what's used for branching) that can guide/inform the user?
-Jim
That is what I do when making clearances.
Twitter: @onshapetricks & @babart1977
It appears this topic was hot at SW, but I hope that the OS developers don't get caught up in it, because as an end user I honestly don't care how many ways there are to create geometry. As long as OS offers a way that is at least as good as the way I do it now. Show me a way to launch a product to production faster, cheaper, or easier than how I do it now, and I'll bust out my checkbook.
I think @Jim_Anders brings up the biggest point of all, "How does one begin?". It begins with education. As long as OS educates new users on what top-down vs. bottom-up design is, when each method is ideal, and how best to use OS for each method, all is good.
The conversation should then get steered towards the really innovative things in OS, such as the Visual Version Management (Branch/Merge) and the Browser-Based Modeling. Coupled with "Easier than MS Office" usability and the "Turn your server room into a game room" lack of file management and you're poised to (1) take market share away from the big guys and (2) grow the market by getting to the n00bs first.
I know I'm late to the convo, but my two cents!
Linked[in]
I really like what I've seen from OS so far. I finally have access to good 3D cad on my Linux boxes, hurray!!! Also, before they came along I was looking for a way to make Git play nicely with 3D cad files for improved version control, now there is no need since OS does it for me. Awesome. Can't wait to see what feature they will add next, I'm hoping for lofts and configurations...