Unable to display the front panel of the VI

[Jeff-P]

Hi gdecker,

It sounds like what you experienced is a different behavior to the rest of this thread - your VI is getting corrupted (which is why restarting does not fix the problem). This behavior is not very common, and we generally recommend using version control and backups for medium to large sized projects.

Regards,

[gdecker]

That's fine, and I agree.

However, this VI got corrupted on the first save ever performed on it, so version control wouldn't have helped me.  Fortunately, it's a small, uncomplicated VI.  If it weren't, I'd be in bigger trouble.

Any thoughts on how to reclaim a corrupted file?

[Jolyon]

I have the same problem.  I've been working on a very simple vi, stored on the network server.  One night I shut down my PC, properly.  The next day I get "Unable to display the front panel of the VI. The VI's front panel may have been removed."

Thankfully its a simple vi and I can re-write the thing, but if there is "Click here to fix your file" magic button then please let me know about it!

Thanks!

Jolyon

[DDayD]

I have been getting this problem for a while now. It is very frustrating and seems to be a major bug (more than merely a bug) that NI has not addressed. Sometimes it happens when I make changes to the terminal pattern for the connections to a sub-vi. I thought that maybe LabView is unable to reconcile changes to a sub-vi in areas where instances of the sub-vi are being used. But the last time it happened, I lost a large vi for no apparent reason. I closed the vi, and when I tried to open it again, this error message popped up. I lost the work since my last backup, which was a day or 2 of work.

Not only does the software fail, but it corrupts my work. This is completely unacceptable for a software package as expensive as LabView. I have a hard time believing that R&D can't reproduce the issue, since it's happened to me 4 or 5 times just in the course of a couple of months of making relatively simple VIs.

If anybody can offer me some help with the issue, it would be much appreciated. I can't post the corrupted VI publicly, but I can send it by email to someone who works for NI.

Software:

LabView 2011 (11.0) 32 bit

using Control Design and Simulation Module components

Windows 7 64 bit

[billko]

---

@DDayD wrote:

I have been getting this problem for a while now. It is very frustrating and seems to be a major bug (more than merely a bug) that NI has not addressed. Sometimes it happens when I make changes to the terminal pattern for the connections to a sub-vi. I thought that maybe LabView is unable to reconcile changes to a sub-vi in areas where instances of the sub-vi are being used. But the last time it happened, I lost a large vi for no apparent reason. I closed the vi, and when I tried to open it again, this error message popped up. I lost the work since my last backup, which was a day or 2 of work.

Not only does the software fail, but it corrupts my work. This is completely unacceptable for a software package as expensive as LabView. I have a hard time believing that R&D can't reproduce the issue, since it's happened to me 4 or 5 times just in the course of a couple of months of making relatively simple VIs.

If anybody can offer me some help with the issue, it would be much appreciated. I can't post the corrupted VI publicly, but I can send it by email to someone who works for NI.

Software:

LabView 2011 (11.0) 32 bit

using Control Design and Simulation Module components

Windows 7 64 bit

---

Okay, and how many developers in your shop have the same issue?  How many similar posts do you read here (where this is a consistent problem)?  Now why is it so hard to believe that R&D cannot reproduce your problem?

[jcarmody]

---

@DDayD wrote:

[...] I lost the work since my last backup, which was a day or 2 of work.

[...]

If anybody can offer me some help with the issue

---

http://subversion.apache.org/

http://git-scm.com/

I won't argue whether LabVIEW damaged/lost your file, but backing up is your responsibility.  A "day or 2 of work" should never be lost.  An hour or two?  That's even too much.

[Dennis_Knutson]

I would also suggest you try the current version of LabVIEW to see if the problem still exists. I'm guessing you don't have a current service contract since you have not contacted NI directly and sent them a VI but you can download 2013 and run it in evaluation mode.

[kevin.key]

jcar: If an hour or two is too much to lose, you could easily have a complex VI open for an hour or two, get it working, save, and commit to svn. Only to find out that that hour or two was corrupted. If LabView was my project, I wouldn't consider telling the user to make sure they backup their work more regularly an acceptable response to the problem.

billko: That sounds like a pretty low standard. Just the because the problem occurs infrequently shouldn't mean it's impossible to fix. I haven't obviously tried to fix this problem myself, but I have fixed problems that are difficult to reproduce. Usually it means studying the code for weaknesses, and manipulating things to make the problem more frequent until it can be understood. It also doesn't seem like an acceptable response to say, we can't reproduce it, so we can't fix it, but just try the latest version and maybe the problem is gone.

[Intaris]

---

 It also doesn't seem like an acceptable response to say, we can't reproduce it, so we can't fix it, but just try the latest version and maybe the problem is gone.

---

How do you fix a problem you can't reproduce?

How do know what to analyse and debug if you can't observe directly what is going wrong......?

[kevin.key]

I challenge the idea that it can't be reproduced.