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.
Doc control, rev control, configuration control...
Mecha
Member Posts: 7 ✭
I figured this would be best done as a new thread. I have been looking at the control scheme (similar to a lot of software development cycles) and am very curious as to how this will translate to engineering rev control methods.
Will there be a way to develop a release process, including sign-offs, prior to a file being able to reach a released state? Its great to have the ability to control updates, but if that means off loading PDM function to manual decisions, I am leery.
Will I be able to work on subcomponnents of an assembly and update them automatically, or will the process forever be manual? (example, I am reworking a part in an assembly.. during this process, I want the assembly to reflect the old part.. but when released, I want the part to be updated to the redesign.. but not require a rev to the assembly itself.)
Configurations: I am personally not familiar with Code control methods of trees, branches, merges, etc... It looks like there is a way to create configuration, but again, how to control them?
Im probably just scratching the surface.
Just to start out the gate, a lot of environments I have been in require pretty solid doc control. Up to the prototyping stage perhaps not so much, but when we start to get to pilot builds, it gets pretty important. So much time is spend on control, I would really love a integrated solution.Scott said:In general, since versions in our system are immutable, if you link to a version that link will remain stable. You may get a notification that a "new version" is available that you can optionally update to. The idea is to let you control any updates so you will never have an assembly blow-up because of a change in a document that you link to or change inadvertently.
Will there be a way to develop a release process, including sign-offs, prior to a file being able to reach a released state? Its great to have the ability to control updates, but if that means off loading PDM function to manual decisions, I am leery.
Will I be able to work on subcomponnents of an assembly and update them automatically, or will the process forever be manual? (example, I am reworking a part in an assembly.. during this process, I want the assembly to reflect the old part.. but when released, I want the part to be updated to the redesign.. but not require a rev to the assembly itself.)
Configurations: I am personally not familiar with Code control methods of trees, branches, merges, etc... It looks like there is a way to create configuration, but again, how to control them?
Im probably just scratching the surface.
Tagged:
1
Comments
Also, since Onshape is a CAD system built around a data manager there will never be a need to 'off load' to another PDM, Onshape is a data manager. We will be adding workflows and process control (as you say no manual decisions) to govern your release process. Since all the data lives in the Onshape database you will have power and flexibility that you just can't get in a bolt-on PDM.
It sounds like you also would like the ability to configure your assembly with a particular component or subcomponent to be 'cut in' at a particular date; again since we own all the data setting effectivity (or allowing a partner to do so) is possible.
We haven't released a method yet to manage configurations but that is coming for sure.
Have you looked at 'branching' in the version graph? You can develop separate alternatives then merge them together. it's awesome.
Also, check out "workspace properties" where you can set the properties like description, part#, Rev. of parts and assemblies. The State (ex. Released) can only be set during the Save Version operation.
Onshape team,
Great job adding in the ability to specify part # and version # and have an official release version with branching capability! This is the future of CAD.
My suggestion is that you make a built-in BOM list attached to the released versions and branched versions as well as the ability to share these BOM lists through emails or a link. This is just like the assembly parts list available now through the "Properties" under the Documents menu, but I'd like to be able to add parts that don't exist in the CAD model such as purchased parts and miscellaneous hardware and be able to add their part numbers, manufacturer names, etc.
I suggest this because:
1) SW BOMs dont work well
2) PDMs don't work well and they're expensive
3) My workplace uses excel BOMs and WOW! What a mess!
4) My CAD models are never complete. I use tapped holes in SW, but I don't waste my time putting a bolt model into my CAD assembly because it's slows down my design flow and all those bolt splines eat up processing power. However, I still need to have a BOM so I know what hardware to order when a machine is going through a purchase order.
Basically, when the BOM can be copied, altered, and overwritten like an excel file, there exists a chance someone will make a mistake. We usually get the job done, but there a few occasions when something happens like some bag o' stupid spacers wasn't ordered and it halts the assembly.
With that said, here is my suggestion:
First and foremost, I'd love an integrated BOM with the ability to share a link that shows a BOM. It wouldn't give editing capabilities, just viewing capabilities. I'm really pushing for this one because I think it'd be a key feature to further expand the collaborative environment you guys are trying to accomplish. If done this way, the BOM will stay in one central place instead of the aforementioned multiple locations. It'd also encourage people to view the BOM link and NOT send or receive emails with files that could potentially be infected with a virus or contain incorrect data.
I'd also like if the BOM could be made multi-layered. What I mean is you could have the BOM behave like your parts studio tabs. It'd be preferred if this was done with the pop up window you have in place now for the "Properties" option because it doesn't force the browser to reload the CAD model when it is closed. This tabbed system could allow me to break down the project into smaller and more manageable BOMs during the manufacturing and assembly processes. I could have a BOM tab for purchased parts, waterjet parts, CNC milled parts, CNC turned parts, etc. If BOMs could be concatenated then I could combine these separate BOMs into one complete BOM for the entire machine.
As far as exporting to an external file goes I realize a static, locally saved document would be necessary for many obvious reasons that I won't bother to list.
I will be honest with you Steve, I think it would be in the best interest for Onshape to be able to export to most format types. This would include PDF, picture formats (.jpeg / .gif / .png), Excel and a few other I can't remember at the moment.
The point is, that as long the BOM that I want to share can be viewed from one place, the local file format won't even be an issue for me anymore. If my machine shop wants a jpeg, the CFO wants an excel spreadsheet, and the engineer wants some else... fine, but at least they won't be changing the official BOM by accident or sending each other the wrong versions.
Later this week I'll make a picture showing what I'm describing.
Also, I'd like to show you guys an example of what my coworker does to achieve this idea, but I'll have to make sure it's ok with him and then set up an interactive link that contains examples.
Please keep 'em coming.....
Best,
A good PDM system, is easy to set up and manage.. I am not sure why there are people saying otherwise. In fact, its required for many industries (anything that mandates ISO-9000). I am honestly having a hard time adjusting to the tree approach, but as long as it can work well with a decent PDM/PLM that is the important part. Just doing something different because you want to be novel will generate a lot of industry resistance.
If there was one thing I would want, is to be able to collaborate with groups. IE if a assembly is in design, its files, BOM, etc could not be seen by people outside of those assigned to my design group. When we get it to a point where it is releasable, and there was some sort of check and approval process (built in ideally) then it becomes viewable by other collaborators, (machine shops, purchasing, etc)
The core principle here is one data source. That is the issue that affects every company. Ideally you want a system that pushes data from production release BOM to accounting systems. In the UK Sage is quite widely used, and I know a lot of 2-5 seat SolidWorks using companies who use that and link SW BOM to Sage....but it is not a live link. It relies on a manual export>import process in most installs. Which is fine if your quality systems build that process into the production release and order place procedures. But mistakes get made ( staff changes, rush jobs etc).
Bottom line is document control is not just a CAD function, and to be truly integrated you have to build links into other common systems.
4) My CAD models are never complete. I use tapped holes in SW, but I don't waste my time putting a bolt model into my CAD assembly because it's slows down my design flow and all those bolt splines eat up processing power. However, I still need to have a BOM so I know what hardware to order when a machine is going through a purchase order.
Don't you use cosmetic threads for this? I think most CAD systems around now handle hardware like fasteners pretty well, for machined threaded parts anyway (custom plastic threads are another issue entirely). The pain point in BOMs I find is the inclusion of non mechanical parts like glue, paint, labels etc. some systems handle that better than others.
I use cosmetic threads to indicate a bolt placement like you mentioned. What I don't use (or should say "rarely use") is the bolt model.
The model just has to convey what I need manufactured, and bolts aren't part of that list. I would only use a bolt model if I need to check collision points or tool accessibility, but there is no real benefit to adding bolts if the intent already exists from using the hole wizard. The BOM and photographic installation instructions is where I would show the bolt, just not the model.
The other reason for not using a bolt model is because it invites mating parts to the bolt or the hole and this is a big CAD design no-no. I'd almost never want my holes defining part locations because the parts will move out of place to fix the hole alignment if changes are made in the future. Instead, I try my best to mate with planes or faces that are unlikely to change and dimension the hole location wherever it makes the most sense.
In my haste to write my last comment, I forgot about the bolts in the SW toolbox since I don't own this tool. Yes, the cosmetic exterior threads should be the only way to apply bolt models unless otherwise needed for things like FEA or 3D printing.