LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Screen Lock up

Well, I didn't see anything wrong in those pictures.
I will ask again, just to be sure - when you say the code runs fine, do you mean the the loop with the event structure continues to iterate (the timeout event continues to execute)? Can you open a new VI in this situation and work on it? If this is so, I don't see how the problem could be with your specs.
Other than your explanation (which I hope is incorrect), the only thing I can think of is that somehow your code is locking the FP, but since you say this only happens occasionally, I doubt this will be possible to hunt down with a working version of the VI available.

Also, please, don't use BMPs, use PNG, GIF or JPG instead. They would have served just as well and would have been much much lighter.

___________________
Try to take over the world!
0 Kudos
Message 11 of 25
(1,408 Views)
Sorry tst for the bmp files. You are right I forgot to convert them to jpg. Any ways yes the code continues to execute the loop; the timeout on the events do occur and you can pause the execution in block diagram, continue executing, set probes, or high light the execution. Everything is fine in the block diagram it is just that I lose all the view events that are supposed to be built in to LabVIEW. I can't click on anything. It is as if there is a Glass Pane blocking the screen.

Message Edited by Nariman on 05-04-2005 03:44 PM

0 Kudos
Message 12 of 25
(1,400 Views)
It does sound weird.
The only thing I can think of is that you cut it down as much as possible and post it.
If it is a bug, that's the only way that it can be recognized by other people.

___________________
Try to take over the world!
0 Kudos
Message 13 of 25
(1,390 Views)
I have had a similar experience towards tab controls. The problem I was having was that I had properties being set for a 2D graph onto a page of a tab control. If I would run the program and am currently viewing the page (of the tab) that the 2D graph is displayed... no problems. Once I switch to another page tab, I and attempted to run the exact same simulation I would receive an error. The odd part is that the error occured only some of the times. The way I resolved the problem was creating a case statement so that the property will only be set whenever the page tab with the 2D graph is viewed. It seemed to have fixed the problem. I'm not sure if this relates to your problem but maybe it'll help, I just thought I'd let you know. Below is the link to the thread I posted about this:

http://forums.ni.com/ni/board/message?board.id=170&message.id=119433&query.id=25906#M119433
0 Kudos
Message 14 of 25
(1,383 Views)
Okay guys I found the problem and fixed it. I don't know if we can call it a LabVIEW bug or wrong programming style. But if I was one of the developers working on LabVIEW 8 I would look in to this further. Here is the situation:

The way I had the program structured was with multiple event structures. If the current tab page was the Criteria tab then the State which had the event structure for that particular tab would be active from my state machine, and all the other event structures (example the event structure for the extract tab page), would not be checked. Because of the slow machine I was using it seemed that when I switched tabs these multiple events somehow overlapped and created a race condition which leads to the screen lock up. Although technically speaking this should not occur in a state machine like the one I had and I still don't know why this happens (maybe I don't know enough about LabVIEW event structures), this was the case. The speed of the machine mattered since when I was doing measurement in the background the probability of lock up increased by a lot. Any ways the way I resolved this problem was by creating one huge event structure instead of couple of small ones that are active when needed and the problem went away beautifully.

Lesson learned: if you are using LabVIEW 7.1 and have multiple events structures for each tab in one VI combine them into one big event structure since even if you are running your application on a fast machine there is a chance that the CPU might get tide up and you get the same lockup that I got. (maybe people knew this before but I learned it the hard way.)

Thanks to all the people who replied and I hope NI Guys will look into this in the future and make the event structures more robust.

Nariman

Message Edited by Nariman on 05-11-2005 01:58 PM

Message Edited by Nariman on 05-11-2005 01:59 PM

0 Kudos
Message 15 of 25
(1,366 Views)
Realiving an old thread...

I ran into a similar problem, with similar conditions (LV 7.1, modest machine). I'm using two event structures in two different subVIs, the second event structure only runs after that the first one is closed. However, the front panel got locked up. The solution I found was to place an "Unregister for events.vi" connected to the Dynamic Event Terminal at the end of the first Event Structure. Now it works fine. Smiley Happy

Rasputin
LV7.1 <> W2K
0 Kudos
Message 16 of 25
(1,177 Views)
Rasputin:

Thank you very  much for sharing the solution to your problem.

Regards,

Rudi N.
0 Kudos
Message 17 of 25
(1,155 Views)
Rasputin:

Thank you very  much for sharing the solution to your problem.

Regards,

Rudi N.
0 Kudos
Message 18 of 25
(1,156 Views)
Not to be a pain or anything, but I seem to be having a similar problem with LV 8.0.  It is a simple communications application, in principle.  I have a System tab control on my FP.  The first tab has the communications setup controls, port numbers, IP addresses, "connect" buttons, etc.  The next three tabs contain the data that gets transmitted and received.  When the VI starts, I have it programmatically jump to the first tab, so people know that's where to start.  Then the VI runs a loop in a 5-Hz period where it waits for the user to press connect.  Then the rest of the program is off and running.  The problem is that if the user wants to initialize some data on the next three tabs to something other than the defaults before he connects, he switches to the tab and makes the changes.  If he does this, then the entire screen locks up.  Nothing can be updated on the screeen.  I have to press the abort button and start over.
 
I'm not using event structures or anything weird.  I can pause the execution and highlight and trace and do everything that I would normally be able to do...but the front panel is completely frozen the instant I change the value of any control on any OTHER tab than the COMMS SETUP tab.  My customer has noticed this in the version built using application builder as well.
 
Please help!
Thanks,
Dan Marlow
 
Download All
0 Kudos
Message 19 of 25
(1,083 Views)

Hi Dan,

Would it be possible for you to attach a sample VI that does the same thing?  I have taken a look at your code, and do not see anything that jumps out at me. 

If you could use your code, delete the unnecessary portions of it, and attach that, I would be more than happy to take a look at it.

Please let me know if you have any further questions.  Best of luck on your application, and have a great day!!

Regards,
Ching P.
DAQ and Academic Hardware R&D
National Instruments
0 Kudos
Message 20 of 25
(1,049 Views)