Item Mapping Properties to old file versions

[csmac2004]

Hey All,

So I'm not having much success on these forums lately, but I will try again...

Lately, I've noticed that when I'm assigning items to my files, some of the items will only map their properties to an old version of my Inventor file, rather than the latest. This is causing me ALOT of grief. Is there any way to trouble shoot this and figure out why? Thanks!

Here's some photographic evidence of the misbehaviour... 🙂

This is the Inventor File:

This is the Item itself:

[mollons]

How is this property mapped? Can you include a screenshot of the mapping tab for Complete Number? What read/write settings does the property have?

Which file and item categories is the Complete Number associated to? Was the item always in the Part category?

What state is the file in? Is it locked for any reason?

Just some ideas...

[csmac2004]

Thanks for the reply.

Here is a screen shot of the mapping settings for this property. If you can see something here I've done wrong, please let me know.

This property is associated to many file and item categories, as can be seen below:

As for this part ever being part of a different category, this one in particular I know was not. The category is automatically controlled via 'Rules' of a property within the part.

It is also not locked via the item, but it is possible it was locked at the file level before that (now that the item is controlling this, I'm not sure how to double check the file level status?). I will look more into the file level locking as well then. Thanks again!

[csmac2004]

The idea of the file being locked got me thinking, so I found another file that had the same issue (incomplete property in the first version) and tried assigning an item to it. This file was not locked, and this was the first time an item had been assigned to the file. However, as you can see by the image I've attached (too big to put in as part of this post like my previous images), the item is STILL looking to the incorrect version to get this property.

[mollons]

I have tied this with normal parts and derived parts and can't reproduce the issue.

What is your workflow for generating these parts.

From the attached picture and your other post on the newsgroup it seems like you are using a combination of iParts and derived parts? What steps are you following?

Also, where is the Complete Number property first defined and when and how do you edit it to the correct value?

[csmac2004]

We have used iParts in previous projects, but due to the headaches we encountered in various forms (from drawing, to assemblies to Vault) we did not use them on these parts in question. However, every part does have a file derived into it at least once.

Basically, we deal with extruded metal or plastic. These extrusions have set profiles, so we maintain a library of these profiles as parts that contain just a sketch and blocks marked for export. We then derive these profile parts into 95% of the parts we model, bringing the sketch blocks forward to the new part which are then extruded to a length, mitred, notched, etc.

We also have gone down the road of even deriving an additional part that is a skeleton which controls the length of our parts.

Basically, each part could have as little as 1 or 2 derived parts within or as many as 9 or 10 depending on the complexity of the part and how much information we need to reference.

These particular parts have only 1 part derived, and that is just for the profile itself. As for repeatibility, it doesn't surprise me that you weren't able to repeat it as out of about 1000 parts we have for this portion of our project, I would estimate about 20 or them have this issue (at least what I've noticed to this point). If there are other iProperties that have failed to map correctly, I'm not sure if I've seen that yet.

This property itself is a custom property that is within our part template. It is a concatenation of both 'Project' and 'Part Number' (=<Project>-<Part Number>). It is the 'Project' field that was not filled in during the initial upload (in this case) that caused this property to be incorrect. The fix was done using the Property Editor within the Vault to add the 'Project' value.

iProperties for all of our parts are typically done via 'Data Cards' once the part is initially checked into the Vault. Rarely do we actually edit the iProperties directly within Inventor anymore.

Thanks again for your time on this, it is much appreciated!

Scott

[mollons]

I think I got it 🙂

Let me know if these steps are what could possibly be happening.

1. Created a new .ipt template file with a custom property Complete Number =<Project>-<Part Number>

2. Created a new .ipt based off the new template, created a sketch, and saved the file

3. Created a new .ipt based off the new template and derived the sketch into the file

4. Extruded the sketch and checked it in to Vault

--> Complete Number for the file = "-Part1" (*correct)

5. Edit the Project property in Vault to Project1

--> Complete Number for the file =" Project1-Part1" (*correct)

6. Assign Item

--> Complete Number for the Item = "-Part1" (*OOPS)

7. Check out the file and update properties

8. Check in the file

9. Assign Item

--> Complete Number for the Item = "Project1-Part1" (*correct)

I think this is happening because the file properties and item properties are actually managed differently. I am not a property expert, but there is a lot of BOM data used for items extracted from files at the time you check in the file. This BOM data may have properties in it ... which would be why a check out, update properties, and check in fixes the problem. Truth be told, I was actually a little surprised that editing the Project property in Vault automatically updated Complete Number for the file.

As to why you are seeing this with some parts and not other, it may be that a couple things have happened to those other parts. They may have been checked out and checked in since the property edit in Vault. Or instead of editing the Project property someone may have edited the Complete Number directly to input the correct value. Note in this case, Vault overwrites the formula in the property with a static value. For some reason, if you edit the Complete Number directly the item gets the right value (without the need for a check out and check in).

Hope this helps, the good news is I think you can work around this by doing a check out, update properties, and check in. I will pass on my findings to the development team in the meantime to see why the item doesn't seem to pull the right value.

Let me know if the workaround works for you...