Derive an iPart from a base iPart

[dpeinad]

Hello, good morning.

I will explain what I want to do with an example

My base part will be an Ipart. I have parameter called Axle_length. Then I have a sketch with a line whose length is driven by this parameter. I generate a table with the part name and the Axle_length parameter. With this setup, I will have a iPart factory which members will have a different line length in its sketch.

I want to derive a iPart factory from this base iPart, so an extrusion will be driven by this parameter. I want also to have different part name for each member so axles with different lengths will have differents part name.

The base iPart will have several sketches, planes, etc. and different iParts will be derived from this base part.

Then an iAssembly factory would mount different members of the derived parts. The idea is to have in one part (main skeleton) all the information for making different configurations. Each of the derived parts will have different part name (part code). I've made this in the past with proE with skeleton family tables referenced by part family tables, but I've not been able to do this in Inventor (probably for lack of training)

Please, can you give an advice to do this assembly factory to make and document different versions of the same machine?

Thanks in advance, best regards

[johnsonshiue]

Hi! I personally do not think this will work. The only purpose of an iPart/iAssembly factory is to generate iPart/iAssembly member files. If you derive the factory, the derived part will be driven by the "active row" of the iPart/iAssembly. When a different row is activated, the derived part will update accordingly.

If you really wants to use iPart/iAssembly to drive other parts, which I don't recommend either, you need to derive the member files instead.

Many thanks!

[IgorMir · Accepted solution]

And that brings as back to a long standing question. Why deriving a factory part into a new part file does not bring an Author table with it? In which the corresponding child can be selected to build a new part off it. That functionality would be very useful indeed. But I know - my question is a rhetorical one, nothing else. We will keep on deriving child of the factory instead. 

Cheers,

Igor.

---

@johnsonshiue wrote:

Hi! I personally do not think this will work. The only purpose of an iPart/iAssembly factory is to generate iPart/iAssembly member files. If you derive the factory, the derived part will be driven by the "active row" of the iPart/iAssembly. When a different row is activated, the derived part will update accordingly.

If you really wants to use iPart/iAssembly to drive other parts, which I don't recommend either, you need to derive the member files instead.

Many thanks!

---

[jlcasasHPUG6]

Sorry for the late reply, I was looking into the same issue for convenience but actually i found a workaround that kinda works for us. I created a "generator ipart" which is the skeleton masterpart of a few (derived) coupling parts. With ilogic i created some rules to export our manufacturing files for each of the components. I do not have actual "members" for the physical parts, but i have generated  all STP, flat patten-DWGs and PDF drawings for the physical parts.

As mentioned, for convenience, it would be great to have the chance to have actual Iparts whose members can be selected and changed inside another assemblies, but this is better than nothing (and with some smart part numbering we can workaround the insertion into another assemblies with ilogic).

[IgorMir]

There is a workaround for it. Which is relatively simple.
1. Create an Assembly and place the iPart into it. Just that very part only. Save the file.

2. Derive the Assembly into a new part file (Part1). Save it.

3. In a Part2, where you want to use different versions of the above mentioned iPart - derive the Part1.

Now, if you want another iPart child to work with - select this Child in the Assembly. Updated the Part1.
In Part2 you will see the new Child.

Cheers,

Igor.

---

@jlcasasHPUG6 wrote:

As mentioned, for convenience, it would be great to have the chance to have actual Iparts whose members can be selected and changed inside another assemblies, but this is better than nothing (and with some smart part numbering we can workaround the insertion into another assemblies with ilogic).

---

[johnsonshiue]

Hi Igor,

This particular workflow will work more robust if the iPart members are replaced with Model States. It is because the iPart member files are derived parts of the iPart factory. If you establish cross-component dependency on an iPart member file, when you try to swap to a different member, likely the dependent will fail to update. The behavior will be fairly similar as if the derive source has been changed to a different part.

Many thanks!

[IgorMir]

Hi Johnson,

It probably will. I can't try it myself. Yet I have created a simple set of files following my own suggestion and everything works fine. But then again - it depends on a complexity of a factory itself. There might very well be a condition, when some of the geometry in a final part will need to get redefined. For example - if the second iPart child is just a mirror of the first  one - changing one over the other will inevitably creates some errors in the part down the chain. But it is understood.
I would imagine - the same is true for the Model States. If initial derived component was Right hand side, and later on it was replaced by the Left hand site one - some of the geometry, based of the derived component will get sick.
Or am I wrong on this one?
Cheers,

Igor.

---

@johnsonshiue wrote:

Hi Igor,

This particular workflow will work more robust if the iPart members are replaced with Model States. It is because the iPart member files are derived parts of the iPart factory. If you establish cross-component dependency on an iPart member file, when you try to swap to a different member, likely the dependent will fail to update. The behavior will be fairly similar as if the derive source has been changed to a different part.

Many thanks!

 

[johnsonshiue]

Hi Igor,

Yes, you are right. The limitation here is that as long as the source geometry (the sketch) is not recreated or is not from from a different file (same document ID), the associativity should persist.

Many thanks!

[DonStauffer99]

How is deriving from an assembly superior to deriving from the member? Either way, you can change which member you use. In the assembly, you'd use a right click on the table and Change Component. If you just derive from the member, in the derived part you can just right click the member in the browser and choose Replace Base Component. What do you get for the addition of the assembly?

[IgorMir]

Replace Base Component function is not available in IV2020. It probably is in newest versioning of Inventor. But the thread is more than  one year old.