Labview Save File Nightmare!

[Jon Hart]

Hello,
 
I am working on a large project which calls upon many sub VI's which often are 3rd party supplied.  Whenever I make a small change to a VI and try and run my project (it's a real-time cRIO based app), Labview prompts me that a completely non-related VI needs saving.  Often it is a VI in a 3rd party LLB that CAN'T be saved because I dont have necessary access rights.  If I say cancel, I can't run my project because Labview says "You can download and run without saving".  This is driving me nuts!
 
I stress, the unchanged VI's that "need saving" (not) have not EVER been changed by me as they are 3rd Party or NI supplied.
 
Any ideas?
 
Regards
 
Jon
 
p.s.  Please don't ask me to post the code as it is enormous and dependent on lots of 3rd party VIs.

[Adnan Z]

Hi Jon, Hope you are doing well today! I don't see a reason as to why you should be getting that dialog if it is third party supplied and you don't have access to the VI. I would suggest mass compiling the directory even though I am not sure if that would help. Is it possible for you to only post one of the NI VIs or a third party VI that is giving you this issue?

[Graziano]

Hi!   When you're prompted to save that VI, select "Explain changes..." button.   I suppose that third party library rely on some other LabView libraries, that were located in a different location on the PC where third party libraries have been developed.... but actually I don't know, I'm only guessing :smileyhappy:    Anyway, please, report what's written in "explain changes..." window, so that we can help you a little more.   Have a nice day!graziano

[lmtis]

Often some of the third party packages have been developed in an older version of LV, and LV will want to save them for the version that you are running.

[JoeLabView]

Does the 3rd party code have documentation describing what it does and any limitations that the code has? 
When buying 3rd party code, make sure it has documentation. 

[Ben]

I'll jump to the game of trying to help with very little to go on.
Try setting all of the third party VI's as read only and then check both of the boxes shown below to see if that gets rid of those messages.
<img src="Loading Image...">
Ben
PS: Thanks to Mike Porter for teaching me this last night. :smileywink:Message Edited by Ben on 04-29-2008 08:46 AM


Dont_Save_Changes.JPG:
http://forums.ni.com/attachments/ni/170/319860/1/Dont_Save_Changes.JPG

[Jon Hart]

This post might be inappropriate. Click to display it.

[muks]

Ben, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; By seeing your post i learnt one of the most worthy things today.Can you beleive it i was in the mindset that the number of undo is fixed in LabVIEW and it is around 8. Ah! So there is indeed an option to increase the undo. Cltrl+Z here I come!!:smileyvery-happy:

[Jon Hart]

It's not that simple as it isn't always the same VI, but usually it is to do with&nbsp;ones that use "General Error Handler CORE.vi".&nbsp; So for example, just now I loaded the project from scratch, opened my GUI VI, then&nbsp;closed it (making no changes)&nbsp;
It tells me that NI_3dgraph.lvlib:Basic Properties.vi has unsaved changes
Affected Items:
NI_3dgraph.lvlib:Basic Properties.vi
NI_3dgraph.lvlib:3D Surface.vi
Format Message String.vi
General Error Handler CORE.vi
If I click "Explain changes", all the above items say "VI recompiled".&nbsp; The top two also say "External component modified since last VI Save"
Any Ideas?
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;

[Ben]

Try doing a mass compile.
Warning: that can take a while.
Ben

[Jon Hart]

Ben,
That has done the trick!&nbsp; Will let you know whether it is a complete fix further down the line.
Cheers for now!

[Dennis Knutson]

If you are getting prompts to save NI functions, then it's possible the third-party app did something stupid like including vi.lib functions in the llb. Open the llb and see what's there. If there are vi.lib functions, delete them. There have been numerous changes to low level subVIs over the years and unless you get rid of old ones in an llb, you will always be prompted to save changes and you DO NOT want to be using obsolete low level functions and you DO NOT want to be modifying any of the VIs in your current vi.lib.

[Matthew Williams]

If I might offer another possible explaination: I noticed the frequent prompts to save "General Error Handler CORE" working in an RT application on Fieldpoint whichalso has a PC side component.I asked at NI Week last year and the answer was that the gui elements of the .vi get stripped off when compiled forthe Fieldpoint controller, causing one prompt, then get&nbsp; 'added' back (not stripped?) when compiled for the PC side,resulting in another prompt to save.&nbsp; Could something similar explain what you are seeing on CRio?&nbsp; I neverinvestigated further, but it sounded plausible.&nbsp; I still see the behaviour now, with no apparent ill effects.&nbsp; Maybe a similarthing is happening, propogating back up through other .vi files?Matt

[Jon Hart]

Matt,
&nbsp;
I think you may be on to something there.&nbsp; Do you get the prompt when simply opening and closing a VI though?
Regards
Jon

[Matthew Williams]

Hi Jon.&nbsp; I don't think I have ever seen the prompt on opening a .vi, but have seen it when closing or when targeting the FieldPoint controller.&nbsp; Whenever the prompt appears, it is always in responseto closing a higher level .vi.Michael K said it better than I could; thanks.Matt

[Riconquistiamola]

Hello everyone. I fielded this question a looong time ago and managed to recall the documentation for this.<a href="http://digital.ni.com/public.nsf/allkb/0458B73E4A7CFC0A8625727300749A77" target="_blank"> General Error Handler Core.vi has Unsaved Changes</a> -- The recommendation if you do not want this behavior is to make a copy
of both the General Error Handler.vi and Simple Error Handler.vi for
Windows, PharLap, and VxWorks and place the recently created VI's in
the user.lib folder or a Real-Time palette for future use. Modify the
part of the code that needs to run on a specific target. Refer to this
snapshot for location of the VI and the code.Unfortunately, the suggestions contained in this KB may not be of much help for your read-only, 3rd party LLBs.Cheers

[Jon Hart]

Hi People,
Had to bring this back to the top. Project getting bigger - problem getting worse. Driving me nuts!!!!
So I create the simplest project possible for the cRIO.
New Project
New-&gt;Targets and Devices-&gt;cRIO 9014
I have a single vi called "Simple.vi"&nbsp;with three components
A numeric slider going into a "Format into String".&nbsp; The error out is fed to "Simple Error Handler" which is the source of all my woes.
I open the VI, make no changes and then close it and get the Save Changes prompt - Ahhhgg!
It tells me that
Format Message String and General Error Handler CORE have unsaved changes.
So I follow previous advice and remove the case statement from General Error Handler CORE which has the OS switch.&nbsp; This makes no difference.
I am at my wits end - can anyone offer any more&nbsp;advice?
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;
&nbsp;

[Tom O]

Hi Jon, Once the VI is compiled for either cRIO or Windows (etc....) it shouldn't need recompiling whilst on that platform. Have you tried, as Dennis suggested, to have a copy of the VI compiled for cRIO and another for Windows? This way you could use the correct one without worry about having to recompile and save.Regards,

[Jon Hart]

Tom,
I appreciate your reply but I think there are some wires crossed here (no pun intended!)&nbsp; I dont have a Windows version,&nbsp;unless of course you are refering to when you run in debug mode where the cRIO front panels are displayed on the PC.
Could you tell me how to verify that I am not compiling a Windows version by mistake.
I described a very simple test in a previous reply to reproduce this behaviour - could you try it out for me please?
Jon
&nbsp;

[Tom O]

Hi Jon, I did try your suggested replication and it only works if another VI is open with the simple error handler in.If I make the project exactly as you've described and have no other VIs running, I can open and close my RT VI without getting any save messages. This is because the error handling VI that's in memory (and the one now saved to the disc) has been most recently compiled for RT.However, if I have another VI running that has the error handling VI (for example) in it, the instance of that VI in memory is currently compiled for Windows. Each time I run it for RT, it has to recompile the VI. Therefore, when I close the VI, LabVIEW tries to save the version that's been recently compiled for RT every time.To avoid this, either:- Make sure that no Windows-targeted VIs are open that use the VI in question. This probably isn't viable in 90% of cases, so see below.
- Create a new version of the library VIs you need (error handler in this case) on your hard drive. Compile this VI for RT (add it to an RT target on a project and run it) and then use that RT-compiled file on your RT system whenever you need it. This way you have a copy on your hard drive (and potentially in memory) for Windows, and another for RT. This is the method that Dennis described; add the VI to your palette (Tools » Advanced » Edit Palette Set) and use that in future on your cRIO.
I hope this explanation makes sense, let me know if you have trouble with these workarounds.Regards,

[Jon Hart]

Tom,
&nbsp;
&gt;&gt;&gt;Create a new version of the library VIs you need (error handler in this case) on your hard drive. Compile this VI for RT (add it to an RT target on a project and run it) and then use that RT-compiled file on your RT system whenever you need it. This way you have a copy on your hard drive (and potentially in memory) for Windows, and another for RT.
What I'm not getting here is that I don't have a Windows version.&nbsp; The error handler is in vi.lib and is shown as a dependency of the CompactRIO project (e.g. it is shown under the&nbsp;RT target).
Questions:
1) If I am running an RT Target in debug (and that RT code has the error handler), is Labview compiling a Windows version?&nbsp;
2)&nbsp;If I open an (RT)&nbsp;VI in Labview, Is Labview creating a Windows version just so I can "see" it.
3) I get the save file problem even if I do a full real-time build and deploy.&nbsp; After I have built the project, when I deploy it, it tells me that I need to save changes to VI's. How can this be after I have just built it?
Regards
Jon
&nbsp;
&nbsp;
&nbsp;
&nbsp;

[Tom O]

Hi Jon, The same VI is used for the RT target and for Windows. You don't have two versions of the VI on your hard drive. However, when you run the VI on either system, the VI is compiled down to machine code that is suitable either for Windows or your RT system. LabVIEW does this for you in the background - RT compilation is one of the functions of the RT module for LabVIEW.The VI is saved including its compiled machine code, so when different targets open/run the VI, it's compiled for that target. When closed, the VI has changes which it wants to save. VIs contain three things: the user interface (front panel), the source code (block diagram) and the machine code (the result of compilation).I'm going to talk about a Windows VI and an RT VI to explain further. By this I mean a VI running on Windows (targeted to your PC) and one running on RT (targeted to your controller). Each of these VIs contain the error handler VI, which is compiled as part of the Windows and RT VIs.The issue you're seeing is that (I suspect) you have a Windows version of the VI open as well as an RT version. This means the VI can't be modified on disk when you close your RT VI because it's still in memory as part of the Windows VI. If the Windows VI is closed first, you can save over the version on disk with the recently-compiled RT code and you'll only be prompted to do so once. If you then open&amp;close the Windows VI again later, it will ask you to save that again with the newly compiled Windows machine code.By making two separate copies of the VI (and its compiled machine code) on your hard drive - one for RT, one for Windows - you should find that the VI is compiled and saved once, and is fine thereafter. Otherwise any time you use the VI on a different target, you will be prompted to save it.Finally, please note that having an RT VI front panel open does not alter the target for which the machine code is compiled. So even if you have an RT front panel open in Windows, the VI is compiled for RT.I hope this all makes sense! As I say, I think the best workaround for you would be the one that Dennis has suggested; having a copy of the VI on disk for each target.Regards,

[Jon Hart]

Tom,
Without wanting to sound like a stuck record - I don't have a Windows version of my software, only one for the RT Target.
Here's what I'm doing in detail
1) I have made sure that all VIs in my&nbsp;project&nbsp;are&nbsp;saved and closed.
2) I right-click on my startup VI and select Run. The VI front panel appears and...
3) I get prompts to Save Changes.
I have noticed that if I open Format Message String.VI or Error Handler CORE.Vi, the moment I open them a * is amended to the filename meaning a change has been made.&nbsp; If I say List Changes it reports the VI was recompiled.&nbsp;In the bottom lefthand corner of all my VIs &nbsp;it says CompactRIO suggesting that these are RT versions.
&nbsp;
&nbsp;
&nbsp;
&nbsp;

[Tom O]

Hi Jon,OK, in that case, a couple of questions:- Are any other VIs open at all when you see this?
- With all VIs closed, if you save the changes at the first prompt and then run the VI a second time, do you still get the prompt?
- Have you tried making a copy of the affected VIs to another location on disk to be compiled for RT?
Message Edited by Tom O on 08-06-2008 02:38 PM

[Jon Hart]

This post might be inappropriate. Click to display it.

[Tom O]

Hi Jon, Whilst it's odd that you get the save file dialogue so often, you're going to get it from time to time during normal development anyway. Without duplicating VIs, it's not feasible to expect no save messages - you're code is going to get recompiled sooner or later!Am I right in thinking that this is a problem because it asks you to save protected VIs? If so, I think you're going to need to get copies of those VIs that aren't protected so that you can save re-compiled code.Please let me know if this isn't the issue!Regards,

[Jon Hart]

Tom,
&gt;&gt;&gt;Whilst it's odd that you get the save file dialogue so often, you're going to get it from time to time during normal development anyway.
Er, why? I wouldn't expect to be prompted to save a file if I haven't ever opened it or modified it.&nbsp; I haven't seen this behaviour in any other IDEs - what's so different about Labview?
&gt;&gt;&gt;Without duplicating VIs, it's not feasible to expect no save messages - you're code is going to get recompiled sooner or later!
In large software projects (like this one), one aims to reduce the re-complie time by designing the software in&nbsp;such a way that you do not need to "build the world" everytime.&nbsp; The system has been formally designed using&nbsp;UML&nbsp;and an OO approach - it hasn't been thrown together in a lab&nbsp;in a&nbsp;day.&nbsp;&nbsp;When your efforts to promote maintainablilty appear to be defeated by the development language, it does get you down.&nbsp; Are you saying that&nbsp;this is a known isssue?
&gt;&gt;&gt;Am I right in thinking that this is a problem because it asks you to save protected VIs? If so, I think you're going to need to get copies of those VIs that aren't protected so that you can save re-compiled code.
Presumably LV would tell me if the file is protected if it was (and I haven't seen any messages to this effect).&nbsp; All I do know is that the problem seems to come from the Labview error handling functions and VI's that are built on them.&nbsp; If this was any other language, I would say that this feels like a circular dependency issue.
Regards
Jon

[JMota]

I might I have seen this problem before but I don't remember if I was able to fix it or not. In any case, I agree it is painful. Here are some ideas of things you can try: + open the VI Properties&gt;&gt;Execution tab for the VI(s) that are giving you trouble, and try:+ turning off the enable debugging for the VIs with the problem+ turning off auto error handling+ if there is a "Autopreallocate arrays" (or something like that) setting on them, disable it.+ divide and conquer the trouble VIs: remove functionality from the VI (e.g. disable the whole block diagram with the disable structure) and try it out. By doing this you might be able to identify if there is a piece of code in the VI that is causing the trouble, or whether it is a setting of the VI what is causing it.My guess is that there is either a setting on the VI(s) or code within them that is causing this save file nightmare. Just need to figure out what that is, and workaround it. :smileysad:&nbsp; If you suspect it is a setting of the VI, you can try Good luck.:smileysad:

[Tom O]

Hi Jon, Sorry, it looks like I had some misconceptions about your project - I thought it was still in active development and that you'd be recompiling code quite a lot anyway. It sounds like JMota has some good suggestions, let us know how you get on.Regards,