A case for iLogic?

[Anonymous]

I design and 'engineer' cabinetry and custom furniture.  I have been using SketchUp for years, but recognize its limitations, and am migrating to the Inventor software.

Through text books and surfing the web, I have figured out the multi-solid modeling flow.  I have been trying to figure out how to take the leap into using iParts (or iAssemblies? or iLogic Components?) in order to streamline some tasks.

For example:

Rooms, case parts, and face frames are all very custom elements in a cabinetry design.  Doors and drawers are virtually only unique to the opening they fit in.

I think there's a way to generate a multi-solid file that includes the room layout, the case parts and the face frames (and such), convert it into an assembly file and then insert iLogic(?) doors into it and link the the driving parameters (for height and width) back to reference dimensions, as opposed to entering specific values when inserting the iLogic part.

I don't know if I'm explaining this clearly or not.

Here's another way to describe it:

I have completed the iDoor tutorial from Applied Design Intelligence.  Now I want to insert that sub-assembly into an assembly file.  Instead of a prompt for specific dimensions to make the door to, I want to be prompted to which opening the door needs to fit in, and have it sized for that opening.

Still not certain I'm being clear, but I'm throwing this out to see what may bounce back.

[PaulMunford]

Yes that is possible. Don't forget you can device a parameter value - you don't have to drive geometry.

You also have the option of linking parameters. ..

[Anonymous]

Thank you for responding, Paul.

Truth be told, I was specifically going to seek you out on this directly.  

I've been through your blog pretty thoroughly, and haven't seen a post that seems to address the particulars of how to go about this process.

I'm aware that you're doing just this sort of thing, can you point me to a tutorial?

As I'm relatively new to working with Inventor, I'm not quite sure of the terms you brought up.

I have thought of the linking parameters bit already, but don't know the steps.

I can imagine one would create reference parameters (driven dimensions) for each opening (height and width) in the multi-solid part, include them in the derive (when converting from a multi-solid into an .iam file,  and those would be the parameters to link the incoming iLogic door sub-assembly to.

Any help would be appreciated.

Cheers!

[PaulMunford]

Hi Sayer. Sorry - both 'device' and 'drive' should have read 'derive' (I should have looked at the helpful suggestions from my phone more carefully! )

I'll see what tutorials I can come up with. Would You be willing to share a data set we can work with?

[PaulMunford]

Check out this class from AU. There is a demonstration of exactly copying assembly parameter values into parts toward the end.

There is an example of the code used in the handout:

http://au.autodesk.com/au-online/classes-on-demand/class-catalog/2013/product-design-suite/ma2604

[Anonymous]

Thank you, Paul, this looks like a solution.  I don't know that I grasp how to go about it all, yet, but I'll do some experimentation, and see how far I can get.

At present, here's what I'm understanding this process to look like:

-New project with Library access for each unique project

-Create re-useable library sub-assemblies (doors, drawers, hardware etc...)

-Create 'Master' part (solid bodies) for unique-to-project elements

-Derive into an assembly

-Insert and place library components into assembly file

And here are some details as I currently understand them:

-Library components that need to change depending on the assembly parameters need be iParts (or is it iAssemblies?) in order to have the option for being unique instances AND to have iLogic code in them to find their dimension parameters within the assembly they are inserted into.

-Creating and exporting reference dimensions from the Master part file is a way to have the parameters brought into the assembly.

-Reference parameters should be uniquely named (ie, OpeningAHeight, OpeningAWidth, OpeningBHeight, OpeningBWidth, etc....).

As I said, I'll play around a bit and hit the forum again when I hit a brick wall.

I have attached a couple of files.  One is a master part file for a coffee table I've been messing around with, the other is the completed ADI iDoor.  You'll see in the coffee table model that I've made some shoddy representations for the frame and panel doors.  My goal is to figure things out well enough to be able to insert the iDoors into a derived assembly and have a better representation of the doors for documentation.

Thank you again,

-Kevin

[Anonymous]

I've run a couple of simple tests to see if I'm getting the gist of what is described in the tutorial.  I'm missing something.  

I've attached the pair of files I created to work with, perhaps someone could take a look and see where I'm going off track.

Also, over the course of looking at this, it occurs to me that this solution would require having unique parameter names for each face opening and iLogic code for each individual face placed into an assembly, does that sound correct?