Labview Save File Nightmare!

[Jon Hart]

Tom,

>>>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.  The error handler is in vi.lib and is shown as a dependency of the CompactRIO project (e.g. it is shown under the 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? 

2) If I open an (RT) 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.  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

[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&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 project are 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.  If I say List Changes it reports the VI was recompiled. In the bottom lefthand corner of all my VIs  it says CompactRIO suggesting that these are RT versions.

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

Tom,

In answer to your Q's

1) There are no other VIs open at the time, only the top level one I am running.

2) I answer Save All to the Save Changes, I then deploy and run.  If I then stop the VI running and run it again I DON'T get asked to Save Changes - this is OK :).  If, however, I close the main VI and reopen it, despite there being no * on the file name (i.e. no changes), if I run it for a second time I DO get prompts to save changes to other subVIs.  These sub VI's have not EVER been opened this session.

3) The affected VIs are already RT targetted.

4) If I set about making my own versions of Labview system VI's (e.g. Format Message String and Error Handler CORE) presumably I would then have to replace all callers of the originals with my own version?  This is unworkable since we are using several third party libraries and to change all of these libraries to use the custom version would be an onerous task, not to mention a configuration control nightmare.

Any other bright ideas?

Jon

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

>>>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.  I haven't seen this behaviour in any other IDEs - what's so different about Labview?

>>>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 such a way that you do not need to "build the world" everytime.  The system has been formally designed using UML and an OO approach - it hasn't been thrown together in a lab in a day.  When your efforts to promote maintainablilty appear to be defeated by the development language, it does get you down.  Are you saying that this is a known isssue?

>>>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).  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.  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>>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.   If you suspect it is a setting of the VI, you can try

Good luck.

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

[ifg]

Hello everybody,

This thread stopped quite some time ago. Has a solution been found? Cause I'm experiencing exactly the same problem here.

I'm using LV 2009 together with a RT desktop PC.

TIA,

Frank.