Suggestions for workflows with manufacturers?

julian_leland

Hi all,

I'm getting ready to cut parts (built in OS), and am working with a vendor who has agreed to take a crack at working entirely through Onshape for both quoting and production. The vendor is a forward-thinking, tech-savvy guy, but also has a business to run, and I don't want to make this a time sink for him.

I'm curious if any of you who have done this already have any suggestions of optimal workflows for sharing parts with vendors. Confidentiality isn't really a concern, but I want to make sure that it's clear a) what the final released version of the parts is, b) what the critical features & tolerances on the parts are & other non-included information (coatings, materials, etc...since we don't have drawings...), and c) how the whole thing will be going together, so that the vendor can understand the parts in the context of the assembly.

Right now, what I'm thinking of doing is:

1. Upload a PDF with lots of images of the parts and assemblies showing critical tolerances, etc.
   
2. When parts are ready for quote, save a version and create a branch called Production.
3. In that branch, delete all tabs that aren't immediately relevant to the project (I have lots of old sketches and concept parts, etc.)
4. Get the parts quoted.
5. Based on vendor's feedback, tweak parts in main branch and update PDF; merge back to Production branch.
6. Release parts in Production branch, and save out appropriate filetypes (STEP, Parasolid, etc.)
7. Vendor cuts parts.

Thoughts? Does this seem reasonable, or are there stumbling blocks I'm not seeing?

billy2

This is how I've been doing it:

Please click:Link

It's easy to distribute and maintain revisions. The amount of time to create this web site is fractional compared to creating drawings and using this process seems to have less errors than the drawings & email bleed. I try to show the design and any tight tolerances, tolerances & fits. 

It's important that the manufacturer doesn't have to open any files to quote which makes it faster on his side.

I don't typically upload SW files and use parasolids binary, when I export from SW is when I add a revision to the file name. On the web I add a note as to why I changed the part.

When I update, I send the manufacturer an email and a list of files that have changed. 

In the spirit of the cloud, there is only one location for this information and it evolves.

I'm not sure if OS has the environment that I want to expose to manufacturers at this time.

john_mceleney

@bill when you say you're not sure OS has the environment that I want to expose to manufacturers, what do you mean?

brucebartlett

I've found you can save the print preview as a png. This is another option instead of screen shooting.
@bill this looks good, almost like the SW's MBD.

I'd like to see the ability only to share parts of the document eg. only the branch you want the vendor to work on. In some case's it would be better to share parts as single parts, not whole design studio's giving away the IP or confusion of which parts are to be quoted.

pete_yodis

Just thinking out loud. Onshape, why not let the vendors quote their pricing right in the interface of Onshape? Could be branch specific, too. This would be really nice for cost simulation rollups. Think MFG quote like... or at least partnering with them.

billy2

I don't think a manufacturer needs to figure out what I want to make. It has to be a list of this & that with qty, materials & finish. I try and not have the manufacturer open any files to quote. It has to be straight forward. No pdf's, dwg's for quoting. I do supply the machinist a 3d cad file for programming but he shouldn't need to open for quoting purposes.

With most of my projects, I talk with the manufacturer and tell him what I want using assemblies and annotations on the model. I use screen shots of sketch dimensions and annotations to convey what I want followed up with a conversation.

Hole taps are still an issue because they are lost in parasolids. My machinist tells me the tap drill hole is always correct and all I have to do is run a tap through holes that he misses and doesn't tap.

One thing spaceclaim did that I really liked was to change the face color for all surfaces pertaining to a cosmetic thread and the entire feature. Even though the meta data gets stripped out during a parasolids translation, the face color is mapped through. I like this. Wish the meta data (thread type) passed through parasolids.

I've tried sending them assemblies with multiple machined parts in one file and they don't really like working with 20 to 30 parts in an assembly/part studio/what ever. They want me to parse each part into it's own entity. I see this as a limitation on their part. Most my time spent on cloud manufacturing is parsing everything down into a presentation of single entities for them. Still is a fraction of the time spent on drawings & the email bleed.

Turns out it's the receptionist who sets up the job has trouble with many parts in one file. The programmer doesn't really care. But, this creates chaos in every machine shop.

OS needs to parse the different parts into waterjet, machining, printing, purchased & purchased modified. I was hoping for layers to accomplish this and show the various components based on categories. What if you have 2 parts in a part studio? OS needs to parse these into separate entities. OS needs properties to handle materials, qty and other things involved with manufacturing. The #1 thing is to have annotations that get captured and telling a manufacture what's going on. Creating attachments that have to be opened on his end slows everything down.

I don't see a manufacturer going through my document/project trying to figure which production branches need to be quoted. Also branches work on documents only and not at a part level so this isn't possible at this time.

Can you open up the API and I'll write a manufacturing parser?

pete_yodis

@John_McEleney I wonder if the current status of Onshape will be too, "CADDY" (no longer just a verb now). I think this was being hinted at on the big discussion on the pricing and plans thread just the other day. I think this is what some of us mean by a viewer only option. Something drop dead simple. @KevinQuigley was mentioning an easy URL link, with no signup needed. YouTube does not need a sign-up for viewing. Was that what you mean @bill. I think Onshape can be far more than just CAD in the cloud (I'm sure you have plans for far more, too) - it could be the centralized design platform for all things design and sharing related.

billy2

Shade & Spin with annotations & dimensions. Give me a url and allow me to show my models on my web page. I'll create the web page and call your servers. Joe told me you won't create a webgl standard allowing me to spin my models on my web page. I don't like this approach and would rather work on the OS data. Not really wanting to sync my web 3D content to OS servers.

How fast are you? If I create a web page with 50 calls to OS for 3D content will you be able to keep up? I'll need the meta data sent back to me also. I prefer json for information about the content.

Are you guys planning on using Angular Directives or jQuery to extend OS?

Are you going to make me register like google maps?



I think we might be getting off track from the original post or maybe not. I could make a bitch'n manufacturing interface.

billy2

Bruce-

I have a screen capture program that I use & it saves the images to files which then I post to my website or this forum. I use it a lot. No need to print to png. I publish most my stuff to the web and have been for many years. I keep all my reports & notes on my website. If I have to publish something for hard drive folks I'll print my web page to a pdf so they can open it in a file viewer. Seems so backwards! The link I give them never changes but nobody saves the link, they want the pdf.


The little bit of SW MBD I saw saved things to a 3D pdf which I'm not a fan of; strike 1, 2 & 3. Pro/E part files were supposed to stand on their own and this was 1987. We still don't have it and I'm not sure SW will make it happen. I think OS has a better chance at making this happen.


I noticed your weldment and saw that it was in mm. Does your shop work in mm or did you change the units to mm and capture the image? I did a mountain bike frame similar to your design and gave the shop all coup'd pieces as well as an overall weldment layout. It's one of the times I actually did a 1:1 drawing so they could print out the layout and weld on top of the print. For the coup'd pieces no drawings as they were hydro formed and we worked only from files. They managed to fixture and machine all pieces then put them in fixtures and welded. I managed 4 bike types with 4 different sizes each. Did it flawlessly. If I had created drawings & emails, I would never have finished and the manufacturer would have some new names to call us engineers.

billy2

Bruce-

When branching are you deleting the items that aren't machined? What would happen if you needed to put one back after deleting it? I guess you could suppress the delete, answered my own question.

I don't use versioning & branching much.

Using versioning more than branching, seems to me "versioning" should be called "save". The branch only occurs when you want to make a change to a previous version. This doesn't happen much for me. Not sure why. Maybe it's my single track mind.

If you make changes to the model, then you have to version & branch again to create your manufacturing data structure. Not sure I want to sign up for this. Parsing the data is a lot of work and not being able to roll a branch forward isn't cool. You can't change a saved version so this won't work. I think you're screwed having to re-branch  and re-create the entire manufacturing data structure each time. This is a lot of work.



Wait til the API comes available, I'll write a manufacturing distribution app that'll work.

stephen_lewin_berlin

Bill,

I'm interested in your thoughts on what APIs you would use to write a manufacturing distribution app.  Can you describe what you have in mind?

Steve

billy2

Wow-where do we begin?

First, I would think of this in 2 sections:
1. quote phase
2. make phase


-quote phase
No body makes money in the quote phase and it has to be very simple. No body these days say oh-boy here's some new software I wonder how it works. I send a manufacturer a link and it plays for him telling him exactly what I want and allowing him to accurately quote the job. I never want to hide details that he'll miss and cost him more time. Everyone has to make money and he needs to understand exactly what I need done.

-make phase
The make phase is simpler and typically you're dealing with a programmer who creates the CNC. In this phase making sure he has the correct files is everything. My waterjet guy needs dxf in inches which drives me up a wall but it's what he knows and I try to accommodate. At this time the CNC guy figures out strategies for tolerance's & fits, I supply him with mating parts so he'll dial everything in (remember I'm a designer, not production engineer).


There needs to be a lot done in OS to handle various views with certain dims & annotations highlighted, think of something like SW MBD. Then all I have to do is write a routine that'll call up the various views that highlight dims & annotation. Currently I take screen shots and post to my web page. It would be better to spin it around see the various dim's and annotations live. There has to be a button he can click and get a file for CNC. Most machine shop guys can work with step, parasolids & SW. I don't like to give out SW because it's just to much, but if you want cosmetic thread info, you have to send it. No CNC uses cosmetic meta data, hsmWorks didn't do a very good job at it. Not sure about CAMWorks but I don't think they use it either. The state of CAM is seriously underdeveloped from a designers perspective.

Writing your own CNC code is a long road because machinist are late adopters so we have to develop a system that distributes information they can use with their existing systems. Trying to get them to use a new CNC software would be impossible.

My system is de-coupled from the design/CAD and allows me to post a design at a current revision and then continue on the next thing. If we use the native CAD environment, then we'll have issues with things updating while he's machining. I guess versioning would help this from happening. But if I branch a version and detail it out for manufacturing, I wouldn't want to do this for each version. I suppose I could merge the production branch back into the main branch to migrate the production stuff to latest design. Will this work? Sounds good in theory. Currently my simple system is a website with images and files that's not coupled with CAD. It takes me about an hour to document about 40 parts for manufacture. In fact I have to do it tomorrow morning. It's funny because I really don't want to waste an hour doing it. Now you why I don't want to spend a week creating drawings.

Currently I don't need your API to implement this into my website. I upload a lot of stuff to my website and I don't have a fancy uploader like you guys have. It would be nice to skip the upload part since OS is on the web and my site is on the web. How are you going to deal with cross-site scripting? How do I get my site & OS talking?

Currently I do a lot of Javascript for the frontend and learning AngularJS, for the backend I use PHP to serve up div content & manage sql database queries. Currently hosting with godaddy and just switched from the "grid" to "cpanel". I don't have a dedicated server so I'm worried about the guy next to me compressing videos and robbing my bandwidth. Not really happy with either godaddy solutions and thinking of switching to AWS.

If I had an iframe on my site pointing to OS, could I register some event handlers to work with your servers? Would I store the parts meta data in my database and then call your servers for the shade and spin, yet all the data is under my control? This doesn't sound clean rather all the data should reside in one location. I guess you could do it like google maps and give certain calls to your server. What calls? don't know, but I'll think of some. If the buttons are in the iframe and someone clicks on it, I need to know. I don't think buttons surrounding your iframe would be good from a UI stand point.

How about this, I'd like to store an object literal in an OS document and be able to read/write it. I would like to be able to display different view states of the model and turn certain sketches & annotations on/off. I would like to be able to load different documents, versions, tabs and isolate down to a body.

Some initial thoughts....





 

bill_schnoebelen

Interesting quote process Bill.

I do it differently as there can be several layers between me and the shop. I throw a boarder around the part. This automatically points to part number, revision, material, and finish. It also gives a tolerance block (per model origin). I then give overall part dimensions and show any views with features. If there are features outside of the tolerance block, I call them out. I then have a macro to save the file as "partnumber_rev_desc" in step, parasolid, iges, edrawing, and pdf. I also send some shops the source files. It works great!

Basically, I try to give them:

-Material
-Finish
-Tolerances
-Setups
--Toolchanges
---Features/tool

Interesting thing about OS, if those first three are meta data. You don't need a drawing. It's also a database. It can automatically give you toolchanges, and features per tool. I'm hoping to save the day or two lost on quoting.

billy2

Bill it sounds like you've mechanized the process nicely. How many files do you have on your hard drive?

I end up with a lot of files also,

bill_schnoebelen

I end up with a lots of files, but the macro organizes them nicely for zipping and sending.   

billy2

Bill I feel your pain trying to control who has what and getting the correct info to the right people.

What would happen if one of your parts changed? Would you email a single file out to everybody or would you batch another zipped folder to everyone and make them figure out which changed? 

I suspect you'd send a single update to everyone. Does it bug you that they now have 2 lists: the original list and a changed list? 

Do you even care about this kind of stuff?

bill_schnoebelen

Hi Bill,

The parts change a lot. The time waiting for quotes to come back allows a window for design reviews.  

It is usually small changes at that point. We mainly do low volume prototypes so the real cost is in the setups.  This is why clear part numbers and revisions are so critical to us.

Below is how I envision it for Onshape. As long as all the data mentioned above is in the model, the vendor can quote from the model. They already do this now. I don't have to convert or email files. Hopefully, it would also give me a consistent format to view and compare the quotes.

stephen_lewin_berlin

Bill, thanks for your interest in an API.  I manage the API/Partner team here - we have been developing an API that provides a web integration model, and gives you many (though not quite all) of the interfaces you suggest, including the ability to use Onshape for storage so you can keep all of the data associated with your model in one place.  We aren't quite ready to release a developer resource kit that includes enough documentation and samples to get you off the ground, but it is coming.

bill_schnoebelen

SteveLewin-Berlin said:

Bill, thanks for your interest in an API.  I manage the API/Partner team here - we have been developing an API that provides a web integration model, and gives you many (though not quite all) of the interfaces you suggest, including the ability to use Onshape for storage so you can keep all of the data associated with your model in one place.  We aren't quite ready to release a developer resource kit that includes enough documentation and samples to get you off the ground, but it is coming.

Hi Steve,

Thanks for the feedback. What program languages will this support?

Looking forward to it! 

billy2

Steve I'm interested in the API, if you need someone to review your stuff, I'd be happy to add my 2 cents.

billy2

Bill- I spent the weekend trying to dream-up the perfect cloud release/distribution system. It's like an onion with so many layers that need to be proven and excepted before we get this thing rock'n. 

What's going to be on Onshape servers and what goes to your servers? Will Onshape give me a database(s)  (sounds like they will)? What's the division going to be and how much will be accomplished by Onshape. Currently I upload solidworks data to my website and maybe I'll do the same with Onshape only there won't be any uploading. I'm thinking I'll construct an animation that will show the assembly with all thoughts & concerns then play on to the individual part views with critical annotations and add a down load option for each shape. Currently I'm doing it with images and you scroll down through a list of items I need. It would be nice if this was automatically created and maintained. It seems like a shape/component/body/part needs a parameter that's called machined and then it's scraped out of a layout to be posted to a web site. Do you work off of branches or modify dates to determine versions or is it a manual toggle?

I don't think the language is going to VB. I suspect javascript which is more interesting/fun. I just finished a good book called "Javascript for Web Developers" by Nicholas Zakas. If it is javascript I recommend this book.

One thing that's really good is that SalesForce (CRM) had a great quarter validating this whole cloud thing.

stephen_lewin_berlin

The API to Onshape will be REST calls that can be made from pretty much any language that you run on your server.  The UI for a web-integrated app would typically be javascript or a closely related cousin, as it runs in a browser.  Stay tuned for more info!

billy2

Never mind, I get it. You'll provide a list of things attainable?


$request =  'http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&query='.urlencode('Al Gore').'&results=8'; 

The actual request is achieved by invoking the<i>&nbsp;file_get_contents</i> function with the URL as the parameter:

$response = file_get_contents($request);

I can hit this with ajax and have real time updating. But how do I navigate through your data structure? ie..

I want this document, this version, this part studio, this shape/body and I want the color?

Can you please return an object literal and I'll just dig through it.

alert(document.version.part studio.shape.color); //red or ff0000






Does this mean:

Gets me into a document?:
https://cad.onshape.com/documents/1195300f63fe4eebab7b7625/w/201010ababdc40ca8a03765f/e/3aaa9b97a856477fad8b6723/info



Can I pass what I want?:
https://cad.onshape.com/documents/1195300f63fe4eebab7b7625/w/201010ababdc40ca8a03765f/e/3aaa9b97a856477fad8b6723?getMe=eyJub3RlSWQiOiI3NjkiLCJub3RlRGF0ZSI6IjIwMTUtMDItMjcgMTU6MTA6NTkiLCJkZXNjcmlwdGlvbiI6IkJpb3Nlcm8gbHMjMiB3YXRlcmpldCIsImFjdGlvbiI6ImxvYWROb3RlIn0=



Do I get a callback?:

            case RsAjax.xhr1.readyState==0 || RsAjax.xhr1.readyState==4:

                RsAjax.xhr1.open("POST", url, true);

                RsAjax.xhr1.onreadystatechange = callBack;

                RsAjax.xhr1.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

                RsAjax.xhr1.send("json64=" + json64);

                RsAjax.ajaxStatus[1]=true;

                RsAjax.status();


I can wait for some examples.

billy2

Steve-

How do I get shade & spin on my website?

How do I get a screen shot of a document as an image?

billy2

Bill S-

Looks like REST will provide you with all the meta data associated with an account. This means I should be able to see who's logged in and count their mouse clicks. I can put this in a table and sort the active engineers from non-active engineers. Just kidding.

I think you'll need some kind of image dump program that runs inside onshape to create snapshots/tabs and then you'll be able to retrieve these through REST and display them on a website. Wouldn't take much to recreate what I do on my site and lose all that uploading.

I could also retrieve a parasolid, step, stl, webgl (please) from Onshape . With a face id, I could get a dxf. With a point & vector I could take a snapshot image (give me this and forget about storing images).

I certainly don't want 50 snapshot/tabs in a document cluttering everything up. Maybe there's a hidden tab only accessible through REST where you can dump the images.

This would be much better than my existing workflow and wouldn't be that tough to write.

stephen_lewin_berlin

We (will) have API to retrieve a shaded image of the model. We (will) also have a structured storage mechanism that you can use to store multiple things "in" a single tab.  It sounds like our mechanism will give you the basic interaction you need. I look forward to seeing what you can do, and what more you'll need.

lougallo

@bill Most REST APIs will give you a list of endpoints (urls) that will allow you to do a variety of actions like GET, POST, PUT, DELETE and responses could be in JSON. Based on your goals of integration, you can pick the endpoints you like and get creative. Most RESTful APIs are simple to build requests, get responses, use your code to perform some action and handshake easily.  @SteveLewin-Berlin is the guy to ask and we can't wait to see what everyone starts building when it is available. 

billy2

You got it Lou, 

It would be nice to eval the object literal (JSON) and have an javascript object to deal with instead of a response that I have to parse. REST can also return XML which I don't know how to evaluate in javascript and I definitely don't want to parse it.

There's going to be a lot of information to obtain from Onshape and I'll have to ask for a slice of this information. My internet connection isn't fast enough for a data dump.

Looking forward to seeing how to figure this out,

stephen_lewin_berlin

Most of our REST APIs will return a JSON object, designed to be easy to work with in Javascript. We will start opening up documentation later this year.

bill_schnoebelen

Hi Bill,

I would be interested in seeing what you come up with. 

I would think initially you would want to break off the data from OS. Long term as OS gets more users you would want to just share the model. This would allow the machine shop to model fixturing and program CAM around the model. This is how I do it with HSMWorks and SW now.

billy2

I've been struggling with this. At first it'll be easier to split the data across a couple of servers. But, for the future, I think having all the data in one place is important.

My thoughts are to try and keep all the data in Onshape and create reports from my server.