Level of Detail for Parts

DRoam
Mentor
Mentor

Level of Detail for Parts

DRoam
Mentor
Mentor

Curtis_Waguespack has posted the following idea in the Inventor IdeaStation for LOD parts: http://forums.autodesk.com/t5/ideas/v2/ideapage/blog-id/v1232/article-id/1401/page/1#comments

 

Autodesk has marked the idea as "Accepted", but I'm wondering if anyone has come up with a decent way to mimic this functionality until Autodesk implements it?

 

With iParts, when I change an iProperty (such as Stock Number), or do any other sort of change while in "Factory" mode, that change should be shared with ALL members unless it's explicitly added to the iPart table--but that's not the case. iProperties are not shared with all members--I have to explicitly add them to the table and keep them in sync manually, or the property doesn't show up right on drawings. We use custom iProperties as well, some of which are created at the Assembly level by iLogic, and these are a pain to keep up to date with iParts.

 

With derived parts, there just isn't enough control over the part's features. I can remove some basic featuers (like fillets), and I can add features, but that's about it. In addition to this, not only iProperties but even more surprisingly, the material is not derived into the derived part, and there's no way to create this link. If the material of the base part is changed, it's possible drawings of the derived part could be produced and handed out with the wrong material and you'd never even know it, unless you remembered to update all of your derived parts (and knew that was necessary in the first place).

 

So, until LOD parts are implemented, does anyone know of a way to have the feature-control of iParts but still maintain shared iProperties between members? Or how to achieve the same linked iProperties (and material) with Derived parts?

 

Thanks for any suggestions 🙂

0 Likes
Reply
990 Views
6 Replies
Replies (6)

mcgyvr
Consultant
Consultant

Can you give a good detailed example of what you are trying to accomplish or what you are trying to do here?

I understand your complaints but don't have a good understanding of exactly what you are hoping to accomplish here..

 

Give me a good example and I'm sure we can suggest a good workaround or the proper way it should be handled in Inventor.



-------------------------------------------------------------------------------------------
Inventor 2023 - Dell Precision 5570

Did you find this reply helpful ? If so please use the Accept Solution button below.
Maybe buy me a beer through Venmo @mcgyvr1269
0 Likes

DRoam
Mentor
Mentor

@mcgyvr wrote:

Can you give a good detailed example of what you are trying to accomplish or what you are trying to do here?

I understand your complaints but don't have a good understanding of exactly what you are hoping to accomplish here..

 

Give me a good example and I'm sure we can suggest a good workaround or the proper way it should be handled in Inventor.


Hi @mcgyvr, I know it's been a long time but I've run into issues with this again, so I can give a couple examples.

 

Here are some of the issues with using the iPart workflow as opposed to a Part LOD:

 

  1. Material and iProperties. The material and iProperties aren't kept in sync for all the members of an iPart. If I change the material, Part Number, etc., that change isn't propagated to the rest of the members UNLESS I add those properties to the iPart table AND explicitly change the value for each member.
  2. Work features. Work features are also not included in iPart members unless I explicitly add them to the iPart table and enable them for each member. In addition, when assembling I have to switch the browser to "Modeling View" in order to access those work features. Not a big issue but still an annoyance.
  3. Feature Patterns. This is possibly the worst because there's no work-around for it: feature patterns are "lost" in iPart members and Derived Parts. This means that if I have an iPart member in an assembly, I can't use a feature pattern in that part to drive a Component pattern in the assembly. It also means that if a part was originally a normal part, and I change it to an iPart, any assembly patterns associated with feature patterns on that part become sick, and I have to delete the pattern altogether and re-create it using parameters.

 

All of this could be avoided if we had LOD functionality in parts.

0 Likes

DRoam
Mentor
Mentor

I've realized that what we really need is not a new "LOD Part" functionality, but for iParts to behave in a more streamlined way. So I finally made an IdeaStation post suggesting some changes to how iParts and Derived Parts behave. These changes should eliminate the primary reasons that users have to forgo the otherwise great capabilities of iParts and Derived Parts, and make working with Part Configurations much easier.

 

IdeaStaion suggestion: Improvements to iParts, Multi-body, and Derived Parts

0 Likes

alewer
Advocate
Advocate

The attached example (Inventor 2016) may be of some use to you. I represent a machined part in several states with assembly levels of detail. In this example I show the finished part, two intermediate manufacturing steps, and a simplified representation of the finished part (without chamfers and fillets).

 

Some things to notice:

  1. In my "skeleton" part (Definition.ipt), I pattern a solid with distance 0 to get a second instance of the body. I then add features to the second body. The first body remains as a "snapshot." I do this to represent machining steps.
  2. Wherever I use this machined part in an assembly, I place the assembly (Assembly.iam) and not a part. I then activate either the master LOD (for full detail) or the simplified LOD (to reduce model complexity). I have changed the BOM structure of Assembly.iam to phantom. This way, only the machined part appears in the higher level assembly BOM. You can see example usage in "Top Level Assembly.iam"
  3. I have shown how to document machining steps in the attached Drawing.idw.
  4. Notice that in Assembly.iam, I've placed not only the derived part (Part.ipt), but also the skeleton (Definition.ipt). Since the skeleton has BOM structure reference, it will not appear on the BOM, affect mass properties, etc. But it does allow me to use any of its work geometry for assembly constraints as you've mentioned. Here, I've constrained Ball.ipt to the notch in the end of the part.
  5. As you can see in "Top Level Assembly.iam," patterns can still work! Again, the secret is to include the skeleton (Definition.ipt).

I will post a sheet metal example below.

alewer
Advocate
Advocate

Here is an example sheet metal assembly. Here my goal is not to represent a single part in various stages/levels of detail, but to represent a simplified assembly. As with the machined part example, I use a substitute part. I often use this approach when I'm sending simplified 3D CAD data to a third party. I also often use it to create drawing views with less superfluous geometry like bend reliefs, tangent edges, etc.

0 Likes

DRoam
Mentor
Mentor

Thanks for putting that together, @alewer. That seems like a very nice workflow for showing different version of a part. The biggest drawbacks are the Derived parts won't derive their material or iProperties from the master part, and there are several files to keep track of.

 

If iParts functioned as they should (such that geometric information like work features and feature patterns wasn't lost to the members) the result would be virtually the same as your workflow, minus the need for the Phantom assembly with the Definition part.

 

And if iParts further functioned as Inventor users wish they did--as a single file, and where the material and iProperties are kept in sync between members unless specified otherwise--then the iPart would truly be the perfect answer to Part configurations, as it's intended to be.

 

Thanks very much for sharing your workflow, @alewer, it's very appreciated. We may implement this workflow until iParts are improved.

0 Likes