Driving Sub-assemblies from assembly with iLogic

[Anonymous]

Happy Tuesday all.

Question for the day for me. I've got all my sub-assemblies driven by iLogic, both sides, bulkhead, tailgate and the floor. I've created an assembly model with my driven sub-assemblies. So now how do I drive the sub-assemblies from the new assembly model. I want to use the floor to drive the length. This will be for the floor and side length. The sides will drive the height for the sides, tailgate and bulkhead. I know I can only do this with a "custom" view rep., but am having trouble making this active for the sub assemblies from the complete assembly model. I've tried to activate each part from the new assembly model and drive the individual subs, but can't activate the custom view reps. Still playing but could really use some input. Thanks in advance for your time and assistance.

Frank

[JamieVJohnson2]

Loaded question...

First, to drive or derive or 'drive' as slang?

The Assembly Level of detail can and will store sub parts levels of detail changes as well.  If you can't see how, after activating a custom level of detail for the main assembly, right-click on a component in the browser tree, and select Representations... and that window should allow you to select your sub-assembly's levels of detail, positional representations, and view representations.  They will stick with that level of detail, position representation, and view representation.

Move with the floor???  If your floor changes size, and your parts are 'flexible' in nature, then turn on Flexibility (per sub assembly) to watch your sub assembly flex as necessary (simple example D-ring assembly can flip ring around clip).  If your design is all rigid in nature, then as we design railcars this way, you can make a base sketch, export its parameters into other parts, and build their features and sketches off of the imported parameters.  Then making a change in the base sketch modifies the entire railcar (such as deck camber).

If I'm still off base, then I apologize and ask for clarification.

[Anonymous]

Jamie,

      I "drive" the sub assemblies with iLogic rules via named parameters and iLogic forms. My main assembly is made up of 5 sub assemblies. I thought this would be easier than building the main assembly first and then trying to program all the illogic code at the completed assembly level. The iLogic code for the floor assembly alone is 370 lines. Each of the 2 sides are 170 lines of iLogic code. For reference, the complete assembly model is an aluminum trailer body that can vary in length from 22' to 53' (2' increments). The sides vary in height from 48" to 102" (6" increments). The floor also varies from 22' to 53' same as side lengths, but has 3 options to accommodate tailgate style options. I use iLogic forms in the individual assemblies to drive length and height. I suppose I could build a complete assembly and strip out the iLogic code from the sub assemblies and paste it all into the complete assembly, then build a new form to drive it all from there...

   I tried to make all the sub assemblies in the complete model adaptive and that still won't allow me to activate the "custom" level of detail in the sub assemblies. So if I double click and activate, for example the floor, my floor form won't work because the "custom" LOD isn't active.

   Also, I'm thinking, even if I copy paste all the code into one rule in the complete assembly, I'll have to re path all the part call outs (not explaining this well) but it seems like it might be easier to start from scratch. I've attached a screen cast of what I've done with the floor model, might give a better idea of what I'm trying to do.

   Thanks again for your help

[Anonymous]

Not sure this worked on previous post...

[JamieVJohnson2]

While your approach is definitely clean and to the point, I have to wonder why you didn't choose to use the iPart / iAssembly system for this instead.

What I would have done:

1 master iAssembly (deck and hardware) - Trailer

1 iAssembly - Hardware

1 iAssembly -  Deck

several iParts (deck parts that resize) - various, such as deck plate, side sills

several standard parts (deck parts that are constant size) - various such as gussets, end sills (unless you want to change width too)

the iParts would have a table driven system, and each member in that table would be named per their size within the overall assembly

the iAssembly, can have the parameter for array, stored in a table driven, as well as the individual iPart choices stored as separate columns.  Then you can create a master deck - size combination chart (data from your code really).

the Hardware doesn't actually have to be an iAssembly, because it could just be 3 separate sub assemblies with visibility, but as an iAssembly, you can name the different configurations as members and drive them (Exclusion tab).

Finally the Trailer master assembly can also be an iAssembly that would drive the multiple combinations of all these parts.

Then, you can select all and right click on the list of members in the table, and 'generate files'.  This would create an output of all the possible assembly combinations, in a sub folder named for the iAssembly, and you can detail each one (or not).  This is similar process to how the content center works.

[JamieVJohnson2]

now to answer you actual question...

iProperties.Value("CarWheels", "Custom", "HalfTruckCenter")

when working with the parameter or property of a child, you must specify the child component by its component name, the value you see in the browser tree.  This will modify the property or parameter of the child object providing it is read/write and able to accept changes.  This also permanently changes your one part.  Hence the iPart concept.

[Anonymous]

Jamie,

   Tried that approach a while back with iParts and iAssemblies but couldn't get it to generate new unique assemblies. Also, the files were glitch too, never knew if I was going to get the same results twice in a row. So I took all my extrusions and put them in the Content Center. This seems to work better than iParts, iAssemblies and iFactories for me and what I'm trying to do. Also wanted to get a handle on iLogic. With the proper parameters and the right code it seems to me iLogic has many more possibilities and more power.

[JamieVJohnson2]

It certainly has more power. The fun of it is, within the iLogic compilier you can write iLogic/VBA/VB.Net code and it will read and understand all of it. Just bear in mind the iLogic specific code does not work in the VBA/VB.Net environment, and some VB.Net assumptions (what I can get away with in visual studio) you can't do in iLogic. Kind of picky. Have you found, and read up on the Inventor API located in the Help/Programming API help?

[Anonymous]

Not yet,

Still learning iLogic basics. But it's on my to do list.

[JamieVJohnson2 · Accepted solution]

At the VERY LEAST, get out the Autodesk Inventor (Version) API Object Model, and print yourself out a copy.  It helps to get under the hood.  I found iLogic to be limiting and frustrating (no intellisense or live error checking!!!) pretty quickly, when only applying the information found in the iLogic portion of the online help document (mostly about changing properties and parameters).  When I began to program for Inventor, it didn't take me long to get into the .Net api, which requires the Programming API help (from the help dropdown within inventor) to get a solid (if I can call my knowledge solid on anything!) understanding of how Inventor works.  This year I've written some pretty powerful Inventor VB.net code (auto-create parts, assemblies and drawings), so if you need any further assistance, I'd be glad to help.  Oh and thanks to a snafu in the Autodesk forums system, my rank of 10 was reset a few months back to 0 as a new user when I had some accounts merged.