Vault + iPart member check-out request after updating factory

[richterBKSAC]

Hello there,

my problem is the following: when I open an assembly with iPart members inside, which have been edited recently Inventor asks me to check out the members involved.

Does anyone know why I get this request and where the error is?

This is my "workflow" when editing iparts:

- check out the factory

- apply the changes

- generate all members

- check in the factory

In this case the iParts also contain iMates, if that's of some relevance.

Thank you in advance

Matthias

[CGBenner]

@richterBKSAC 

This could be that the assembly reference to the iPart instance is still the old version, and since you have updated the instances and checked them into Vault, there is a difference between the local version in the assembly and the updated version in the Vault.  Vault is probably just looking to correct that difference by "getting" the latest version into the assembly.

[Frederick_Law]

Member need to check out and in also.

[richterBKSAC]

@CGBenner 

probably you're right that Inventor just wants to get the latest version of the member. I'm just wondering why it wants to check out the file instead of just "get" it.

I've also created a new iPart + assembly for testing purposes. But sadly I couldn't recreate the problem.

That beeing said I kept my "workflow" described above and I didn't check out the members and didn't get any errors when updating the assembly. Is there a reason why you would recommend checking out member files as well @Frederick_Law ?

[richterBKSAC]

I think I've found the source of the checkout problem.

It's connected to my other question delete-ilogicrule-in-ipart .

Since I've deleted all members in Vault and regenerated them I don't get asked to check out the members anymore.

The iLogic rule in my factory updated a custom iProperty with the rounded physical mass. I guess everytime that i placed a member the iProperty had to be updated because the mass changed.

I'm still interested in why you @Frederick_Law said I should also checkout the members when editing a factory.

Anyway thank you both for your help 😉

[Frederick_Law]

---

I'm still interested in why you @Frederick_Law said I should also checkout the members when editing a factory.

Anyway thank you both for your help 😉

---

Because IV will asked to later?

"Inventor asks me to check out the members involved"

I haven't done any iParts in Vault.

There was setup required to use iPart in readonly Library.

From Vault Help:

https://help.autodesk.com/view/VAULT/2023/ENU/?guid=GUID-3AC6DDCF-A25C-4D92-9A26-04CF1719AB7E

[swalton]

iPart members are created using Inventor's Derive function.  When Inventor opens a member from disk, it checks to see if the iFactory file has changed since the last time the member was saved.  If Inventor sees a change in the factory file, it wants to update the member to consume any potential changes.

Any edits to the factory file makes all existing members update on the next file open.

When Vault is added to the system, it sees that the member files are dirty, so it wants to check them out to consume the updates.

When I add an iFactory to Vault, I also add an "Update Assembly" file.  This file is not for any design purpose, instead I use it to help Vault and Inventor manage the check-out, update, and check-in cycle for these types of files.  I put each member of the iFactory into UpdateAssembly.iam.  Every time I generate a new member, I add it to the UpdateAssembly.iam.

My workflow when making a change to a Vaulted Factory File:

1. Update the Lifecycle State of all files, if required
2. Check out UpdateAssembly.iam and all its children.
3. Make the changes to the factory file
4. Open the UpdateAssembly.iam
5. Add any member files that are missing from UpdateAssembly.iam
6. Run "Rebuild All" to force Inventor to regenerate all the member files
7. Check in everything from the UpdateAssembly.iam
8. Update the Lifecycle State of all files, if required

[richterBKSAC]

Thanks for your detailed explanation!

Btw I'm using Inventor professional 2023 + Vault professional 2023.

You've mentioned that iParts make use of the dervice function. Would you point me to the documentation, I wasn't able to find anything about it.

I just did some edits on my test iPart and I did the following:

• Check out the factory
• edited all members 
  • all members are checked in, in Vault
• generate all members 
  • all members are automatically checked out, in Vault
• check in the factory
• opened a test assembly, which had all members inside it
• Inventor just asks to update, not check out

I've mentioned above that some of my iParts had an ilogic rule + trigger event before save, by accident. This was the rule:

iProperties.Value("Custom", "weight_lb")=round((iProperties.mass*2.2),2)

Don't you think that it is more likely that this rule+event caused the check out?

Apparently my "workflow", which includes some of the steps you do, doesn't cause any check-out request when opening assemblies.

[richterBKSAC]

Just because Inventor asks me to check out doesn't mean that it's usual, right? At least that's what I think.

[swalton]

I don't know that Autodesk has formally listed the Derive command as part of the iComponent workflow.  Its something I have picked up over the years.

One hint is that the browser icon for the source file in a derived part is the same as the icon for the source file in a factory member.

Derived Part:

iPart Member File:

Reading your steps, it looks like you checked out all the members, but did not check them back in before the update. 

I think the key takeaway is to expect that any changes to the factory will dirty all children.  Plan the workflow so that the member files will be updated and the new versions checked back into Vault.  This can get complex if you are using Lifecycle States.  It also can get complex if you are using iComponents as design elements, not library components.

I find that iComponents work well for hardware or other elements that have a known set of variations before I check them into Vault.  I don't like using them for new designs that have unknown variations.  Think of the difference between a drawer slide that is offered in 6 different sizes vs a custom kitchen cabinet that will change for every client.

 The drawer slides work well as an iComponent in Vault and the cabinet is painful after 10-30 variations.

[richterBKSAC]

I see.

Contrary to your iPart factory file mine consists of extrusions and so on. It looks like you've put a derived part into an iPart or am I mistaken? 

Regarding the check in of the member files in my workflow, I forgot to mention that they got checked in when I checked in the factory file.

Thanks for the hint about the general use of iParts. In my case it's like the example you gave with the drawer slides, plus the custom iPart lifecycle never changes.

[swalton]

I don't think I was clear in my pictures.  The second screenshot shows an iPart member file, not the iPart Factory.  The browser node gives the name of the factory file.  If I go back to the factory file, I get the normal browser with all the feature nodes.

Autodesk may have improved the iPart-Vault workflows to reduce the need for the update assembly.  I'll have to check it out.  

[richterBKSAC]

My bad, your picture was clear enough and my member file looks the same 😉
Thanks for your help.