Multibody design

Multibody design

Anonymous
Not applicable
1,587 Views
6 Replies
Message 1 of 7

Multibody design

Anonymous
Not applicable

So after 7 years of learning inventer and ilogic, i found out about multybody modelling. I am really ecstatic because this approach has shortened my design time a lot. I am wondering, in community experience what are the downsides of this approach?

0 Likes
Accepted solutions (1)
1,588 Views
6 Replies
Replies (6)
Message 2 of 7

DRoam
Mentor
Mentor
Accepted solution

No downsides per se, multibody modeling is extremely powerful. But a few things to be aware of/keep in mind:

 

  1. Use master sketches and work geometry. As much as possible, build everything off of one or more master sketches and work geometry (planes, axes, points), rather than projecting geometry off of solids. I usually like to have all of my sketches and work planes at the top, then have extrusions, cuts, fillets, etc. after that. This is much, much more stable. Likewise, in assemblies, when you do need to constrain parts, place a copy of your multibody and constrain your parts to the skeleton sketches rather than constraining between parts.
  2. Use Sketch Blocks for structural/standard shapes. Dealing with structural shapes and standard shapes is one of the more frustrating aspects of multi-body modeling. Say you need something to rest on an I-beam. How tall is the I-beam? How wide is its flange? Usually, you would get stuff like this from the Content Center. But now you want the multibody part to be your "source" for every part. How do you get the dimension for all the structural parts you might use into your multibody part? Do you sketch them up every time? Update their dimensions every time there's a design change? This would be very tedious. The solution we've come up with that works very well is Sketch Blocks. We have our own templates for each type of shape (beam, channel, structural tube, etc) with a Sketch Block with the shape's profile. We use iLogic and an Excel table to drive their dimensions for the chosen size. So for each structural member in our design, we create a "Profile" IPT that is just used to specify the size for that member, and generate the correct profile in the sketch block. Then we derive that sketch block into the multibody part. Then we place that block wherever appropriate in the multibody, extrude it, perform any necessary cuts on it, and derive that out to produce the desired structural member. The "Profile" IPT is just used for just that -- the profile. It never ends up containing the full final geometry of the part.
  3. Multiple occurrences. This is probably the most frustrating aspect of multibody modeling. The great thing about multibody modeling is every part is already in its correct final position when you derive it out, so you don't need to constrain anything. Just leave it grounded and if its position changes in the multibody, it will change accordingly in the assembly. However, this completely breaks down when there are multiple occurrences of a part, whether patterned, mirrored, or arbitrarily placed. You could easily pattern, mirror, or copy and move bodies in a multi-body part, and derive those out -- and this would be fine if all you needed was for it to look right. But the big problem is that now each occurrence of a part becomes its own IPT file, with its own iProperties, and its own row on the BOM. This is unacceptable for most drawings. You could possibly give each occurrence the same Part Number and turn on Part Number row merging in the BOM, but this would be difficult to keep up with if you add new occurrences, and that also doesn't help the fact that you would have tons of extra IPT files. So, what do you do? Well, unfortunately there isn't a great solution. The best thing I've found to do is to just derive out one instance of the part (the one I modeled), and then copy and constrain it to the skeletal sketches in the assembly at each location where it's supposed to go. If it's supposed to be patterned, I'll create a dummy pattern in the multibody and associate (link) the assembly pattern to it. Another thing I've found is that often, if a part will be used more than once, it's often easier to model it at the origin in your multibody part (rather than at one of its intended locations) so that you can constrain it using its origin centerplanes in the assembly.

 

Sorry, that turned out to be a lot of information. I hope it's helpful though. Good luck and have fun learning the joys and frustrations of multibody modeling 😉 and do let us know if you find any good strategies of your own!

Message 3 of 7

Anonymous
Not applicable

I have mastered master skeleton sketches and sketchblocks (i like the tip about placing shared sketches on top of master part). I have made a lot of ilogic VBA programs specificly about sketchblocks and i am already using sketchblocs for content center.

 

Are you suggestusing not using Project geometry and Project cut edges in master part?

 

Number 3 is exactly the thing i was wondering about. My idea was deriving all the sketches and planes of the master part in a layout and constraining the occurences to the layout sketch instead of grounding them to the origin. What do you think about this? 

 

 

On other note do you have any useful ilogic or vba programs for moving bodies to origin or desired plane??

0 Likes
Message 4 of 7

Anonymous
Not applicable

I am really interested in projecting cut edges in master sketch. In your experience, Is it stable while you are modefing master part?

0 Likes
Message 5 of 7

LukeDavenport
Collaborator
Collaborator

Agree entirely with DRoams excellent answer.

 

For anyone struggling with item 3) Multiple Occurrences, the Duplicate Replacer app for Inventor (released today) is designed to solve exactly that problem in an elegant, and most importantly, automated way.

 

https://youtu.be/sbFZaeBHehY

Message 6 of 7

DRoam
Mentor
Mentor

WOW! This is absolutely beautiful! Incredibly impressive app! I was actually thinking about doing something similar to the row-merge approach the other day, but this is leaps and bounds above what I was thinking. I can't begin to express how impressive this is -- from the foundation of just identifying duplicates and replacing them correctly, to the clean, modern, integrated look, to the incredibly intuitive and feature-rich interaction. The review table and review tools do an amazing job of clearly presenting things and allowing you to control what happens. It also seems very responsive and speedy. It's my dream to one day be able to write add-ins for Inventor like this, lol.

 

The only thing that would make it better (basically perfect) for multibody workflows would be if the component-replace approach could associatively update to changes in the master multibody model. So if I add or remove "occurrences" of a part in the multibody, add or remove them in the assembly as well. This would allow it to dynamically change with design changes, or easily adapt when copying a design and changing it for a "same-but-different" job. I realize the row-merge approach can basically do this, but it would be great to be able to do it without the one-file-per-occurrence drawback that comes with the row-merge approach. I would love to see an "associative update" for multibody masters come to the component-replace approach in an update.

 

Fantastic work on this, Luke. Are you planning to publish it on the app store?

0 Likes
Message 7 of 7

LukeDavenport
Collaborator
Collaborator

@DRoam too kind! Really appreciate the feedback, makes all those long winter evenings coding (pre COVID when we could actually leave the house) worthwhile.

 

I agree, the icing on the cake would be the ability to update the duplicates based on changes in the master multi-solid part (if applicable). This wouldn't actually be a huge amount of work to implement (#famouslastwords), and would be something like a 'check for updates' button, which checks to see if the duplicate parts still match the source solid body, then check that they are still identical to the other parts in the assembly, and give option to update if not. If there's enough interest in the app to justify a second round of coding that'll be first on the list.

 

I'm probably not going to put it on the app store as I've found it less flexible for updates/licencing etc. Will support it from info@ldcadsolutions.co.uk 

 

Thanks again for the kind words!

Luke