Model States and Drawings

[eric.frissell26WKQ]

Curious how many of you started using model states this past year and, if you did, did you have to make compromises to allow model states to fit your workflow?  

Our place is pretty standard; 1 part = 1 drawing and that all goes through the vault item master process.  After that we have a process that automates saving each drawing as a pdf, and dxf's of sheet metal get exported.  We're taking a look at the process and wondering how this is all going to work.  For some parts will it be individually saved out drawings for each model state?  Will it be a package of drawings so that 1 part with 10 model states get 1 drawing with 10 pages?

Curious how many of you guys are handling this!

[mluterman]

Love Model States. Used iParts in the past-they were very cumbersome/slow/error-prone (and requires the use of external files that Model States don't need). We typically have one print that shows a different Model State on each sheet-all the way from saw-cut envelope to finished part. So your sheets would be, for example: SAW-CUT/MILLING/DRILLING/GRINDING/EDM, etc (each sheet having its own Model State level of the same part). We design the finished/Primary Model State of the part first, then generate the rough ones by growing material around it, suppressing features, etc.

[eric.frissell26WKQ]

Awesome!  This interface seems SO much better/easier than using iParts.  Spent many hours believing in iParts and destroying/rebuilding all the parts from the beginning.  Sucked...

So it sounds like you're using model states to have multiple versions of the same part so you can define different operations?  Definitely one nice feature of this, or for frame building allowing you to show how weldments go together, or suppress items to show how large assemblies go together. 

Right now I'm using it to have 1 part contain 10 different lengths of 2 different materials of parts for 20 different states.  Getting here was pretty easy but figuring out what to do now is tricky to say. Because only length is changing (okay, and material) it's possible to have 1 drawing and a table noting each length but then handling it with the ERP gets interesting.  If it was possible to associate 1 model state with 1 individual drawing that would probably be our preference but gotta figure out if that's actually possible

[BDCollett]

---

@eric.frissell26WKQ wrote:

Awesome!  This interface seems SO much better/easier than using iParts.  Spent many hours believing in iParts and destroying/rebuilding all the parts from the beginning.  Sucked...

So it sounds like you're using model states to have multiple versions of the same part so you can define different operations?  Definitely one nice feature of this, or for frame building allowing you to show how weldments go together, or suppress items to show how large assemblies go together. 

Right now I'm using it to have 1 part contain 10 different lengths of 2 different materials of parts for 20 different states.  Getting here was pretty easy but figuring out what to do now is tricky to say. Because only length is changing (okay, and material) it's possible to have 1 drawing and a table noting each length but then handling it with the ERP gets interesting.  If it was possible to associate 1 model state with 1 individual drawing that would probably be our preference but gotta figure out if that's actually possible

---

With Items in Vault that should be possible. Do a drawing per state an assign an Item to that state.

[johnsonshiue]

Hi! iParts and iAssemblies were meant to be library components (fully defined on the table and rarely changed). They can be used as a means to create configuration on the fly. But, the number of files to manage and also the "factory files vs member files" can make the update process less intuitive.

Many thanks!

[mluterman]

"If it was possible to associate 1 model state with 1 individual drawing that would probably be our preference but gotta figure out if that's actually possible"
For this, I would use the Derive command to "extract" the Model State I want into a new .ipt. Yes, this creates an additional part (and is an extra step), but it is truly only one part that always stays linked to the Model State of the original part from when you first derived it.

[eric.frissell26WKQ]

@BDCollett Drawing per state?!  This sounds good, any chance you have any reference material for this or screenshots you can take to show how to assign a drawing per state?

[eric.frissell26WKQ]

@johnsonshiue  Thanks for the heads up, and I can see where there was likely some value for creating basic components like bolts, nuts and washers since revising hardware is a pretty scary thought on it's own.  It was the inability to easily edit items (since I wanted to use them for production parts/assemblies similar to Solidworks Configurations) that really left a sour taste even though it makes sense that they weren't designed to be edited easily.

[eric.frissell26WKQ]

@mluterman 

This is actually extremely similar to a Solidworks work flow I used to use in the past - setting it up and maintaining it was a little tricky and a bit time consuming but the end result was that it worked.  If @BDCollett 's suggestion doesn't work then your suggestion (I expect) will be a bit more robust and allow a bit more flexibility - the trick, of course, will be tying this all together to get it to work with our ERP system but that will be more of an "our problem".  I wasn't aware the derive from model state existed so this is a really solid idea that I'll be looking into.

Could easily combine this with iLogic to save each model state as a new part as well so you're basically setting up model states and making drawings... I like this