Front panel locked up?

I'm using the System Control UI Suite 2.0 and trying to work with graphs on my VI. Frequently my front panel appears to "lock up". I'm apparently able to move around the front panel, however the front panel graphics themselves do not change location. If I hit "ctrl-A" to select all front control objects, the marquees themselves appear where the control 'should' be. If I close the VI and reopen it, the controls appear where I moved them previously. It's as if the front panel image itself is not updating properly.
This does not appear with other VIs. I can get around it by deleting the graphs, saving the VI, renaming the VI, and reopening it. For whatever reason this sequence restores it. Once I add the graphs and attempt to populate them with data in run time, my front panel locks up again.

Hi Synaesthete,
I am curious, do you see the same behavior when using only the stock LabVIEW controls? Have you tried replacing the UI Control Suite System Controls with the stock LabVIEW controls and seeing if the behavior still exists?
Also, do the controls only lock-up when in edit mode or do the controls become unresponsive while executing the VI as well?
Milan

Similar Messages

Front panel locks with event structure loop and another while loop

Hi,
Why is the front panel locking after changing the value of the "boolean switch" twice? This problem disappears if I uncheck the "lock front panel" option in the event case. However I don't understand why that is the case since the event structure loop has already finished executing.
thanks

Do you really want the event handling to stop after detecting the first event? If so then as Christian says the event structure will cause the front panel to lock. What you can do is dynamically register and unregister the events. You right click on the event structure and enable "Show Dynamic Event Terminals" Then you can programatically register and unregister events.
Here is your vi modified to do that.
Edit: Just in case - right click on the control and create a reference. When selecting the source of the event in the structure look under the dynamic section.
=====================
LabVIEW 2012
Attachments:
event structure test.vi ‏13 KB

Event structure front panel lock

hi, I have a mouse down event for pushbutton on the front panel to trigger an event. The event structure is under a while loop. However, I checked 'lock FP during the process' but the pushbutton actually registers the mouse click. i.e. once i click the pushbutton during the event(which is supposed to be locked), the event will be triggered again automatically after the current round.
Does anyone know how to fully lock the button? I even add in property node to disable the button in the beginning of the event case but it doesn't work as well.
Thanks a lot.
Cheers,
SSR

Hi,
The option is to 'Lock the front panel until the event case for this event completes'. If you have this checked, then all other controls are locked until the event triggered by the mousedown completes. It does not prevent the event from registering in the first place. The mousedown will still register and it's event code will execute regardless if this checkbox setting (unless another event is being processed at the time).
Mousedown also registers if you disable the control either programatically or via the menus - you need to change the event to 'Value Change' instead of Mouse Down. If you do this and programatically alter the enabled stated of the control, you can control whether the event is processed or not.
HTH
Steven
edit: stevem181 beat me to it and in fewer words too
Message Edited by Steven_G on 11-02-2009 10:33 AM

Front panel locks up

When this vi nears completion it reaches this part of the code and waits for a final comment and for the user to close panel so the iv will finish and close. About 50% of the time it works. When it doesn't the VI is totally locked up and I have to abort out. What would cause this FP to lock up and refuse input?
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell
Solved!
Go to Solution.
Attachments:
overview lockup problem.png ‏18 KB

Not sure how this can happen, but one debugging technique is to add an indicator to the loop counter. (and add a +1 between the 'i' and the indicate to see it's started the first run.
It might be that some of the inputs are not ready! (I heavily suspect the numeric array!)
You can try this by placing a breakpoint on every incoming wire, you should all the breakpoints before your freeze.
Another point to try is to set the timeout of the read queue to 100 ms, and remove the OpenG wait function.
That prevents you from loosing messages! When there are more than 1 message per 100 ms. you might loose messages.
For instance:
T=0 ms : start loop
T=0 ms: Read Queue finishes
T=10 ms: Add message 1
T=30 ms: Add message 2
T=100 ms: Iteration 0 finishes
T=100 ms: Read queue finishes and returns message 1
T=120 ms: Add message 3
T=130 ms: Stop pushes
T=150 ms: Iteration 1 finishes
T=150 ms: Read queue finishes and returns message 2
T=200 ms: OpenG wait ends, Iteration 2 finishes, and terminates loop
So your queue has 1 message in backlog, and you had an additional 70 ms wait after the push of the stop button. (this varies between 50 and 100 ms.)
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

Unexpected effect of Lock Front Panel in Event Structure

I have been using LV intensely for only a short time, although I have dabbled with it many times since its first appearance. The "problem" that I have had may well be the intended behaviour, but it just seems unintuitive to me. I'm writing a small application to take measurements from a USB instrument. I have already written a basic driver for the instrument, which the application calls, and the driver is working as expected. In the application, the user can configure various settings and then click an Execute button to transfer them to the instrument. The click event is handled in an event structure along with other events. Since some of the instrument operations take an appreciable time, the first action that occurs in the click event case is to disable the Execute button using a property node so that further clicks are ignored until the operation completes, at which time the button is re-enabled.
When disabled, the Execute button is grayed out as expected and clicking it has no visual effect. However, it seems that clicks made during the disabled period are still queued and acted upon when the button is re-enabled, causing the operation to be repeated.
It is the solution I have found that seems unintuitive to me. The Lock Front Panel check box was checked (by default) for the click event, and I assumed that this would be the correct setting. However, unchecking the Lock check box actually makes everything worked as expected. Click events occurring during the disabled period are now ignored or discarded. I'm not suggesting that this is a bug, but I'm interested to learn why it happens, if anyone can explain. I have attached a picture of a simplified version of the event case.
Attachments:
Sample.png ‏7 KB

I would say what you see is expected behavior, even though it's a bit complicated.
The "Lock front panel until the event case for this event completes" option will only defer clicks and other things generating events until the current event handler completes. So this means that the click is placed in a queue and only evaluated once the event is finished. At this time, the button is no longer disabled, so an event is generated.
When the "Lock front panel until the event case for this event completes" is not checked, the click is immediately evaluated, but it's happening on a disabled control, so it does not generate an event.
From the LV help:
By default, when an event enters a queue, LabVIEW locks the front panel that contains the object that generated that event. LabVIEW keeps the front panel locked until all Event structures finish handling the event. While the front panel is locked, LabVIEW does not process front panel activity but places those interactions in a buffer and handles them when the front panel is unlocked.
Note If an event case that locks the front panel takes a significant amount of time to execute, consider using the Set Busy function or displaying a dialog box to notify the user that the front panel is locked.

Front panel of SubVI locks on 2nd call

HI!
I'm calling a SubVI and pass a Boolean Reference to this SubVI. In the SubVI I'm executing a While loop. The stop condition is the value of the boolean control in the VI that calls the SubVI. (Boolean Refnum + Property Node: VALUE connected to while stop condition)
Mechanical Action of the Boolean in the calling VI is: Switch when pressed.
For the first time this will be executed it works fine. But the 2nd time the SubVI is called. The Front Panel of the calling VI where the stop button is located will be locked.
Does anybody have an idea why this happens and how I can solve that problem?
ANDY

I tried what you described, using LV 7.1, and I have no problems running the vi over and over again. See the attached examples. Ref1.vi calls Ref2.vi and passes the Boolean reference to it.
- tbob
Inventor of the WORM Global
Attachments:
Ref.zip ‏21 KB

VI locks up when front panel is displayed

Hi
Firstly, I apologise if I’ve sent this to the wrong forum – I’m not sure if this is a TestStand or Labview related issue or possibly both.
I have a test procedure developed using Labview 7.1 and TestStand 3.1. It’s run from TestStand’s Operator Interface VI (full version), and executes about a dozen TestStand sequences in turn which call lower level VIs that perform the actual tests.
The code was written on a Dell GX240 Pentium 4 PC, with Windows 2000 + SP4 installed and runs without a hitch. However, I also have a second PC, same model & spec, but running Windows XP + SP3 instead of Win2K. I’ve also installed the same versions of Labview & TestStand on it, and copied across all my TestStand sequences & VIs into the same working directory. However, when I run the program on this machine, again using the same Operator Interface, it executes until about half way through and then hangs up.
In several tests, I call up a graphical user interface VI which displays a picture and prompts the operator to click on either a ‘Pass’ or ‘Fail’ button – the actual text being passed as a parameter. When the lock up occurs, the front panel is displayed, but there’s no picture and the buttons are blank. Up to that point, previous calls to the VI have executed ok.
If I modify the step that causes the problem, to call another VI - for example, a sub VI that doesn’t display a front panel - the new VI executes and the program continues to run. If I then change this VI’s configuration so that it’s front panel is displayed at run time, the problem re-occurs - the front panel outline appears but everything then freezes.
Attempting to close the front panel window, results in either error code –18001 and the message ‘an error occurred accessing the Labview ActiveX automation server’ being displayed or the Windows prompt to close Labview as it’s not responding. Usually, clicking ‘End Program’ causes the PC to crash out & re-boot.
Skipping TestStand sequences, whether they execute the GUI VI or not, just moves the point where the lock up occurs further down the list of tests, to the next step where the GUI VI is called. It’s almost as if something isn’t being closed properly when the program runs, and eventually reaches some limit, but why this doesn’t appear to effect the Windows 2000 PC, I’m at a loss.
Very much appreciate anyone’s thoughts.
Thanks
Bruce

Hi Bruce,
I found a KnowledgeBase article relating to the error you are seeing.
It describes error 18001 "Error occurred accessing LV activeX automation server".
Let me know if this helps you out.
This problem may also be due to how you have configured the Distributed COM (DCOM) settings on your machine. You will need to ensure that your DCOM settings allows the LabVIEW ActiveX Server to be launched and accessed through ActiveX automation. Even Administrator accounts can be denied launch and access permissions. To modify these permissions follow the steps below for Windows XP:
Login to Windows using a UserID that has administrator privileges.
Select Start»Run and enter dcomcnfg.exe. This displays the Component Services dialog window.
Navigate to Component Services»Computers»My Computer and select DCOM Config. Ignore the warnings that may appear.
Right-click on LabVIEW Application, TestStandLVRTS or the name of your LabVIEW ActiveX Server and select Properties to open the LabVIEW Application Properties dialog window. Select the Security tab.
You must give permission to the appropriate users so that they can access the LabVIEW server. You should give everyone access permissions and appropriate users launch permission. Only users who have launch permission will be able to access the server. Add permissions by selecting Customize and Edit for each of the three permission settings and manually adding permissions for each user.
I doubled checked that LabVIEW 7.1 and 3.1 are compatible with windows XP and they are. Just to make sure, it is 32bit or 64bit you are using?
Let me know how you get on.
Kind Regards
Lewis Gear CLD
Check out my LabVIEW UAV

How to lock a pane within front panel

Hello,
i am trying to lock a single specific pane of my front panel while handling an event.
or the inverse
in the event structure, one can lock the front panel while performing the event. i would like this to happen, in order to avoid queuing other user events in the mean time.
except for some commands, which i all put in a single pane (like a taskbar), and which includes important features that should be accessed at all time.
however i could not find any property of the pane or the front panel that allows me to do so.
any idea?
... And here's where I keep assorted lengths of wires...

Thanks Partha,
i have looked at this thread before, did not think it related too much.
if i want to set busy, i still cant use the pane 1 of my front panel. or, the inverse, if i set controls to "disable" i would have to do it for all the controls in the pane 2, for every event that is fired. anyway it is reported there to not work as desired.
i think we might have here a suggestion for improvement:
i could not find anywhere except in the options for specific event, the option to lock the front panel. to my taste this should be an avaible property node. then, this option would also automatically exist for every pane in the front panel.
what do you think?
in the mean time, i still need a workaround. an idea i had, but makes my code more complicated, is to implement an external vi that would be always on top, and would be as the pane 1 in my curent vi. i would not like to do this actually...
... And here's where I keep assorted lengths of wires...

How to lock the size of front panel so that user can't see hidden objects?

Dennis_Knutson wrote:
You don't care that the code itself can be changed?
For that you can lock the VI with a password

2014spring wrote:
Sam,
I'm also considering your advice to redesign it...That's a little pain though.
Regards,
spring.
Hmmm, Thats a really good idea! a key thought for you:
Protect the user from himself! your exe should NEVER display the Front Panel of a non-running vi. That data can't be updated or renewed - it contains no information the user could possibly be interested in. Really, that's the mindset you need while refactoring the app! Some other RUNNING utility may need to display information simillar to that shown on the vi FP in question but "Dead Data" is about the worst thing you can give to a user. (I've had simillar "Face-Palm" moments - don't feel too bad)

Disable/Lock Front Panel Programmatically

Hello
I have a huge project with a bunch of boolean controls. Each boolean triggers an event. So when an event is triggered, I disable all other booleans to avoid any event lock up.
There are cases where I have to disable ALL the boolean, for ex. when saving, I disable all controls till a report is generated. Is there anyway I can lock or disable the front panel programmatically rather than use property nodes to disable them ? I am losing a lot of my real estate and VI becomes really huge (1.41 MB so far, just the top level )
Thanks !!
Kudos always welcome for helpful posts

Maximus00, like you, I have a huge VI (complex UI with controls/indicators), It is now 2.5 MB in LabView 8.20 (in 6.1, it is about 5mb). I'm looking for the same thing, that is how to disable the Event Structure "locking front panel". Currently, I disable all 50 events for this feature, but this is cumbersome, tedious, and should be a better way. I came across your post and wish LV had a way to programattically disable it, via a property node. The VI I am working is large, and will most likely be used be maintained by multiple developers so it is critical that there is some way to inhibit the "locking front panel", anytime they add or edit an event. It is definitely NOT a good thing to have the VI lock up! By Programmatically disabling all of the event structure's locking front panel, this would protect the VI code from locking up, if a new developer is unfamiliar with the code.
If anyone knows a way to Disable/Lock Front Panel Programmatically let us know!!
-crazycliffy
- crazycliffy

Lock front panel until the event case for this event completes

A Dynamic Event is a filtered event? Is this why "Lock front panel until the event case for this event completes" is not shown on Edit Event window dialog? I use Dynamic Event so I can subvi the event structure.
I need stop my app from locking the FP whenever the user double clicks on the numerical array value (<-- the FP freezes the mouse and renders it useless) and stops the value from ever being changed. This event is registered for Value Change (not mouse up or down) and I get a locked mouse. As yet in the UI, no value changed occurs but I get a locked mouse. A LV bug?
Trying to KISS, I can see this fixing this by moving ONLY the value change event to the top level VI instead of a dynamic registered event in a subVI. This will give me the option to NOT "Lock front panel until the event case for this event completes" .
Solved!
Go to Solution.

richjoh wrote:
Thx, Ben that fixed the problem when I unchecked "Lock panel...".
So it appears LV locks the panel during runtime once the Dynamic Reg Events is on BD and it doesn't matter if your case to handle the Reg Events is created or NOT... interesting. That's why my mouse persisted to "freeze up" although I deleted the case for my FP array.
Its situation like what you described that has given me many insights into how LV actually works. In one of my bbuggy VI's I found that a class wire can run a million miles through multiple sub-VI queues etc but the data itself is only touched when it has to be touched. in my case it was a crash while trying to write bogus class dat to a TDMS file.
I am glad you are back on course.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

How to lock block diagram alone from editing leaving front panel for editing?

i want to lock block diagram from editing but front panel can be edited for creating controls, moving controls editing properties...

executables will be delivered to customer and they can create new vi and edit frontpanel and link tag through databinding. but i dont want them to open block diagram...
Natasftw is right - you seem confused about the difference.
If the customer can "create a new VI and edit frontpanel" then they have to have LabVIEW Development System.
If you give them an EXE, and they don't have the DevSys, then they can use your VIs, but not edit them or look at the code.
If they have the DevSys, then they can edit your VI and look at the code, UNLESS you protect it.
If you save a VI with protection (VI PROPERTIES - PROTECTION ) then you can LOCK it (user has to explicitly unlock it with an extra step), or you can PASSWORD PROTECT it (user has to explicitly unlock it by giving a password). Either way requires the DevSys.
There is no situtation where one can edit the front panel without being able to edit the block diagram.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Pressing on the Table Control locks the front panel in a certain state

Hello everyone!
I have following problem. I have a very simple state machine with two cases. In the Idle case there is an event structure receiving input from a Table Control. When pressing Run the Vi enters the Run state. To exit the RUn state I have a Finish button, but IF I during the running state press anything on the Table Control the entire front panel will lock. Disabling the Table Control in the running state doesn´t help in the same way it helped for Button 1 and 2. Any help would be appreciated. I have tried unsuccesfully with the Registering and Unregistering event functions.
Attached is a simplified version of the problem. Thanks in advance.
Solved!
Go to Solution.
Attachments:
Event lock problem.vi ‏22 KB

Hi, RealBjörkis !
I ran your VI and I saw a few problems, try to keep your controls outside the events structure, also do what said P@Anand previously.
Here is your VI with some corrections. (Hope it fix the problem)
Good Luck.
Attachments:
Event lock problem.vi ‏23 KB

Lock front panel with has titel bar?

How can I lock a front panel that has a title bar?
I do not want that the user
- close the window --> ok, vi-property
- resize the Window --> ok, vi-property
- minimize the window --> ok, vi-property
but:
I also want, that the user can't move the window using the titel bar
I do not want to poll permanently the windows-position.
Any idea?

Hello zav,
via vi->property node you can also set the window size. So switch of
closing/resizing/minimizing in the vi properties dialog and do the rest
in a small while loop parallel to your main program (permanently set
the window size to the size of the screen).
Attached is a picture of a sub-vi calculating the window position
regarding to screen size. The output is wired to a property node
'Frontpanel Window.Window Bounds'. Hope this helps...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Attachments:
WindowSize.png ‏4 KB

While loop with stop button within event structure locks up front panel.

I am not sure if this is a bug with my program or a bug within LabVIEW. If you believe that this is a bug with my program then I will post my program to be looked at.
The problem I am having is there is a while loop within an event structure that fires when a particular value changes. Once the "Activate" button is pressed the while loop within the event structure starts going with a polling frequency of 1hz (1000ms wired to the "wait till next ms multiple" vi). There is a "Deactivate" button that is wired to the stop control of the while loop and an outter while loop that resets the event structure so that the activate button is being listened to again.
Once inside the while loop, however, none of the button are responsive within the front panel. The VI continues to run, and only 60% of my CPU is being consumed, but none of the button or scroll bars work. The only way for me to terminate the program is with the "Abort" button next to the "Run" button. If I remove the event structure so that the while loop in question runs as soon as the program starts, the front panel remains responsive. I've inserted probes within the while loop and verified that it is not running prior to the "Activate" button being asserted, and it is running after the assertion of the "Activate" button with the expected polling frequency set by the "wait till next ms multiple" vi.
Can anyone help? Do I need to post my code?
-Nic

It is typically not a good idea to stall an event structure by placing loops inside event cases. What good is an event structure if it is not free to repond to events?
Have a look at some alternative solutions, such as in the following link:
http://forums.ni.com/ni/board/message?board.id=170&message.id=224817#M224817
LabVIEW Champion . Do more with less code and in less time .

Front panel locked up?

Similar Messages

Maybe you are looking for