topic Re: EXPLICIT UPDATE in Inventor Forum

EXPLICIT UPDATE

bhenderson — Tue, 14 Sep 2021 05:39:29 GMT

Gday. I'm continuing a 10+ year battle of Inventor and Vault getting along. The old favourite of "dirty files" in Inventor just keeps giving like Santa Claus!

See pic below. The IDW file is marked dirty nearly every file I open from Vault. This is just 1 of thousands of files in vault that open dirty every single time, even with the files released (locked against editing). When I look at the file diagnostics I see Explicit update and it's this I want some help with. What does this mean? I'm hoping if I can get an explanation of the meaning of this flagged entry I might get a clue about what the problem is that causes the dirty file.

Re: EXPLICIT UPDATE

SharkDesign — Tue, 14 Sep 2021 05:56:39 GMT

Should be pretty obvious:

"Explicit denotes being very clear and complete without vagueness"

But no, I am not sure, sorry. When I get files like that I usually assume it's vault updating properties or Inventor updating mass.

The only thing you can really check is if you have some ilogic set to run on this file.

Re: EXPLICIT UPDATE

bhenderson — Tue, 14 Sep 2021 06:14:39 GMT

All IDW files have 2 pieces of iLogic, and I've gone over this 100 times with Adesk tech people & a few prominent Inventor/Vault forum contributors ending in "it's no an iLogic problem". I'm okay with being told otherwise and will even supply the iLogic codes if it helps.

See below for the triggers. This problem isn't on every IDW, just a hell of a lot of them, and every IDW file has these 2 iLogic snippets and the triggers.

[cid:image001.png@01D7A983.6491B6C0]

Re: EXPLICIT UPDATE

SharkDesign — Tue, 14 Sep 2021 06:18:00 GMT

Before save would suggest that they shouldn't run.

The only other thing to check is that you have this turned off.

Re: EXPLICIT UPDATE

bhenderson — Tue, 14 Sep 2021 06:30:02 GMT

This is turned off for both codes.

As I mentioned I've gone thru the iLogic possibility many many times. it's not that. It's more in the way Inventor and Vault talk I think, but I just can't get any traction with Adesk about this. Several years ago I even supplied them my entire vault server Db and they couldn't replicate the problem.

Re: EXPLICIT UPDATE

SharkDesign — Tue, 14 Sep 2021 06:31:00 GMT

Are you part of the beta community?

Autodesk have been asking a lot about dirty files recently.

Re: EXPLICIT UPDATE

-niels- — Tue, 14 Sep 2021 06:48:13 GMT

In previous versions the 0x800 was called "rebuild", not that that is any less vague:

For me it seems to originate from the part or assembly contained on the drawing.

I usually see it when our custom "revision number" property wasn't updated properly before locking the drawing.

(like doing a synchronize on the part from Vault after checking in both part and drawing and then not updating the drawing when it needs to update the synchronized property in its titelblock)

Re: EXPLICIT UPDATE

johnsonshiue — Tue, 14 Sep 2021 19:58:05 GMT

Hi Arthur,

Do you mind sharing an example that behaves unexpectedly here or with me directly johnson.shiue@autodesk.com? I suspect an iLogic rule updates a property which causes the drawing to be dirtied.

Let me walk through the file dirtying processes to avoid confusion. Use an ipt file as an example. When a property or a parameter has been changed (or added) by the user within an ipt file, the change has to be saved. It is because if it is not saved, the change will be lost. The user will need to perform the same operation again.

What is a bit confusing is the need to "update." In a text file, everything is pretty much wyzywyg. You make a change and you see it. There is no need to update. Think about an ipt file as an Excel spreadsheet. When you make change to a cell value, the Macro driven objects (tables, charts) may not be up-to-date. You will need to run the Macro to update so that everything is up-to-date. Inventor ipt is quite similar to that. The change in property or parameter can trigger change in geometry. For performance purpose, Inventor leave it up to the user when the update should occur.

You can make 100 changes and then update once.

Drawing works similarly too. Think about drawing as an extension to the part or the assembly. As long as geometry holds true, the drawing file does not need to be saved. It only needs to be saved when the views are updated (due to change in component geometry). If the drawing is no saved, you will keep getting prompted to save after views update. Still it is optional. The drawing can stay static (deferred update).

I still believe there should be a reason you are seeing the behavior. Please share an example. I am more than happy to take a look. As always, there is possibility that we have a bug (corruption) somewhere.

Many thanks!

Re: EXPLICIT UPDATE

bhenderson — Tue, 14 Sep 2021 22:22:12 GMT

Hi Johnson.

I sent you an email with the files and a couple of screen snips of the Vault history of the IPT and IDW.

Re: EXPLICIT UPDATE

bhenderson — Tue, 14 Sep 2021 22:22:38 GMT

I am, I just can't find time to participate 😞

Re: EXPLICIT UPDATE

johnsonshiue — Tue, 14 Sep 2021 23:28:34 GMT

Hi Folks,

I took a look at the files Brenden sent me. I think I can explain the behavior. The idw file is linked to another ipt file stored in Vault (Tools -> Doc Settings -> Drawing -> Copy Model Properties). When the idw file is opened, Inventor tries to find the ipt but it is not available. As a result, it keeps dirtying the file as "unresolved."

Changing the setting to "None" will stop the recursive save prompt. I will work with the project team and see what we can do. When the iProperty model source file is unavailable, it should just take the properties as is. There is no need to save. It won't be up-to-date anyway.

Many thanks!

Re: EXPLICIT UPDATE

bhenderson — Tue, 14 Sep 2021 23:32:20 GMT

Thanks Johnson.

I've updated the IDW template and turned this off and will monitor new IDW files on release.

Re: EXPLICIT UPDATE

bhenderson — Tue, 19 Oct 2021 00:12:15 GMT

Update - turning off the "Additional Custom Model iProperty Source" did nothing when I released the file again. it's still dirty. See pic.

Re: EXPLICIT UPDATE

matt_jlt — Mon, 18 Oct 2021 05:10:59 GMT

I get the same problem, lots of files that have been updated, saved, checked in, then when opened later on, inventor marks them as 'dirty' even though they haven't been edited in any way.

This happens even with our library files that are completely locked. I end up just having to save them so i can check stuff in half the time.

Re: EXPLICIT UPDATE

bhenderson — Mon, 18 Oct 2021 05:24:31 GMT

Just the IDW for me ATM and I'm pretty sure we've narrowed down the cause. Now just to convince Adesk that a fix is needed.

I do have ongoing problems with the FG assy & members & Vault but I'm focusing on 1 big battle at a time 🙂

Re: EXPLICIT UPDATE

johnsonshiue — Mon, 18 Oct 2021 23:26:13 GMT

Hi Folks,

I would like to clarify a few things. The discussion can be a bit confusing here. First, the option "Copy Model Properties" does cause drawing to dirty. It is just if there is a change in property value. If there is none, the option does not make a difference.

Second, Brendan's issue is specific to a drawing custom iProperty changed outside of Inventor. In order to populate the property to the titleblock (drawing sheet), the drawing needs to be updated (then dirtied) by Inventor.

Hi Brendan,

I would like to understand the required "fix" here. Is it about the ability to update drawing view due to out of context iProperty edit without dirtying? If yes, there is no fix. The behavior you are seeing is correct.

If it is about Vault Job Processor not updating the drawing view, there should be a process updating the view (and the drawing will be dirtied). Task Scheduler Update Design task can do that too. Regardless, after the view is updated, the drawing will be dirtied.

My understanding here is that there is lack of a drawing update after the custom iProperty has been changed. Either the drawing is opened in Inventor manually, or updated behind the scene via Job Processor or Task Scheduler. In the end, the drawing is dirtied and it needs to be saved.

Your argument about revision tag behaving differently is totally legit. Unfortunately, it is indeed a separate process, not the same as property update. I hope I provide some clarify to the issue.

Many thanks!

Re: EXPLICIT UPDATE

bhenderson — Tue, 19 Oct 2021 00:10:24 GMT

Hi Johnson. Thanks for your update.

The "Copy Model Properties" was something you highlighted to me as a possibility for the "Dirty" file problem. Testing showed that if I turned the option off and released the file it still opened "dirty". I'm happy that this workflow is not causing my problem but it may be for others so they can also test this.

After a lot of testing involving your input, what seems to be causing the "dirty" file problem is a UDP I use on the drawing Title Block that gets updated during state change. E.g. I have the UDP on the drawing (IDW) showing the Drawing Status to the reader. Completely practical requirement, otherwise the reader doesn't know if the drawing is ready for consumption or work in progress or other. The contents of the UDP change as the file state changes.

The "fix" I am referring to is to make the drawing clean when I open it after it has been released. I don't care if the cause is Inventor, Vault, the JP or other. I simply want to be able to open the released drawing in a clean state. Not a big ask I wouldn't think. Your comment "In order to populate the property to the titleblock (drawing sheet), the drawing needs to be updated (then dirtied) by Inventor" is correct but also an unwanted outcome and I'm a bit shocked that Adesk knows of this and accepts it. The behaviour may be correct (from Adesk programmers perspective) but is 100% unwanted from the millions of users that suffer this continuing hassle. Tt's even worse when I am teaching new drafters when they open drawings they have released and see every one of them dirty. They think they've done something wrong and I spend a fair amount of time educating them about this issue.

The "fix" I want is for the title block UDP to be treated the same as the Rev Block, or some other fix to move past this problem that I've experienced for 10+ years. The Rev Block entries can be edited inside Vault and released without the user open the drawing and regenerating it. This process seems flawless as I have done several tests with just changing Rev Block data and releasing without first regenerating the drawing. And the drawing is clean after going through the Job Processor. This is what I and I think many many others want too.

Re: EXPLICIT UPDATE

johnsonshiue — Tue, 19 Oct 2021 21:19:58 GMT

Hi Brendan,

If a drawing is released (locked down), nothing should have been changed. The moment you designate such flag as an iProperty, which is also referenced by the titleblock would dirty the file. I personally think this is a process issue. You can view it as a bug on Inventor or Vault. But, I have to be honest that I don't believe it will happen. It is because such change does not trigger the necessary view update if the drawing is not opened in Inventor.

Certainly, I think it can be automated by a secondary process. The bottom line is that the sheet has to be updated.

Regarding the titleblock, it does seem like a different process.

Please take a look at this article documenting how LifeCycleState is changed. It does require the view to be updated.

https://knowledge.autodesk.com/support/vault-products/learn-explore/caas/sfdcarticles/sfdcarticles/Add-Lifecycle-State-to-a-drawing.html

I am not saying these behaviors are ideal. I am just trying to explain why they behave this way. You can disagree with me for sure. Please feel free to escalate the issues to Autodesk Product Support. The forum can help resolve issues but not something like this.

Many thanks!

Re: EXPLICIT UPDATE

bhenderson — Wed, 15 Dec 2021 01:34:05 GMT

Update : I've been working with the Global Product Support team for the last couple on months trying to get a workable solution to this ongoing annoying problem. They have used my database & templates and confirm that this problem exists - however they maintain that it is "behaving as expected". I find this so annoying!

They gave me links (see below) to knowledge base articles that partially describes "using a custom job to update the files" and I'm guessing this is to be done after the job processor has completed the release. I'm still working through this and leveraging off my VA for some input.

I'm enlightened by the process but so disappointed that this hasn't been fixed/addressed.

https://knowledge.autodesk.com/support/vault-products/troubleshooting/caas/sfdcarticles/sfdcarticles/The-Vault-jobprocessor-job-Update-Revision-Table-does-not-update-the-view-and-save-the-file.html

Re: EXPLICIT UPDATE

karthur1 — Fri, 27 Oct 2023 16:39:28 GMT

@bhenderson wrote:

Gday. I'm continuing a 10+ year battle of Inventor and Vault getting along. The old favourite of "dirty files" in Inventor just keeps giving like Santa Claus!

See pic below. The IDW file is marked dirty nearly every file I open from Vault. This is just 1 of thousands of files in vault that open dirty every single time, even with the files released (locked against editing). When I look at the file diagnostics I see Explicit update and it's this I want some help with. What does this mean? I'm hoping if I can get an explanation of the meaning of this flagged entry I might get a clue about what the problem is that causes the dirty file.

I know this is an older thread, but I ran across this same issue today with an idw. I could save the idw and close it. When I reopened it, it wanted me to save again. It also showed as "Dirty" in the diagnostic screen. The model was up-to-date, there was not any iLogic rules and the mass was not changing. I tried recreating the idw from new and placed the same iam on the new idw. When I did this and closed/reopened the idw, the file was not dirty.

So, to fix my trouble idw, I deleted all the views, saved and closed the idw. Then reopened the idw and re-placed the views. Now when I saved and closed the file, it did not require an update.

Not exactly sure why this worked, but that is how I resolved the "Explicit Update" causing my idw to constantly wanting to be checked-out and saved.