What factors can cause a Proj file to open Dirty (LV 2009) ?

[Ben]

Update from support on this issue:

This may be rolled into an existing CAR "another CAR #200678" which wants to blam it on RT. No RT in my case.

Ben

[Andrey_Dmitriev]

I have seen such behavior lot of times with LabVIEW 8.6. The root cause was - .net.

For example, attached project opens always with asterisk with LabVIEW 8.6 (because "attributes was changed" or something like that).

And every time the string

<Property Name="NI.PreserveRelativePath" Type="Bool">true</Property>

added or removed. I mean - if this string exists, then by next save will be removed. Then open project again, and this string will be added again.

But with LabVIEW 2009 this problem goes away in my case (but not in your case).

I think, something wrong happened in Dependencies section - this section seems to be updated by every open dynamically, and from open to open with "different logic"...

Try to compare projects files before and after. No any differences?

Andrey.

Message Edited by Andrey Dmitriev on 02-16-2010 04:15 PM

[Ben]

compare proj file before and after show no differences.

Ben

[Ben]

---

Ben wrote:

---

Ravens Fan wrote:

For my situation:

LVOOP no

DAQ - no

TDMS -no

CW 3D graph -no

RT -no

Auto-populate -no

VISA to interface with serial device - YES

 1 dynamically called subVI, about 56 of my own subVI's in the dependency list, along with assorted VI.lib and OpenG dependencies.

...Message Edited by Ravens Fan on 02-12-2010 07:34 PM

---

We have an over-lap on VISA

Most of the Classes I am using for I/O (Serial DAQ-AI, DAQ-Counters) use templates to realize servers for each sub-system.

I keep my dependancies pretty clean but I can't claim it clean at the moment.

I am only seeing this on proj files that came from an earlier version (so far).

Makes me think there is some mutaion code in LV 2009 that is not finishing the job when we save.

Ben

---

Another data point to add to the list.

I just opened an app that does NOT use VISA and the project did not re-open dirty.

This app does not use LVOOP but does use XControls.

From where I sit this starting to look like it has something to do with maybe the VISA controls.

Ben

[RavensFan]

Ben,

For clarification, what do you mean by "keeping the dependencies clean"?  Does that mean you make sure all VI's that would show up under dependencies you have explicitly added to the project?

I think there are several hidden factors that could cause the dirty dot, and in my case I'm still leaning towards changes in the VI's under the dependencies tree.  I've been working on the project lately and have not had the dirty dot show up.  But all my changes have been aesthetics, or fixing any errors I might have in string constants that feed message dialogs.  I haven't done any changes to the VI hierarchy in over a week, and during that time, the LV project file itself has not changed or asked to be saved.

I'd still like to hear a reasonable answer to this question I asked earlier,  "if the dependencies are automatically updated when the hierarchy is loaded when you open the project file, then why is the list of dependencies even stored in the .lvproj file?"

Actually, the only answer I can think of myself right now is that it is storing the order they show up.  Because you can resort the list such as to make it alphabetical, it is storing the list in that order every time the project file gets saved.

-Bill

[MichaelAivaliotis]

I disagree. I see this happening to apps that don't have any Hardware IO controls or even VISA. Keep looking. I think it's related to upgrading old project files.

You open a project, it shows dirty. You make no changes. All you do is save it. Close it, then re-open it. It shows dirty again. The hierarchy is unchanged. 

Message Edited by Michael Aivaliotis on 02-18-2010 01:02 PM

[Ben]

Clean = If one of my VI's shows-up there, I move it to a virtual folder*.

I don't do it all of the time cause... I ain't perfect!

NI has a copy of my stuff so hopefully they will find at least what is affecting my projects.

Ben

* I don't have good reason to do that. Since I code for other developers, keeping everything organized in virtual folders makes it easy for me to find what I need when they are looking over my should wondering "Was this guy worth all I spent?". Finding stuff fast never hurts. Trying to fill the silence while I am scrambling for the VI I want seldom leaves a good impresion.

[Ben]

---

Michael Aivaliotis wrote:

I disagree. I see this happening to apps that don't have any Hardware IO controls or even VISA. Keep looking. I think it's related to upgrading old project files.

You open a project, it shows dirty. You make no changes. All you do is save it. Close it, then re-open it. It shows dirty again. The hierarchy is unchanged. 

Message Edited by Michael Aivaliotis on 02-18-2010 01:02 PM

---

Well that rules out the VISA over-lap.

So far the only common factor seems to be an old project that was updated.

Ben

[Nathan West]

I have this same problem on both 8.6 and 9.0 on projects started from scratch and from projects upgraded from previous, on both real time and normal targets, on both internal and FPGA based designs.

I also use real time modules and they are even worse.  My current project even prompts me to save VIs in the vi library like "format message string.vi" "general error handler CORE.vi" and "general error handler.vi"

If I just open my project, then it is flagged as changed.  If I open a vi in the project, it is flagged as changed.  If it try to deploy it to the real time target and run it (without editing anything) then it gives me up to 16 VIs to save including many from the labview vi library.  If I use a library but never even open the vi's within it, it is marked as changed and has to be resaved before I can deploy to the target.

It is highly annoying and makes version control impossible.  Since everything is always resaved there is no way for SVN to know what has and has not been edited so I have to manually track which files I actually edit and which labview is just overwriting for no reason.

If there is something I can do to keep this from happening, I would appreciate knowing about it.  Otherwise I hope that NI is working on fixing it!

Nathan

[Ben]

Hi Nathan,

Your situation may be a little different because of teh RT component. The error codes that can be terturned by the general error handler can change depending on the environment. WHen we target a RT target the general error handler picks-up RT error codes so the linkage gets changed. THe other thing that may help is doing a mass compile.

But if you still think your project falls into this catagory, then give NI a call and tell them you have another example to include with the SR# I posted earlier. The more evidence NI has the better they will be able to help us.

Thank you,

Ben