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.
Answers
so for the simple example above,
what I would need exported would be
ASM-158 - 1
ASM-159 - 2
PRT-155 - 1
PRT-156 - 2
PRT-157 - 2
6498K847 - 1
since each part and assembly has a dedicated drawing sheet, and has a total qty on their respective drawing (which is stored in a separate QTY custom property to be read by the drawing).
The reason for this is, each department may only see the one or two drawing sheets relevant to them and will not be held responsible for adding up the entire system worth of parts.
It's like you should have put your linkage arm weldment in a folder versus ASM-158.
I'm thinking we need a newer definition for an assembly. Promoting items to next assy seems like it could solve your problem and retain the motion in the assembly. The problem with using folders is the motion mates are all in the top level which is undesirable.
This didn't have the effect I was looking for and doesn't produce what John wanted. I always use flattened and now I know why I don't want the structured output because I don't know the part count without multiplying the assembly instance count. OS is doing it correctly based on the way it was done in the 1980's.
I always used flattened BOMs but I'm usually the designer, engineer, buyer, machinist and assembler. I'm always referring to my layout throughout the process verifying what needs to be done. I think in a real company setting, a better structure is needed so people don't have to refer to my layout to make decisions.
what's a bom?
I think we're looking for a mBOM which lists assemblies & all parts but I think we'll be waiting for Adrians "promote" before we get an mBOM option.
Can you use configurations to control a BOM? Absolutely.
I've added an additional link to my branch and the BOM updated to 3 links:
I've added a config that suppresses this new link and the BOM updated to 2 links:
I'm not sure this is for everyone but could be useful to those with certain structural designs. One of the problems comes with deep subassys and calling the bottom layers of the tree. Every sub-assy from the top to bottom must contain a config to carry the command down the tree to the bottom layers. It's a lot of work to tie everything together and requires someone dedicated to keeping it working. I'm not sure this style is good for a large team of designers especially if the team is defined as every man/woman for themselves.
This cascading configuration pattern is also useful to showcase a variational design on the web with controls showing changes in the design. I think once people create websites that can showcase their products, this will be a dominating assembly design pattern.
@CBowers if you can share your document with me, I can post it on my website and your configurations will work. Don't do it if it's proprietary.
Twitter: @onshapetricks & @babart1977
So, BOM management is critical because it affects all parts of a business. Unfortunately, it's difficult to do well for the exact same reason.
A design tool isn't going to have all the capabilities needed to forecast and purchase materials. MRP and ERP tools, even if they are well done, exist outside of the CAD world, so the designers creating the product may not have direct access/control of the final and complete BOM and would have to rely on some sort of integration to sync information back and forth. And then, all of the people in these different departments need different representations of the same data set.
Hopefully these challenges are easier to solve as more things move to cloud native technologies.
This is my preferred style because it's simple and gives me what I need. I don't care about top down documentation that drops down nicely from the top and trickles up from the bottom, instead I do what it takes to get the job done.
Added another branch to the Public "bom" document listed at the top of this thread.
Added some complexity to the initial design to show off flattened BOMs:
Above is now 2 non-deterministic linkages governed by a new link. I have failed to mention in this thread that I like the assemblies in OS. It's fun to move this design around because it acts like it's real.
So flattened removes all assemblies from your BOM structure and gives you only parts. That works for me:
Notice that I'm mixing partstudio parts with nested assemblies and there isn't a problem creating a BOM.
Changing the configuration of the tie rod connector length gives me an updated bom with the rod length change in the BOM, thanks to @Evan_Reese and "Part Name" featurescript:
Note:when using a feature script to update part properties based on configurations, please keep in mind that properties that have been set at anytime will not update with feature scripts. You have to reset all in the property dialog box which clears all properties that have been set.
If I need to document something, I just do it without regards to how it fits into a top-down structure. Who cares what path is taken to get something done?
In the past we had top down:
Let's give up and move toward a center centric structure:
If you need an exploded view, build it. If you need operation instruction sheets, build it. And, most important, if you need to design something, create a layout. Engineering data does not have to migrate to manufacturing data. Manufacturing, build your own documentation.
If we can get that implemented in Onshape that will be a huge start.
Please vote this up: improvement request
The public "BOM with configs" document was created to try out different ideas incorporating BOM methods and to allow multiple engineers to work in the same document without clobbering each others work. This is how it works.
BOM with configs
The initial version:
An initial version was created of a simple assembly containing some parts and a library component. All of these items where made public.
Those that have share privilege were asked to branch the initial version to create their own workspace before developing their ideas.
-John created a workspace "adding sub assemblies".
-Bruce created a workspace "B5 Bruce Bartlett".
-I have created workspaces "config bom" & "flattened bom"
If you open the public document "BOM with config" you have to open the Versions & history tab to see all the workspaces contained inside the document. These workspaces contain all the different ideas on how to build a BOM. To access these ideas, just click on the workspace. The whole idea with setting the document up this way is to allow us to collaborate and develop ideas and most important is to be nice to each other.
Adding my ideas to John's workspace:
-I versioned John's workspace
-I branched this version to create my own workspace of John's work
John created his own workspace (RMB on a version and clicked "Branch to create workspace") and proceeded to reconstruct the initial release and added subassemblies. To add to John workspace with my ideas, I versioned his workspace and created a new branch for my ideas pertaining to his ideas. The purpose for doing this, John's workspace is not affected by my changes and his workspace remains the same. This is a nice way to setup a document where many engineers are developing ideas and you don't clobber each others work.
Contributing to the document with a new idea:
-Matthew has an idea dealing with my "config bom" workspace.
-Matthew needs to version this workspace.
-Matthew then creates his own workspace branched from my workspace.
It's a simple way to share ideas in an organized manner and allow ideas to develop without messing up other people's work.
Matthew can now add his idea's to my workspace without clobbering my work:
This is a simple collaboration pattern that everyone needs to learn and implement. If you're new to CAD, a student, learn this pattern so you can show all the older, seasoned designers a new trick. This simple pattern is going to be extremely important in the future and without knowing how it works, we'll never proceed to where we need to be.
Note about public documents, when you create a public document, the world can't edit your public document without making a copy of your document. If you want to contribute to "BOM with config" you have to PM me your login email so I can add you to the share tab. Please don't post your email in this forum.
Exporting data from OS is fairly simple:
Spreadsheet containing BOM:
It's not a simple translation and after looking for a simple "no code solution" I've decided on writing 10 lines of my own code to parse the JSON file and create the BOM I want.
If someone knows of a good "no-code solution" that can handle parsing JSON, please let me know.
I'm considering writing a BOM exporter using an NPM library called "object filter" which is basically a one line query tool for objects. It'd be easy to write a "promote up" for assemblies and any other wild BOM that comes up in the future.
Let me know if this is something you'd use.
more details
Branching & Merging
The problem with current CAD systems is distributing engineering documentation to other departments doesn't work. Currently it's a one way street with data flowing out of engineering to departments and it becomes disjointed from the original design. Engineering and manufacturing are 2 different worlds and the data is different for both of these organizations. But why can't both data sets stay connected?
In the beginning of Onshape the concept of branching was thought to be the answer to this huge problem and could keep the company's data integrated.
link to document
Below is a complete design that needs distribution to shipping, testing & manufacturing:
We create different branches off of a version called "distribution" and share the engineering design with shipping, testing & manufacturing.
Shipping adds a box to the design:
Testing says a longer link works best:
There's now a longer link in the testing workspace only.
Manufacturing changed the center connecting point on the link:
To prevent manufacturing from having to learn the engineering models and design intent, they should use direct modeling to make changes to the model. With direct modeling you don't have to have an understanding about how the model was put together.
Manufacturing changed the attach point for the link without learning the design intent:
Notice manufacturing doesn't have the longer link that testing made. That's because testing hasn't been merged with manufacturing.
To combine all departs work we merge shipping, testing & manufacturing back to engineering:
Above show's all department's ideas merged into engineering.
At this point engineering can modify the model's design intent keeping the model pure. Engineering should be the only department working on the model.
After the merge is completed with engineering, engineering's data is updated. Now engineering can merge all changes to testing, shipping & manufacturing keeping all departments in sync.
This is an attempt to keep a company's document intact while sharing between all departments.
chadstoltzfus@premiercb.com
As far as Google Apps Script, I'm worried it's not enough. One thing I wanted is to parse a JSON file but I'm not convinced it's possible. I like coding so "no code" needs to great and powerful to convince me this is the way to go. I'm not convinced it can do what I'm wanting especially when it takes 10 lines of code to parse a JSON object.
I don't really want to create something that I have to configure and would rather have it customizable by a user. Everyone wants something different from engineering data and these "no code" solutions sound interesting. I need to research more what they are capable of doing and make sure they'll work.
@lougallo created a link to google docs a long time ago which had a lot of promise. I'm wondering if we're ready for a newer one?
Have you played with it yet? A lot of people like it.
If I can speak for Greg for a second with the little bit I saw,
I have not looked into a "no code" solution in Google Apps Script, and I'm not sure if there is one. But the program does seem to be fairly powerful for those that know their way around code. You can create a framework by coding with Google Apps Script in the same way you can create your own framework with node.js or PHP or any other HTTP friendly programming language. This homebrew framework can be structured to make API calls by directly reading a cell. For example, you could link a cell to a configuration, and that cell would become a drop down with the configuration options, and other cells in that table could give values that the selected configuration generates. So this workflow is working almost exclusively in Google Sheets, not evening opening Onshape. To me it seems just as malleable as developing a custom framework in PHP like my company did.
We did some experimentation with Link Tab and found some success. We use Excel Online so we needed to do a bit of tweaking to get something close to what we wanted. I could imagine a Link Tab housing the BOM instead but the transfer of data to a sheet being used in Link Tab would still need to be either done manually or with some API calls.
chadstoltzfus@premiercb.com
OS has 2 BOM outputs:
-structured=total assemblies
-flattened=total parts (ignore assemblies)
I think most get stuck using one style of BOM and ignore the other. Myself, I tend to use flattened to get the parts I've used. Others, tend to use structured and then complain about not getting parts. I believe there needs to be a 3rd type that combines the output using a "promote" algorithm on assemblies. Although this sounds good, I'm worried this could be a temporary fix and what we need is far more complicated.
Supplying data from engineering to a company seems to be an ongoing issue that's masquerading as PLM, MRP, ERP and many other acronyms. I'm not convinced there is an easy solution.
I know you can get the data from OS using it's api and have spent the morning trying to prove to myself that a "no-code" solution was right around the corner. Is this something that could easily be bolted onto OS? I don't think so. In the future, yes.
Google app sheets uses .gs which is a form of javascipt and can handle objects. The problem is that "no-code" solutions only deal with 2 dimensional spreadsheets and don't really parse JSON objects without some "code". The best solution I found for converting OS JSON objects to meaningful data was zenphi.
link to zenphi
It's not cheap and not for most people in a company, it's possibly out of scope for this thread.
I think there could be a solution for OS to push data throughout an organization but it won't be called a BOM. The challenge is to make it so anyone can build these reports. OS does make the data available and is presented in a cloud friendly format, there's just no way to consume it, yet.
@chadstoltzfus what you've done is special and something I'm very interested. After 8 years... of OS I'm surprised there's not more activity like you've accomplished. An interactive cloud model for a company's products. I'm not sure why it's taking so long. Maybe we need to start a thread on this topic.
link to my interactive cloud model
I'm just reading the configuration table in an assembly and displaying it on a website. I didn't want anyone to have to "code" and felt OS users could create a configuration model capable of hanging on the web. Currently creating these websites is time consuming, I think OS is the only cloud based CAD system capable of making this happen for everyone.
I've only scratched the surface of this interactive cloud model. I want a webgl viewer with a rendered state to show off the models and allow a company's customer to create the product they want.
Maybe we should start another thread on this topic, I'm not sure this thread is about this topic. I would like to know more about your experiences.
CAD Engineering Manager
I'm not feeling comfortable with this share the BOM in a spreadsheet experience and I'm thinking this isn't the way for an engineering department to propagate engineering data throughout an organization. Exporting a CSV from a BOM seems like an inefficient process for disseminating information. I think the cloud could be much better.
These things are true:
-Onshape is a well written cloud app
-The REST API is here and available
-JSON is a viable transfer language
-Cloud data is ubiquitous and you only need permission to access it
This will be a long post and I'll show you how Onshape's API can be used to share engineering data perhaps changing things forever.
Onshape, the world's only cloud based CAD system has incorporated a modern cloud based API making all the data contained inside accessible to whom ever has the appropriate permissions. With this why can't we share our engineering data? In this post I'll explain how Onshape's API works, define JSON & introduce a "no code" solution to build an engineering data disseminator. Is it too soon?
REST API
The REST API is a simple way 2 cloud applications can exchange data and is quickly becoming the standard in the cloud. When discussing a cloud application, don't be afraid to ask about their REST API and how do they accomplish this. Many companies are struggling with this basic concept so it's important to ask this question.
JSON
JSON was created by Douglas Crockford in 2001 by registering it with ecma. History of JSON. JSON is not complicated and it's quickly becoming the cloud data transfer mechanism. Onshape sends its data using JSON.
JSON Deep Dive
Simply explained, CSV can contain 1 spreadsheet, while JSON can contain any number of spreadsheets and each spreadsheet can be accessed easily:
object.spreadsheet1
object.spreadsheet2
Why would we want to use CSV?
Glassworks
Everybody has access to their Onshape data. Glassworks is a new Onshape API viewer and is really nice.
play with Glassworks
There is so much engineering data available to your organization, why not use it, here it is, go for it? You must be logged into Onshape for glassworks to access your data.
how to use Glassworks
Zenphi
Zenphi is a new cloud "no code" workflow management tool that can parse JSON and makes the data accessible. You'd think with all the "no code" systems available today, asking for a JSON parser would be a common topic. A google search on "JSON parser and no code" returned only one result which was a link to Zenphi.
zenphi json parser
This is the video which got me excited about Zenphi.
I have had several meetings with Zenphi and I'm very impressed with their approach parsing JSON, formatting data & then distributing this information throughout an organization.
Conclusions
I think we've all used BOM data buried inside spreadsheets and shared with others in our organizations. This works fine until the next release and then you get to do it again. Watch @john_mcclary video and imagine performing that dance weekly without making any errors. I think with the cloud, we should be able to easily build workflows that distribute engineering data throughout an organization. With webhooks enabled, you can bind a release action inside Onshape to a workflow inside Zenphi and do all this busy work with one button click.
If you're interested in Zenphi, send them an email support@zenphi.com and talk to Machel about Zenphi and Onshape. I've spent a lot time playing around with the system and believe it'd work well for distributing engineering data throughout an organization. I've told Zenphi that I'd be happy to work with them integrating api-keys or oauth to link the systems together and build a new seamless cloud tool to securely disseminate engineering data to the world.
A lot of other discussion has happened here. Hopefully some of the more advanced things make their way into future PLM integrations.
It isn't for a lack of trying to move to the cloud.
But an organization is a difficult thing to work in new strategies.
Some people (especially those born before the 80's) are very toxic when you try and introduce something new that requires learning a new computer app.
It takes small steps and little nudges or else the new tech just gets ignored completely.
Just look at the metric system in the U.S.
Most people don't want to learn it at all. Those of us that have, apricate its simplicity, but can't convince the Olds to stop converting to inch when then have mms on their tape measure already...
But scientists, doctors, and the automotive industry have adopted it and are just trickling it in slowly.
That's the basic approach I've been taking at work.
So far I've got everyone using Onshape to open PDFs, which is slowly teaching them how to log in and open a document and navigate tabs.
I've got them using discord as a company telephone and meeting place. (All it took was showing them how to search and post a meme)
That may have backfired a bit though:
baby steps... :P
If I were a salesman I'd remind you of the inefficiency with your process. Not so much the time to do it, but the time spent fixing things and keeping it moving.
John, I could never keep your system going smoothly, wouldn't want to. I'd automate it.
Guys I'm trying to push the capabilities of the cloud and wish we could abandon our past. I'm thinking that we should never try and switch or migrate to the cloud. The hybrid cloud is a bad idea. I'm thinking a clean break is best.
When moving to the cloud, I'm thinking a company should run parallel. Keep the old hard drive stuff but develop a cloud solution for what it can be but don't have it duplicate your old system.
John you should talk the Zenphi guys about your problem. They keep telling me if it's a workflow, they can map it. You're already building things in Onshape, take it one step further and automate the workflow. If you had 1 click workflows, I'd never tell management and spend the extra time fishing.
I spoke to Vahid Taslimi one of the founders of Zenphi about distributing engineering information and he didn't speak in terms of PLM, ERP or MRP; but instead spoke about workflows and getting this information from this department to that department. With all the "no code" companies out there promoting workflows I'm not sure PLM, ERP and all the others can't be grouped into 10 different workflows. It seems like "workflow" is the new buzz word. He said they had many engineering companies using "no code" solutions to distribute information throughout their organizations effectively. A drawing with a BOM could be old fashion.
Zenphi is a new startup based on a bunch of guys who wrote a "no code" solution for the windows environment and then sold it. Instead of sailing around the world a couple of times, they decided to focus on a "no code" solution for google's workspace. It's really slick to watch what it can do because, obviously, google is cloud based. Watch their videos, it's pretty interesting.
You realize that you can ask Onshape for updated images allowing you to update exploded process instruction sheets after each release. With the new drawing API, it's going to be easier. How many times have you gone out on the process floor to find them working to documents 2 revision back? I don't think it'd be much work to have Onshape talk to google sheets, docs & gmail and build updated process instructions for the shop floor. Beyond a BOM, you can access a lot of information from the Onshape API. Basically everything & anything. If you had a 3D viewer, you could send gltf and spin the updated models on monitors stationed around the process area.
I think John's problem is a process problem and not lifecycle issues. I think he needs some workflow management tools to get engineering data out to manufacturing.
The funny thing to me is google workspace. I switched about 2 years ago, I like it. I'm all cloud now. Most solidworks companies are burdened with microsoft excel and word. I'm not sure how slick Zenphi would be when burdened with outlook.
I'm thinking if a company was using workspace & onshape, it'd be easier to build workflows to distribute information throughout an organization.
It's going to be interesting how all this pans out.