Unable to display the front panel of the VI

[JackDunaway]

@Tanya V: Inconveniently, my Vista work computer went totally kaput yesterday, but conveniently I got a new Win 7 distribution installed today. I am in the process of reinstalling LabVIEW 2009 SP1 as we speak. I'll keep my eyes peeled for this error again, but since my entire system has fundamentally changed, the bug could be gone. If I see it happening again, I'll be glad to spend a little time chasing down the problem, but unless I see the bug again, back to work as usual.

Thanks,

Jack

[Tanya_V]

Hi Jack and gsussman,

I submitted a corrective action request (#234040) to R&D, so they have been made aware of this behavior. Any code that you could post that intermittently exhibits this error would help R&D reproduce this error. Thanks for bringing this to our attention.

Take care!

[dhedges]

I have a theory.  I suspect you are all hitting an error during the load of a front panel that only occurs if the VI's code was already loaded.  If my theory is correct, then your VIs are not corrupted -- if they were, LabVIEW would not have been able to load them the first time, or compile them, and a restart would not fix the problem.

LabVIEW will sometimes load your VI but not the panel, such as when loading a subVI or any member of an LVOOP class.  Also, sometimes LabVIEW will load the VI when you want to see it, and when you close it, it will throw it out of memory again.  You can run the VI without the panel in memory.  Sometimes, running the VI makes changes to internal data structures.  My theory is that a bug happened during the run, that caused the internal data structures to be inconsistent with the front panel (which is on disk, and not in memory).  Then, later, you may want to open the front panel, and you hit this error during the load.

If my theory is correct, then a workaround would be to tell LabVIEW that you always want the panel in memory even if it's loading as a subVI.  Now, there is a potentially serious performance penalty here: not just the memory of the extra panel, but also the extra copies of the operate data for all your controls and indicators, and the time it takes switching threads to keep that data consistent.  But maybe you can handle this; I can't say because I know nothing of your application.

If you can try my workaround, and if it doesn't work, then you disprove my theory.  Here's the workaround:

1. Make a backup copy, for the love of all that's holy.  Please don't skip this step.
2. Somewhere on your block diagram, drop a read property node for the value of one of your front panel controls.  It doesn't matter if the node is ever executed -- just having it on the diagram tells LabVIEW to keep the panel in memory.
3. Do your thing for a couple of weeks and see if the problem still happens.

If the workaround is successful, we still don't know what the bug is.  I need to figure out what the mismatch is, and what (presumably during a run) could have caused it.  But this might give us clues while we look for a way to reliably reproduce it.

[lounatic]

I'm seeing this exact same problem at least twice a day. This causes an error when deploying to a real-time target like a cRIO controller.

Dave

Message Edited by lounatic on 06-11-2010 04:18 PM

[RD Mercer]

I am seeing the exact same thing...and it happens at least once a day.  It causes a deployment error when it try's to deploy the random, messed up, VI to the target and it's really annoying.  You have to close LV down and re-launch.  It is almost as annoying as opening up my project and every single bit of text is unicoded and you have to shut down and re-launch several times before it corrects itself.

I bet it happens more frequently with larger projects as we have over 500 VI's in our project and like 1000 project items.

[charris]

Have you been able to test DHedges' workaround? It's the best suggestion thus far, and unfortunately, there's not much I can do to test this without a project to replicate the issue with.

[JackDunaway]

@dhedges: PN's won't be valid for my RT target (this problem has affected VI's on both Windows HMI and RT side). Also, since I've got hundreds of VI's, it would not be economical for me to troubleshoot this problem further (others who have commented here may be willing to pursue the problem further since the problem is a bigger problem).

Unfortunately, last week my computer went kaput, so I'm working on a fresh install of Windows 7 and LabVIEW 2009 SP1. Since then, I have not seen this bug, but I will report back if I see it again, or if the frequency becomes more often like the others.

[gsussman]

Testing this theory would be a huge task on my project. The problematic VI is not the same every time, therefore it would require one of these property nodes in every single one of my 2800+ VIs.

Putting all of this code in to test the theory only to have to rip it all out afterwards in order to deploy the project is not feasable time or cost wise.

Another peice of food for thought. I am not sure how the internal panel loading mechanism works within LabVIEW, but I would think that if the issue was with the internal data structures for a particular VI, wouldn't closing all projects...all the way back to the LabVIEW Getting Started window, unload all of the VIs from memory and reset their internal data structures?

[Will_E]

I am also experiencing this problem  First time I open a sub-VI, it opens just fine.  Next time, I get no response.  Large project, multiple VI’s and such.  I try and click on the VI to open it, nothing happens.  So, I go to the Project Explorer and try and open it, I get the “Unable to Display the Front Panel of the VI.” error message.  Now, I just closed down my project, re-open the project and now the file will load again.  It has opened several times on this occurrence.  Annoying problem that is intermittent

[dhedges]

---

gsussman wrote:

The problematic VI is not the same every time, therefore it would require one of these property nodes in every single one of my 2800+ VIs.

---

It might not be the same VI every time, but I suspect it's not all VIs.  Can you keep a list every time this happens, and see if a pattern emerges?  It could be the problem only happens on one out of a small set.  From there, we could try and figure out what the small set has in common.

---

gsussman wrote: 

I am not sure how the internal panel loading mechanism works within LabVIEW, but I would think that if the issue was with the internal data structures for a particular VI, wouldn't closing all projects...all the way back to the LabVIEW Getting Started window, unload all of the VIs from memory and reset their internal data structures?

---

Yes, it should.  It's possible that you could get all the way back to the GSW and LabVIEW still hasn't thrown out your VI.  That would be a bug, but it's possible.  Perhaps, after you hit this problem, you could close everything, get to the GSW, then create a new VI, drop a property node to get all VIs in memory and see if the problem VI is listed.  It would at least be interesting to know.