Vault Library File Smudging

[Curtis_Waguespack]

Can anyone explain the behavior shown in this video, where copying a library part in an assembly causes that library part to show up in the file list of the Save tool?

When this happens and a user uses the Yes to All option it causes issues that prevent the user from being able to check in. In this video it is obvious that the Yes to All option is saving the library file, but in real life the file is getting saved in context of saving a large assembly, so it is not apparent to the user that Yes to All, is causing a library file to get saved.

In my mind the file is in a library path that is defined in the project file ( .\Libraries ), so it should not be able to be saved (that's the purpose of the library).

I have checked and made sure that the file is migrated to the latest version, as I am aware that that can cause file smudging, but I can't seem to figure out how to prevent the file from showing up in the Save dialog list.

Thanks in advance,
Curtis

[Mark.Lancaster]

@Curtis_Waguespack

What Inventor and Vault version?  Or did I miss it in your screencast?

Also for a test can you do the following.

1.  Disable the routed system module

2.  Start a new assembly and repeat the process

[Curtis_Waguespack]

Hi Mark,

Thanks for looking at this!

Versions info:

(sorry I forgot to include that )

Inventor Pro 2015 with Vault Basic 2015

1.  Disable the routed system module - roger that

2.  Start a new assembly and repeat the process - roger this also, (although I didn't show that part in the video)

Same result.

Is this just the way it works?

Or is the behavior of Vault wanting to check out the library part, and adding to the Save list (set to No) when a new instance is placed not typical behavior?

It seems to me that it shouldn't be doing this, but I can't really recall.

Thanks again,
Curtis

[Mark.Lancaster]

@Curtis_Waguespack

Recently I just got a new laptop so I haven't had the chance to install all my Vault structures on it.  So I can't confirm if that behavior is correct or not.  I would assume if its a library part then you shouldn't be able to edit it out of turn.   Are you logged in with Admin rights or a normal Vault using?

In addition I noticed the components had the "bluish" piping tee and I was thinking maybe the routed system rules were doing something even though you were not creating a routed system model.  So that's why I wanted you to try to see if the problem was there when the module was disabled. 

Update:  @Curtis_Waguespack In your second screencast the browser pane is only showing the vault structure.  Can you just toggle over to the Inventor model side and confirm the components do not have a bluish piping tee as the icon.

[Curtis_Waguespack]

Hi Mark,

So I thought you were on to something with the tube and pipe add in (and you might be still ) , but in testing here is a very reproducible set of steps that we can go through to demonstrate the issue with a some library parts but not others (still investigating).

• Basically I start with an assembly and place this one library part in it and then save the assembly, and all is well.
• I check the part file to see if it is smudged ( I saw your info on this earlier today ).
• But then if I place another instance of this part, it get's smudged ( eAuditInvalidate )
• This is not the case with all part files in the library.

Here's a video of this as well as the part file as an attachment in case anyone wants to look at it (it's an Inventor 2015 file).

Thanks!

Curtis

[Curtis_Waguespack]

Update:

So this appears not to be a Vault issue or a Library issue, but a Tube and Pipe Component issue.

Here's what I did:

• I had an un-vaulted assembly file
• Into this assembly I placed the library part that demonstrated the issue.
• I then saved a copy of that part as a standard part, at the root of the project.
• Then I replaced the library part with this new part in the assembly
• So now I have an un-vaulted assembly with an un-vaulted part that is not a library part.
• When I copy and paste the file it demonstrates the issue, and wants to be saved.
• I open the part and I run an iLogic rule that displays the internal Tube and Pipe component iProperty information in a dialog box (in the video it runs off the screen, so it just looks like a bunch of gibberish popping up out of no-where)
• It then clears all of that information.
• I run the iLogic rule again to confirm that info is cleared, demonstrated by a blank dialog box
• Now I return to the assembly and paste a new instance, and the part no longer demonstrates the issue.

I tested this with a few parts and found stripping this out fixed them all.

Here's the iLogic rule that strips out this info, in case someone is interested:

 'https://knowledge.autodesk.com/support/inventor-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Remove-Tube-and-Pipe-Authoring-from-part.html
 'RemoveTPAuthoringInfo
 
 ' Dim oProperty As Property
oProperty = ThisApplication.ActiveDocument.PropertySets.Item("32853F0F-3444-11d1-9E93-0060B03C1CA6").ItemByPropId(56)
 
'check for info
If oProperty.Value <> "" Then
MessageBox.Show("This file has Tube-and-Pipe Authored info in it.", "iLogic")
'clear it
oProperty.Value = ""
End If
 
'check again
If oProperty.Value <> "" Then
MessageBox.Show("This file has Tube-and-Pipe Authored info in it.", "iLogic")
Else
MessageBox.Show("Tube-and-Pipe Authored info cleared.", "iLogic")
End If

[Mark.Lancaster]

@Curtis_Waguespack

Glad to hear that you figured it out...    When I saw the bluish tee icon in the screencast I was wondering if something about the routed system rules causing it.  I've come across other issues as well that were related to routed system rules when the tube & pipe module is loaded.  Granted this article ends up talking about a workflow issue/bug but it does document an issue I also saw with the bluish tee icon and you are trying to replace the component.

[Curtis_Waguespack]

@Mark.Lancaster

Thanks for the link. We're still looking into this, and have opened up a support case.

@Bert_Bimmel

Hi Bert, 

I found your detailed post at this link:

Stop telling me I need to save something I haven't changed

And read where you are relating the eAuditInvalidate flag with Mass Props being outdated. Unfortunately I can not seem to see the connection. Do you have any more information on this flag? or more information on how you were figuring out all of the differences in the various types of file smudging that is going on?

If you review Post 6 in this thread, you can see that we've narrowed it down to the eAuditInvalidate flag using this file: 6110.ipt ‏217 KB

But I can't seem to determine what is tripping the flag.

Thanks,

Curtis Waguespack

[cbenner]

Going to have to keep this thread for future reading. All I do is Routed Systems, and it seems that every time I open a saved and checked in assembly, using Open from Vault to make sure I've got the latest, I have dozens of components (library or Content Center) that need to be checked out because they have "changed".  This happens even though on the last check in, all local files were deleted, and any older parts were migrated.  Si, I check them out and do a save (yes to all), because if I don't I can't check back in.... and guess what.... they migrate again!  As if they had not been migrated on the previous check in.

Maybe there is something in this thread that will shed some light, but I just don't have the time right now to look at it.  Thanks for sharing guys!

[Bert_Bimmel]

Hi Marc,

there is no official information availlable on this flag. Everything i posted is based on my own observation. An

inquiry at my Autodesk-Dealer lead to the answer "That's none of you're business" (well just a little more

politely expressed, but that was basically the message).

But i downloaded the sample file, conducted a few experiments, and found out, that you're in fact dealing on a

MassProp-issue: At a first glance on the part itself, everything seems to be fine: the "update massprops"- button

in the iProperty-dialog is grayed out, there are nice values presented, and even the value of the "Valid

MassProps" - Property in the "Design Tracking Properties" is "31", i.e. all five bits set (something else, where i

would appreciate some more information on the meaning of the bits)

But then try out the following:

1: Set your application options to "update Massprops -> Parts only" on the General tab. Then create a new Assembly

from scratch, insert your part, and save the assembly. The "eAuditInvalidate"-flag of "6110.ipt" is not raised.

2: Do the same again (of course without saving 6110.ipt before), but set your Application options to "update mass

props -> parts and assemblies. Now, when you try to save the assembly, the "eAuditInvalidate" flag of "6110.ipt"is

raised.

3: Open 6110.ipt alone. Go to your VBA-client, and type "debug.Print

ThisApplication.ActiveDocument.componentdefinition.massproperties.mass" into the immediate window, hit Return, and

return to Inventor. Now have a look at your part's editflags via the "about Inventor"- Window (control-"d"). The

"eAuditInvalidate"-flag is raised.

Conclusion: Inventor is fooling you again by presenting self-contradicting information to you. Apparently he has

once again "forgotten" to perform some pending updates.

Here some more Information about updating MassProperties:

When you edit the geometry of a part, and the massprops aren't updated, ('cause the updatemasspropsonsave-option

is not active on your machine, and you haven't performed it manually), next time you open it, and do update the

massprops (either manually or automatically upon saving on a machine, where this option is active) the

"eAuditInvalidate"-flag is raised.

On the other hand, when changing the mass by altering the material without performing any geometric changes, the

massprops don't need to be "updated". they're automagically correct "without updating" (the volume and

"normalized" moments of inertia don't need to be recalculated, you only have to apply another proportional factor:

the density"

Now, when dealing with Assemblies, it gets even more confusing:

Once again the Example from my post on the MFC-flag:

ASM_2.iam
|
'-> ASM_1.iam
      |
      '-> PRT_1.ipt

We have changed the mass of PRT_1 by editing it's density without applying any geometric changes.

Now we open ASM_1:

-It's massprops are presented as automagically up2date in the iProps-Dialog.
-The eAuditInvalidate flag is not raised
-The "Valid MassProps" - Property in the Design Tracking Properties (DTP) ist volatilely set to "1" i.e. MassProps

are NOT up2date
-Last time, ASM_1 was saved, the Massprops were correct, thus the file on disk does still contain the outdated

values
-When we save ASM_1 now, the values in DTP are updated: In case the updatemasspropsonsave-option is active for

both, parts and assemblies, the correct values are written to the propset, otherwise the "Valid MassProps"

property is reset, and the Mass is not updated in DTP (although apparently known to Inventor).

Assume, we haven't opened and saved ASM_1 before, but open ASM_2 instead:

When we go to the "Physical"-tab in iProperties, the fields do all contain "-" and the "update"-button is active.

Klick it! now both, ASM_1 AND ASM_2
have their "eAuditInvalidate"-flag raised.

Still not lost?

Open the orignal and unaltered ASM_1 together with an also unaltered PRT_1.
Open PRT_1 for edit, change its Material, and return to ASM_1 without saving. now the "Valid MassProps"-Property

of ASM_1 is reset in Memory, whereas that of PRT_1 is not.

In the end, i cannot reproduce and thus explain the indefinite masspropstate of your part.

All i can say, is that these experiments strongly indicate, that "eAuditInvalidate" has something to do with

outdated Massprops.

BUT(!!)...

...you can also raise this flag without fumbling with massprops:

Take the Example from above:
Edit the "Part Number" property of PRT_1 using the Property-handler inside Windows-Explorer.
Open ASM_1.
Now, the BOMRequiresUpdate-flag inside the API is raised (this is none of the "eBlablabla" -flags from the save-

dialog).
Update the BOM by klicking on the BOM-button on the "Assemble"-Ribbon.
Check out your edit flags: the only one raised is "eUpdateCmd".
Close it without saving.
Open ASM_2 instead.
Click on "BOM"
Now open ASM_1 and check its editFlags!....

... Any questions???

PS: I personally do not consider it a good idea to make library parts adaptive, or reuse adaptive parts in another

assembly, or using adaptivity at all together with Vault.

PPS: Inventor gives a da mn on what the vault says about any file. You cannot prevent Inventor from demanding write

access to any file due to some phantom pain, by not checking it out, "releasing" it, or putting it inot a library-Folder.

On the other hand, the best way to completely mess up the data integrity inside your vault is to ignore updates

you consider illegitimate, calm Inventor by saving them "out of turn", and then check in the superior assembly ->

now the next one to download the assembly cannot get the expected version of the dependent file as it does only

exist on your workstation, and the vault has absolutely no clue, that the two files he is delivering to the next

workstation do not fit together. Maintaining data integrity and prevent producing garbage takes up 70% of my time,

and requires very much knowledge about inventor's internal file structure and updating mechanism, which i have

gathered throughout all the years i have been working with this System (which still consumes another 20% of my

time, as yet, i still do not know everything)

[Curtis_Waguespack]

Hi Bert_Bimmel,

Thanks for all of the information!

>>  I downloaded the sample file, conducted a few experiments, and found out, that you're in fact dealing on a MassProp-issue

After I posted yesterday, I investigated the mass properties updates and was able to see some of this in action. We're still working towards understanding all of this so that we can come up with a way to get past these issues when they arise.

>> PS: I personally do not consider it a good idea to make library parts adaptive, or reuse adaptive parts in another

assembly, or using adaptivity at all together with Vault.

Agreed. That jumped out at me as well. It is something that we'll have to address with some clean up to our library files.

>> PPS: Inventor gives a da mn on what the vault says about any file. You cannot prevent Inventor from demanding write

access to any file due to some phantom pain, by not checking it out, "releasing" it, or putting it inot a library-Folder.

This really speaks to the bigger issue we're trying to solve. We have library parts that we do not want anyone to modify, ever. But the Vault doesn't honor libraries, and allows users to check in modified versions. The only way we have found to ensure that modified library parts don't get checked back in, is to check the parts out with a "librarian" account. The issue then becomes the files getting smudged, which then creates a situation where the top level assembly can not be checked in, because one or more library files within it are smudged and modified locally, but checked out to the "librarian".. This results in a stopping issue for the users, as they can not check in their assemblies.

Thanks again for the time and effort involved in looking at this,

Curtis

[Anonymous]

Hi Curtis,

I know I am replying to an old message but just in case you or anyone else comes across this thread to read it.

"We have library parts that we do not want anyone to modify, ever. But the Vault doesn't honor libraries, and allows users to check in modified versions. The only way we have found to ensure that modified library parts don't get checked back in, is to check the parts out with a "librarian" account. The issue then becomes the files getting smudged, which then creates a situation where the top level assembly can not be checked in, because one or more library files within it are smudged and modified locally, but checked out to the "librarian".. This results in a stopping issue for the users, as they can not check in their assemblies."

I work in a similar environment.

When a part is in the Vault tab of the model tree and an asterisk * appears next to the filename, this indicates that there are unsaved edits made to the part. I am going to call this a "floating edit" because Inventor believes for whatever reason that the part is modified but your local part isn't actually modified and its status within vault will reflect that.

However, if you open and save this part, your local file will now become modified and the part file will now have a green circle appear next to it in the Vault tab of the tree.  Now that your local file has actually been modified you can do a Vault -> Refresh and have the part revert back to being unmodified, allowing you to check in the parent assembly.