Labview Save File Nightmare!

[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 which
also 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 for
the Fieldpoint controller, causing one prompt, then get  'added' back (not stripped?) when compiled for the PC side,
resulting in another prompt to save.  Could something similar explain what you are seeing on CRio?  I never
investigated further, but it sounded plausible.  I still see the behaviour now, with no apparent ill effects.  Maybe a similar
thing is happening, propogating back up through other .vi files?

Matt

[Jon Hart]

Matt,

I think you may be on to something there.  Do you get the prompt when simply opening and closing a VI though?

Regards

Jon

[Riconquistiamola]

Hello everyone. I fielded this question a looong time ago and managed to recall the documentation for this.

General Error Handler Core.vi has Unsaved Changes --
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

[Matthew_Williams]

Hi Jon.  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.  Whenever the prompt appears, it is always in response
to closing a higher level .vi.

Michael K said it better than I could; thanks.

Matt

[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->Targets and Devices->cRIO 9014

I have a single vi called "Simple.vi" with three components

A numeric slider going into a "Format into String".  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.  This makes no difference.

I am at my wits end - can anyone offer any more advice?

[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!)  I dont have a Windows version, 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

[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,

[muks]

Ben,
      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!!