Suggestions for workflows with manufacturers?

fastwayjim

I think it is important to give the 3D geometry out for quote. For example, in machining, the machinist wants to think about how it will be tooled. Tooling for prototype is different than tooling for production, and all that needs to be taken into account.

That being said, there needs to be a smart way to communicate the non geometric info to the supplier, as @Julian_Leland suggests in the OP. Material, Finish, Revision Level, and other unique manufacturing-related part-specific notes. In some cases these are parameters that are embedded into the model.

IMHO, OS needs some smart way of storing and displaying this information for each part within a studio. Perhaps, there is some sort of parameterized note that can be than can be tied to the part itself. I see there is a properties tab for each part, what if it were updated to include these parameters? Like this:



For drawing creation, these parameters can be parametrically tied to different notes in the drawing (such as in CAD today). But for those workflows which do not include creating 2D prints, these parameters will stay with the part itself.

Of note: If these things get exported to step/iges, this info should then be carried along as well, such as in the ascii header.

My two cents.

Jim

billy2

Good points Jim-

Would you use a distribution system if I built one?

bill_schnoebelen

FastwayJim said:

I think it is important to give the 3D geometry out for quote. For example, in machining, the machinist wants to think about how it will be tooled. Tooling for prototype is different than tooling for production, and all that needs to be taken into account.

That being said, there needs to be a smart way to communicate the non geometric info to the supplier, as @Julian_Leland suggests in the OP. Material, Finish, Revision Level, and other unique manufacturing-related part-specific notes. In some cases these are parameters that are embedded into the model.

IMHO, OS needs some smart way of storing and displaying this information for each part within a studio. Perhaps, there is some sort of parameterized note that can be than can be tied to the part itself. I see there is a properties tab for each part, what if it were updated to include these parameters? Like this:



For drawing creation, these parameters can be parametrically tied to different notes in the drawing (such as in CAD today). But for those workflows which do not include creating 2D prints, these parameters will stay with the part itself.

Of note: If these things get exported to step/iges, this info should then be carried along as well, such as in the ascii header.

My two cents.

Jim

I believe getting that info in OS up front is very important. It has to be in only one property and unambiguas. 

OTW: you quickly get PartNum, Part Number, Number, Rev, Revision, Mat, Material, Fin, Finish. You can get the same properties with different values in the in the same model. Screw freedom of expression! Lock it down to one.

On the same note: Materials need their own properties. Finish should trump materials for apperance. Cost should include MOQ or price breaks.

brucebartlett

Sent this to @AbeFeldman in response to a ticket request he asked me about. 
ruce Bartlett <babart77@gmail.com>Mar 4 (1 day ago)to OnshapeHad some idea's here about a material library with stock material listing and using a to link material meta properties. https://forum.onshape.com/discussion/191/properties-material-properties-and-drawings/p1
My list (pretty much what you have in On shape, not sure if you could have dates auto propagate when a revision is added)
material (from the editable material properties description if possible) finish   (eg. natural, painted, etc.)Weight (from model based on material)
PartNo
Description Description_2 (I think we need a second line, some ERP systems have this and most drawing also have a 2 line description)
DrawnByDrawn_Date

Revision RevisionBy ApprovedBy (Eng Manager Sign Off )Approved_Date
Release (internal project number for work done, don't know if onshape needs this )
Release_Date


I think we will need to have some form of custom properties too, unfortunately their will be special properties to add by some users but good if all Onshape parts only had standard properties list them they can be interchanged between everyone. I'd also like a link to ERP so properties match, hopefully linked via the API.
ERP Property which would be nice to see/set in CAD
Part typeCostSupplierCommodity Code
EBQ

Hope that help

pete_yodis

With regards to material definitions...

  It seems if the material library were thought out, it could be done in a way that is not a bolt on library, but one that is integral to Onshape and could have implications for helping users with BOMs - identifying what raw material a part is made from, possibly what part number that raw material is. This would be important on the PLM/ERP facing side of things. If Onshape is going to support BOMs and if it is a database system, then why not extend it to the most granular state that users would ultimately want in order to capture product structure. The material database/definitions would also be important for regulatory compliance with users, as well.  We really need a level below the part, and that is the raw material level.  Full tracking of raw material usage in Onshape designs would be really something, and not bolted on after the fact...

pete_yodis

With regards to notes and metadata. I would think we should ask for notes to be implemented in a way that is compliant with ASME Y14.41 and model based methods so that those items could be properly displayed with an annotated 3D model, and then also not have to be duplicated if displayed on a 2D drawing. I'm not certain what that looks like, but I'm sure I don't want to type information in more than once. Its a problem between 3D models, metadata, and 2D drawings. Information can exist in too many places.

billy2

I wonder if there could be public templates. These could be sorted by public voting so the good filter to the top. SW templates were never any good, but then, what's a good template? What's good for me might not be good for you. Let the public vote templates up/down and good ones filter to the top.

I'd use Bruce's template for 6061 aluminum, 4130, 316 or 1020.

pete_yodis

I'd be happy to share from my treasure chest of material definition if it helps the cause....

billy2

Thanks Pete, I'm trying to figure out how to incorporate these into Onshape other than having a tab with an excel spreadsheet attached.

murray_1

You'd want a consistent system of units, rather than grams, pounds, Farenheit, Celsius, inches, metres etc all mixed in together. Sorry to sound ungrateful but I've no idea how you US boys cope with such a confusion!!!

billy2

The boys aren't the problem, it's the old farts. Welcome to my hell.

john_f_carr

Murray said:

You'd want a consistent system of units, rather than grams, pounds, Farenheit, Celsius, inches, metres etc all mixed in together. Sorry to sound ungrateful but I've no idea how you US boys cope with such a confusion!!!

Don't forget slugs.

fastwayjim

"Pete Yodis" ! Whatever the implementation, it needs to be compliant with ASME Y14, if OS intends to be taken seriously with the machine design crowd.

I think I would just stick to density, and allow the full variety of units options for both input & display (so as not to discriminate). No need to get bogged down with the rest, let the analysis tools manage those.

pete_yodis

@FastwayJim More specifically I was referring to ASME Y14.41, not just all of Y14. 14.41 is the standard that fleshes out model based definition, such that 2D drawings are not needed (although can still be used). http://www.etinews.com/etimail/archive/volume01/issue12/#main I think it would be better to have the full material definition in Onshape, rather than just in analysis tools. There are plenty of times I want to reference a specific material property to make sure that is met (like minimum yield strength on a material that is not covered under a standard - it happens quite a bit). I also think the full definition of the part should be contained within the model, not in the ancillary tools that would then analyze the model. Full digital definition of the model is where things are going in the longer haul. Material libraries in CAD tools have always been bolted on to CAD systems and or analysis sytems. Why not extend material definition down to the most granular state. Before we have a part, we have the raw material its made from. Why not fully capture that as well?

fastwayjim

@Pete Yodis Gotcha. I had to review it again, I thought it was just covering 3D Geometry, notations, dimensions, GD&T, etc. but it does appear to be a bit more encompassing... For those who care, this is from the spec:

pete_yodis

Makes sense, doesn't it.  I don't want data existing all over the place in other documents and systems.  I want it to live centrally to the model.  That is the more efficient route in the long haul, I believe.

bill_schnoebelen

SW handled units pretty well. They use consistent base units (forget which ones?) you use for programming. Everything the user sees is a conversion of the base units. I'm sure OS does the same. My preference is fractional mm.

I would be leery of trying to make a ERP. I, however, never want to use an ERP system, and would be happy with some of the info in CAD. I would break data up into Engineered and Commodity.

Engineered
A component is dependent on it material, finish (better described in a 3D model than a 2D drawing), tolerances, and general notes. Additionally, Number and Revision identify the component. Description is needed since we are human. I think all these should be high level properties. 

Commodity
Cost and Leadtime are dependent on time of mfg and quantity. I can change a source and still get the same part. I have never seen two companies with the same commodity codes yet they can make the same part. These are more variable properties. 

traveler_hauptman

Stephen Lewin-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.

I'm not up to date on all the web programming lingo so I might be missing the correct meaning, but it seems like all of the interaction being discussed so far is between a client machine or a client servers and the onshape servers.

If you use a client machine you lose the run-everywhere advantage of Onshape. If you use a client server then you have to have a server available and the expertise to set it up to interact with your client and the onshape servers.

What's useful to me is to be able to insert a javascript tab into my onshape document that has two modes: edit and run. In edit mode I write the code to extract the image or generate the report I want from my model and in run mode it gets executed and the output shows up in the tab, to be cut&pasted, or grabbed via an html request.

I'm assuming this javascript tab can be referenced from outside documents in the same way models will be able to be.

 This way the results I want are available no matter what client I use and all I need to learn is a few api calls and a little js syntax.

Or is this what everyone is already talking about? I see a couple hints that a couple of the posts might have the above approach in mind but can't really tell.