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.
Options
Best workflows - Part studios to Assemblys
dylan_rose
Member Posts: 5 ✭
So I wanted to get some general feedback on how some of you organize your work. I am very often designing while building so it's rare that I will have a complete idea of all of the parts of a given project before I begin modeling. It's always very iterative and I always end up with lots of copies of different part studios and different test assemblies. It gets a bit messy, and I know I need to get more familiar with the timeline/versions/etc.
Specifically, I'm wondering when you all decide to create a new part studio vs keeping parts in a single part studio. It seem much easier to just keep building within the original studio and I personally just like being able to see everything in relation all of the time. But is there a general best practice for this? Some workflows tips I might be missing out on? Or is this just one of those case-by-case things that there it's really a general answer for?
Onshape was my entry to CAD design from traditional mesh modeling if that helps give some perspective as to where my head's at.
Specifically, I'm wondering when you all decide to create a new part studio vs keeping parts in a single part studio. It seem much easier to just keep building within the original studio and I personally just like being able to see everything in relation all of the time. But is there a general best practice for this? Some workflows tips I might be missing out on? Or is this just one of those case-by-case things that there it's really a general answer for?
Onshape was my entry to CAD design from traditional mesh modeling if that helps give some perspective as to where my head's at.
0
Answers
It seems like it changes from project to project too.
If it's a small project with 10 parts, I'd say keep it all in one.
but if you have 100+ parts, now it gets hairy.
I hear some people go with the plan:
Keep related parts together in smaller part studios.
Then make an in-context studio to make your brackets and stuff that's related between studios.
To me it sounds like a structural nightmare, especially when multiple people jump in.
But so is having everything in one slow part studio.
In my head everything is related..
until it's connected by a purchased part
This is definitely a good question and I'd like to share a work flow that I've been quite happy with.
I will start with my initial approach, which was very similar to what was taught in the beginner training.
- Model all related parts in relevant part studios (I basically had 1 part studio with the majority of my parts)
- My approach to modeling was to create the base version of the part first (I was working with a lot of 2D profiles as this model was going to
heavily use laser cutting in manufacturing). So the base model would define the overall shape and thickness. Later on in the feature tree I would
add in more details (screw holes, vent cuts, slot cuts, etc)
- I would include all standard parts in the same document in their own folder. Not sure if this is best practice if you have a lot of documents
you work in, which share standard parts. But if you only have one document you work in the majority of the time, then this means you don't
need to worry about linked documents and manually updating revisions, it keeps things cleaner in my opinion.
- The custom parts and standard parts would be combined in sub-assemblies
- The sub-assemblies would finally be added to a main assembly.
I started having difficulty as the main part studio started to get "complicated" (over 200 features, and 15+ parts). It made editing
very slow as feature tree rebuild times could take anywhere from 1min to 3min! It is not very productive when I have to wait 3 mins to
update a dimension. So I reached out to OnShape support and suggested some alternative workflows I was thinking about to get their
feedback on which would be most efficient.
Here is the work flow I follow now and I find it to be quite effective.
- Have a dedicated part studio for layout sketches. Your layout sketches will be derived into part studios and act as a location to
link any related features (e.g. a hole position will be shared between two part studios because the layout sketch is derived in each studio).
- Break your design into modules any module which has custom parts should have those parts modeled together in the same part studio.
- My rule of thumb right now is to keep part studios under 100 features
- Always insert layout sketches at the top of the feature tree (they should be right after the default planes, with the exception of maybe having variables ahead of them but nothing else!)
- Create sub-assemblies of each module. I find having layers of sub-assemblies to be more organized, and faster than having a lot of parts
in each assembly. For example when working with standard fasteners if I have 3-4 standard parts fastening something I will break that
off into its own sub-assembly. The down side of this is that there may be some manual work in updating spacing in the sub-assembly when the
model changes.
- If you need to create incontext relations do it at the lowest level sub-assembly you can. I'm not sure if this has a big impact on efficiency,
since in-context references a static version of your assembly (so as far as i can tell it doesn't have any rebuild time). But usually when working in context you want to setup your assembly in a specific way, such as hiding or suppressing parts, so the fewer parts you need to worry about when updating the faster it is for you and you're less likely to make a mistake.
- Bring the multiple sub assemblies together in a main assembly.
It probably sounds like a lot of structural work and planning, but it really isn't. You don't need all the detail (which you haven't decided yet) in your layout sketches at the start, you will iteratively go back and add things, a layout sketch could be a simple as a couple rectangles in different planes.
-Your model will be just as robust as modeling in the same part studio as features are derived from the same sketch. So making changes
in the layout sketch will update all your part studios (better than having to manually update changes when working in-context).
- Rebuild times will be much faster as your model gets more complicated because each part studio module can be calculated in isolation.
Making use of parallel processing on AWS. As far as I know the re-build process is: Layout sketches will be built (this is relatively fast as sketches are very simple compared to solid features) -> Each part studio can be built in parallel with incontext relations-> Sub-assemblies can be re-built in parallel -> Final assembly is built. My rebuild times are now less than 30 seconds which is much better.
- Everything is well organized and it much easier to collaborate with other workers because each user can work in a module (I personally think things can still break too easily when more than one user works in the same part studio).
Finally as you continue to build and your part studio becomes more complicated there are a few things you can do to try and stick to that 100
feature rule of thumb.
- 1st you could roll features together (e.g. defining holes and cuts in base sketches). Although this can make editing features more complicated I believe it helps build time
- 2nd you can break up the part studio into multiple studios (create more modules of your design). This can have a decent amount of re-work.
But if you structure your features to reference layout sketches and early parent features hopefully not too much will break. I haven't had to do this yet but I imagine the work flow would be make a copy of the part studio you want to break up. Suppress the features which will belong to the
other part studio, and start fixing the broken features. Remember any static reference shared between two or more part studios should be defined in the layout sketches, which you can always go back and add if it wasn't there initially. Once all the part studios are fixed delete the suppressed features. Rebuild your sub-assemblies. This is where having layers of sub-assemblies can really speed things up and you hopefully only need to re-fasten a few things rather than dozens or hundreds.
Your main assembly should be easy to update once the sub-assemblies are updated.
Well hope that didn't confuse you too much. Feel free to reach out if you want me to explain further.
Anthony
Interesting...
I want to experiment with that tonight..
Especially breaking down a studio into smaller modules.
John & Dylan I like Cody's video stating that if things move put them in an assembly. The other one is "instancing" which means multiple use of the same part in a design. Part studios don't handle this well.
Seems to me that part studios should be added to sub-assy 1st before adding to a top level. This follows Anthony's ideas as to incontext referencing and that this sub-assy can hold all the references between 2 part studios. Seems very organized to me and a great way to maintain incontext reference.
Anybody build a BOM from all of this? Are instance counts correct?
I've been toying with instancing theory in part studios since i've started,
Normally we draw one part at a time, and bring in into an assembly.
but with Part Studios it's nice to be able to make your whole frame in the same place and add to it.
But what I've been experimenting with is: Is it better to make the additional parts and not use them in the assembly until you make the unique... or just leave them out of the part studio completely until you need them.
I'm still up in the air on this, It's difficult to only design half a frame in a studio, but at the same time it is faster to update because there are less unused parts laying around in a studio.
anyone have any thoughts on this?
I'm struggling with this also, I don't have the perfect division. Have you played with incontext? It's kinda like a partstudio in functionality. My fear, as in the SW space, too many references will be made making a project a bowl of spaghetti and un-usable.
Have you worked with BOM's yet?, maybe this will help us , a decent BOM would be nice.
That's why I'm liking the derived layout sketch approach. It gives you top level controll when you want it, without remembering what and where all of your in-context references are.
Honestly there needs to be a table somewhere on the document level that lists all in-context studios, and notes for us to remember what they were for. One or two aint bad, but I'm thinking if you have 10 of them and somone else comes by to help out. How do they know how you structured all these in-context relations without looking at each studio one by one.
BOMs are all managed 3rd party, so there's that....
The one I've used the most is OpenBoM, it's ok but both bom apps on the store are bearly a thing, compared to SW BOMs at least. But I'll give it time
I really hope to get a BOM out of OS without 3rd party. Hoping I don't have to write that myself. I've used Lou's google doc's linker and think it's really good. I'm not a real fan of putting data into a spreadsheet/google sheets.
Have you looked at the comments? They seem to be a great method for communicating design intent.
but they need to show comment icons on the tree or by features, even if the comment window is closed. Or else nobody knows to look for them.
Do you know where a good tutorial for fully customizing columns and such in Lou's BoM?
I agree having 3rd party bom's suck, because you need to log into the BOM app, I haven't even tested sharing a BoM, or if it is shared as part of the document. Rather than it just living inside the drawing sheet. But I do need to export it to a database after release anyways, just mean's I have to manage it in 3 places instead of 2...
Lou showed me his google doc's interface right after he wrote it. It's shows the power of the cloud and how linked everything can be. He help me set it all up so of course it worked. I haven't played with it since, but I should.
I don't even know how to create a BOM in OS. Maybe that's what I'll do this morning is to figure out BOM's in OS.
I'll get back to you,
Insert using Onshape BOM Sample:
Trying to get this into a drawing:
-Added APP Onshape BOM Sample
-Created csv file and uploaded into a tab
-BOM data isn't working doesn't see tab "top.csv" which is a file
I have to be honest, I'm not interested in a drawing with a table listing items.
I already had Lou's App loaded in google's sheet:
-App had to update
-Had to cut'n paste URL into a text box, I'd rather pick from a drop down list
-It works pretty well
-Doesn't have any structure like sub-assy info
-It's a data dump of a document and I'm not sure what a document is used for.
OpenBOM:
-didn't load it
-I feel OS should do this
My ultimate goal is to create an order inside McMaster Carr but this looks like it's a long way off. Sent McMaster asking how to upload a google sheet to their website. We'll see.
Right now I think Lou's app is the best, wish it had a few more configuration options.
Kinda stuck, I wanted to structure my assemblies to get a good BOM.
I've never heard of a BOM connecting to a manufacturer to be honest. Usually you hire a guy to do that for you. "Purchasing"
The first screen shot you posted was a BOM Example App, which is an incomplete BOM sample for developers to learn from I think. So don't us that one
The second screen shot, You need to click the tab that says "BOM Apps" in order to see your generated BOMs.
As far as OpenBoM, What do you mean, you feel OS should do this?
If you mean OS should handle BoMs.. then.. yes.. I agree, this 3rd party s**t is just f*ing stupid... but I'ts what Os wants to do, so whatever..
As far as structuring your assembly, That's something you have to come to terms with, with any CAD software's BoM system... Sorry, But that's life dude. Garbage In, Garbage Out..
What's a BOM app? Isn't Onshape BOM Sample a BOM app?
I guess I don't get how to add a BOM to a drawing.
And yes, OS vs. OpenBOM, I think OS should supply a simple listing. I think there's plenty of need for OpenBOM in the enterprise but we shouldn't need it to produce a configurable data dump. I really didn't expect get a proper data dump from any existing BOM API's and was planning on writing my own. Getting information out of OS is pretty simple.
So I logged into API Explorer and I'm looking at the OS backend:
Every thing's in here and there's dozen of queries to get what you want. It's simple enough to bang out 40 lines of code and get what you want.
My global idea, because it's the cloud:
Dump data into a google sheet, like Lou did, and make fine edits to the BOM list.
Then cut'n paste the data from google sheets and dump it in Mcmaster Carrs' API to create an order:
Which produces this order:
Once I'm done with McMaster Carr, then I'll hit up 80/20 and get them to expose an API. Why can't all vendors expose an order API?
Cut'n Pasting on the internet is working really well these days. When you cut'n paste from google sheets, the cut'n paste buffer contains csv data. It's properly delimited with \t & \n. All McMaster has to do is parse it which could easily be done in less a 100 lines of code. This concept is really simple.
Do you think cut'n paste is a good way to transfer lists? I hate creating files and uploading. Hoping for something more modern than the old desktop ways using files.
Garbage In, Garbage Out.. this is the way it's done today, I agree. Hoping to clean this up. When I'm designing and if I know how to create and get a good BOM listing, then I'll do it. I'm trying to get my engineering layout to do everything, even tell Pete Yodis how to build my design.
I know you've never seen any thing like this before, neither have I. But I can try, right? Someones going to do it.
Yes onshape bom sample is a bom app.. but the keyword is 'sample' it has no real function, just demonstrates how it can query your project. Really they should remove it from the list now that there are a couple others there. Or finish it and make it usable.
BEST WORKFLOWS - PART STUDIOS TO ASSEMBLYS
with good BOM's, manufacturing data, budgets, schedules....It's all tied together,
What more do you need in life? I think I'll write a McMaster Carr exporter,
It's the same with Boms and ordering stuff - if it's faster to write few things down on paper and make a call, the system has failed. Saving & sending files is something we shouldn't do, ever.
I have thought this with many cases, for example financial bank connection (in Finland at least).
With any cloud or installed software bank connections are made sending out some clomsy files with ultra secure route - do you get receit from your payment, NO - do you see the money leaving your account, NO - do you have any immediate proof that you have paid something, NO.. Next day your system might have got some feedback that transfer has been accepted.. And this is what they call Web Channel for companies
When using bank online web system for individuals and micro companies, everything is almost real time - if you could just click a button to copy & paste certain info from erp while having the secure bank webpage open inside erp UI everything would be faster and easier. And if the site would thank you by adding payment proof to your clipboard, you could click finish button to paste it back into erp. I'm sure it's too simple and doesn't have enough 'channels' to charge all the necessary fees.. And of course it would be way too easy to update since there's pretty much nothing to update - so how do you charge from nothing?
Well, someday people will reveal that barcode is only numbers and xml is only a plain text file - until that let's keep generating & uploading
Sorry for off-topic, great stuff in this thread!
Do we really want a BOM? Especially on a drawing?
Not sure where this is going, but I have this itch to fix ordering from McMaster Carr. I waste so much time looking up historical orders finding what I bought weeks ago.
Do you have McMaster Carr in Finland? I suppose not.
The problem is getting the order right. Expecting OS BOM's to be correct for what I'm doing will never happen. It has to be easily edited before submitting. I have some ideas, that may work. Like you say, it has to be easier than writing on a piece of paper and keying in numbers.
barcodes, xml, json & csv it's just text.
It's an OS document loader, documents are listed on the left, all tabs shown on the right:
It has all tab/document information when hovering over image:
Click on an image and it opens in OS:
I can never find part studios buried in documents. I wrote this to display documents and with all tabs contained inside the document.
OS document loader:
https://rndengineering.com/os/
What happens when you click on the link above:
1. your browser goes to my website
2. I call an OS server where you login
3. I can only read your document/user information
4. click on "documents"
I think this is more of an exercise to show the API and you can have access to your data. I'm not sure it's possible to write a CAD system that'll do everything everyone wants. So, roll your own, this is an exercise in that.
Nice job @billy2
In terms of documenting my structure I don't have a process yet for that. A lot of the design work my company is doing is for ourselves at the moment, and we don't need to share CAD data with people outside the company.
I'm not sure if OnShape comments would well in documenting the structure, but would work well for reviewing someone else's work. Actually what has help me most so far has been writing it out. I am interested in formalizing some sort of CAD process for people at my company to follow, of course in the case with something like OnShape this will certainly change from time to time as new features are added. So for me I think the best approach right now will be keeping a google docs page for ideas, and work flow. Comments will work well as a review tool and
track/engage design related discussions on a model.
Regarding the BOM discussion I think what you talking about building is a really awesome idea. I haven't been completely satisfied with any of the third party options available for managing BOM. To me the google sheets BOM by Lou Gallo probably holds the most promise for customization if you are comfortable with Google Apps Scripts. However my programming skills are a bit weak, so it would be a steep learning curve, hopefully this is something i can start to work on soon. Currently I use google sheets to manage the BOM, but without any automated tasks, hearing about API based ordering makes me very excited for what could be possible once I have the resources to dedicate to it.
I've turned on comment notification alerts so hope to be more active in the forums. Clearly there are a lot of good ideas out there!
When it comes layout a document/project I would start with layout sketches and maybe do some very simple block modelling in what I would call the Master Model or Master Layout. I would always name the tab "master" to try and let other know this is the master doc, but I never know where to drop this in my tab list. Sometimes I have this as the first tab but lately, I generally line up all my part studio tabs up with the master as the first. I would then use derive to transfer sketches or block parts out into other studios which become the working studios to build the parts in. I try to limit the derives and have them at the top of the tree using the rollback bar, if you have lots of derives the studio will slow and you can have rebuild error's. If I need to have more bits derived I will try to update a derive rather than create a new one. I use the in context later in the design with cross-linking parts and assembled positioning references.
I am looking for a better Onshape BOM solution, we really need to have multi-level (nested) BOMs, I use OpenBoM at the moment and like some of the features they have but really want the BOM to live in the Assembly doc and be able to interact with the properties with visual references to the assembly. The small image created in OpenBoM and also Lou's google sheet are good but sometimes you need more than this to establish the parts details.
Twitter: @onshapetricks & @babart1977
One small issue, the code times out in about 60 minutes and I don't refresh it. Delete what's highlighted in blue and refresh the screen. This will get another code that's fresh.
Next on my todo list, I'll fix the refresh and keep it logged in as long as the browser window is open.
See this mocked up example of how I want it to work.
At the moment I find it so hard to chase properties back to a part studio and into a BOM. I use a naming system on the part name to try help but don't really like doing this.
Twitter: @onshapetricks & @babart1977
Firefox showed error: SEC_ERROR_REVOKED_CERTIFICATE
Also I realised I created a folder called so for the site. 2 weeks later I saw it was a typo and should have been os for onshape. Now all my bookmarks point to so and not os. Please watch for this when the browser says file not found. It'll flush itself through eventually.
I know about the firefox issue, it's the https certificate, turns out I didn't register www.rndengineering.com in my certificate, I registered *.rndengineering.com and firefox is over compensating. I've got the certificate re-registered, I just need to update nginx to send the proper hand shake to my certificate holder. Chrome isn't so annul about such topics. I'll see about updating the certificate this afternoon and hopefully get firefox to calm down.
Once & if you get in, I've fixed the refresh token so that every 59 minutes I request a new token. This means that if you're working on your computer with my site open in chrome, it'll stay logged into onshape. In this condition the state of the website is preserved and you won't know it refreshed. I flash a refresh message on the screen but other than that, you won't know it happened.
I'm finding though that if the computer sleeps, the token doesn't refresh and expires. In this case, I now re-login into onshape automatically. Unfortunately, I lose the state of the site and in this condition the documents will be at page 1. Sorry, I'm not going to generate any sessions logging your state as this is a high use website 10,000 hits/second and sessions are out dated. In the future, and if you register, I'll be able to log into a DB the website's state so when a re-login occurs, you'll never know it. Currently my only global variable is the document's page variable. Not sure it's necessary to make people register, store website state just to track this 1 number for the re-login condition.
I already track which notes a user's read so I can display a listing and show what you've read and haven't read. This type of stuff requires that I track who's coming to the site. I authenticate through OS & log who's coming in, but currently not creating any entry in my database. That's coming, good news, it'll all be automatic. Once your in a database, I can remember things like settings, which notes you've read and other stuff.
Joe chewed me out for not reading the OS query spec close enough. I now display the recent files open which is the one I prefer. I'll write an interface to toggle through the various queries after I fix the firefox thingy.
Blah, blah, blah; so if you didn't read anything above, I fixed the token refresh issue.