Minimise front panel of vi containing timed loop = problem

Is this expected behaviour...
Run the attached VI.
All it is supposed to do is beep every 10 cycles.
When you minimise it and try to restore the front panel though... it locks up for a random amount of time.
I don't think it is supposed to do that. (I'm running it on XP Pro.)
Originally I was chasing this problem in a data acquisition loop. The buffer would overflow and exit the app with an error when it was minimised.
It took all day to track it down to this.
Hmmm... I just tried to save it back to a version 8.0 vi and it doesn't seem to have the same error!
Message Edited by Troy K on 10-03-2008 05:26 PM
Message Edited by Troy K on 10-03-2008 05:31 PM
Troy
CLDEach snowflake in an avalanche pleads not guilty. - Stanislaw J. Lec
I haven't failed, I've found 10,000 ways that don't work - Thomas Edison
Beware of the man who won't be bothered with details. - William Feather
The greatest of faults is to be conscious of none. - Thomas Carlyle
Attachments:
Timed Loop minimised.vi ‏85 KB
minimisetimedloop.png ‏7 KB

I'm using LabVIEW 8.5.1 on two PCs and it does it on both of them.
I just emailed the vi to a colleague and after a few minimise/maximises it locked up on him too.
I've just found that if I remove the left and right data nodes inside the timed loop the bug seems to go away.
Steps to repeat bug:
1. Minimise all windows (Windows+m)
2. Restore vi front panel and run it. (It should start beeping twice a second)
3. Minimise / Restore it rapidly by repeatedly clicking on the vi's Front Panel 'task bar button' (down the bottom).
After a while the beeping will stop when the front panel is minimised and it wont restore. Then after a while (with or without clicking on the task bar button) the front panel will restore and the missed periods will execute very quickly (as the timed loop does what it is configured to do).
I think because of the simplicity of the example vi the bug doesn't show up as often. When I ran it in the real application (too many vi's to post) it crashed every time. In the real application there isn't much going on in the timed loop, it is just used to queue items into a separate consumer loop. The problem is that when the bug occurs, ALL LABVIEW CODE stops executing, not just the code inside the timed loop. So another vi running in parallel (in a daemon) that retrieves messages from a device queue stops and the device buffer overflows.
Attached is a modified vi to demonstrate that code outside the timed loop stops executing too. The bug occurs here on three different PCs, the only common thing I can think of is LabVIEW 8.5.1.
Troy
CLDEach snowflake in an avalanche pleads not guilty. - Stanislaw J. Lec
I haven't failed, I've found 10,000 ways that don't work - Thomas Edison
Beware of the man who won't be bothered with details. - William Feather
The greatest of faults is to be conscious of none. - Thomas Carlyle
Attachments:
Timed Loop minimised 2.vi ‏89 KB

Similar Messages

How can I save front panel images each time a loop iterates

So I've been working on some optical codes in LabVIEW for a while, I've read a lot of these similar questions but I can't seem to apply them directly to my situation in all cases.
I essentially have a code that shows an intensity graph that is continually modified in a for loop, I want to save a picture of that intensity graph each loop without having to manually label them. Is there something similar to the get image node that can do this. I've looked through the image acquisition in the vision VIs but only see references to hardware like cameras.
Attached is a simplified version of a changing intensity graph. With the get image I have to establish the names of 10 images and the path there before it will run and save like I want it to.
A million thanks to anyone who can help
Solved!
Go to Solution.
Attachments:
Sample image save.vi ‏19 KB

That worked wonderfully and is exactly what I need for the phase diagrams Im working with. I have a new and similar issue, I do have a camera showing us our laser source in a CCD image within my code. I was hoping to get a picture of that each iteration and hoped the solution you provided would work for both but the CCD jpgs are just black. I'm assuming I may have to use a different acquiring technique with that but dont know the best way to go.
Any help there? I cant really post a VI since the camera stuff wouldnt work but heres a screen shot of the front panel and the CCD image that id like to capture.
Attachments:
2.JPG ‏400 KB

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

Remote Front Panel Problems and Best Practices

All,
Problems
I'm currently attempting to host a Remote Front Panel from a cRIO 9073. The intent of the front panel is to control and configure the services running on the cRIO. Currently I've been experiencing quite a few problems getting this to operate smoothly.
These are the problems I'm currently experiencing.
* Front panel takes a very long time to load (~45 Seconds).
* On close the front panel may reset the cRIO.
* Front panel may cause excessive CPU usage.
* Plugin has problems in Firefox.
I'm fairly sure that I've installed all of the Latest NI software (I'm using LV 2009f2)
I currently cannot post the code as it's proprietary.
Currently the front panel consists of two timed loops one running at 500ms intervals and the other running at 1000ms intervals. The GUI is basically a tab control and on the heaviest tab contains about 15 buttons.
Questions
Is it not possible to use event structures in embedded LabVIEW? So far I've had to code my own event loop to handle all the events I wish to process on the remote front panel, and I feel this might be causing a problem.
Is the sort of functionality I'm trying to achieve acceptable in Web Front Panels?
It seems that the reason it takes very long for the VIs to load is that the VI Front Panel Server must fire up. Is there a way to make this or whatever the component is that handles it fire ahead of time?
Thanks for your time, I look forward to discussing this.
Regards,
Ken

Hi Ken,
Is this a remote front panel for a real-time VI? Is it built into an executable? If this is a RT VI, you cannot use event structures. More details are available in this KB:
Can I Use the Event Structure in LabVIEW RT?
I assume you have seen this?
How Can I View Remote LabVIEW Real-Time Front Panels in a Web Browser?
Are you still having the cRio reset issue and CPU usage increase?
Kristen H.

Front Panel freezes completely

Hi,
The attachement contains the image of the front panel. The picture shows child vis loaded using subpanel . In this VI i have tab with 5 pages, the pages are controlled using Runt time menu. The picture shown is from the first page of the tab. Now i have a situation we similar child vis are loaded in all pages, it works until fine few minutes, later the front panel freezes compeletly. How to solve this problem?
Attachments:
Front panel.jpg ‏480 KB

Hi jay,
usual problems are
- starving the CPU by heavy load (especially in the UI thread)
- an event structure set to block UI while handling event(s)
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Question about subvi front panel

I want to call a subvi in the main program and do like
this:
1. When the main program calls the subvi, the subvi shows its front
panel and executes.
2. After the subvi finishes, it can close the front panel.
Now, I meet a problem: I can popup the subvi node setup dialog to enable
"show front panel when called", which implements the first one, but I
can not close the front panel until originally closed(main
program stops). How can I close the subvi's front panel(after it
finishes running) even when the main program is still running?
Thanks in advances.
Sent via Deja.com http://www.deja.com/
Before you buy.

In article <[email protected]>,
"Remco Breen" wrote:
>
> [email protected] wrote in message <[email protected]>...
> >In article <[email protected]>,
> >"Kevin B. Kent" wrote:
> >> [email protected] wrote:
> >>
> >> > Now, I meet a problem: I can popup the subvi node setup dialog to
> >enable
> >> > "show front panel when called", which implements the first one,
but
> >I
> >> > can not close the front panel until originally closed(main
> >> > program stops). How can I close the subvi's front panel(after it
> >> > finishes running) even when the main program is still running?
> >
> >
> >
> >
> >> Select the "close front panel if originally closed" option.
> >> in addition to the "Show front panel when called"
> >>
> >> Kevin Kent
> >
> >
> >I have tried this, in this way, the subvi's front panel is closed
only
> >after the main program stops. In fact, what I want is to close the
> >subvi's front panel even the main program is still running.
> >
> >
> >zhljh
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
> Another option would be to open a VI reference (found under
"application
> control") and tie that to a property node and select the property
"front
> panel.open". Change it to a control and attach a boolean false to it
when
> you like to close.
>
> RB.
>
I think a more elegant way of closing the SUB VI is to start off the way
that Remco states regarding opening a VI reference. Only in the Sub VI,
you should program a Terminate control (such as an Abort button to exit
from a While loop... or something similar) and via the VI reference,
select the 'Set Control Value' method to gracefully stop the Sub VI
execution. Of course the Sub VI will have to set the close if originally
closed attrib set.
There is a great source of example LabVIEW apps at:
http://digital.ni.com/explprog.nsf/web%2Fswgrp?OpenView&Start=1&Count=50
0&Expand=3.7#3.7
In particular, see "Stopping a Running SubVI from the Main VI Using VI
Server" example. It demostrates this techniques better than I can
explain it. Hope this help.
Rick
Sent via Deja.com http://www.deja.com/
Before you buy.

Front panel scroll bars are missing

Hi
Can somebady tell me how to get my front panel scroll bars back. Block diagram is showing them but front panel is not. i can probably open another vi and copy and paste my application. Thanks

suni wrote:
Can somebady tell me how to get my front panel scroll bars back. Block diagram is showing them but front panel is not. i can probably open another vi and copy and paste my application. Thanks
What is your LabVIEW version?
All the above responses only apply if your front panel does NOT contain splitter bars. Once you have splitter bars, things get a bit more complicated and you can easily create a situation where the scroll bars are also off in edit mode and the VI properties cannot get them back directly.
What you need to do is right-click in the splitter bar and select e.g. right pane (or whatever) as follows:
Message Edited by altenbach on 09-17-2008 03:56 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
recoverScrollers.png ‏17 KB

RT Remote Front Panel issues.

I'll start with my setup:
2 PXI-1042 chassis connected via fiber-optic using NI PXI-8336 (MXI-4) cards.
Chassis 1: PXI-8108 embedded controller running LabVIEW Real-time OS (2010), PXI-6528 DIO, PXI-8336 MXI-4.
Chassis 2: MXI-4 in slot 1, 4 PXI-8334 DMM, PXI-6528 DIO, PXI-6281 M-series DAQ.
The real-time executable monitors analog and digital inputs and DMM measurements, displays the values using numeric and boolean indicators, generates alarms and allows users to acknowledge alarms via a Remote Front Panel. The code has a custom error handler that traps errors and stores them in a global array. This allows the code to display them on a console and allows the user to acknowledge and clear errors, and scroll through multiple error messages. We used property nodes sparingly.
The system is monitored by two laptops with the correct run-time engine installed (both laptops have the LabVIEW development suite). Under normal conditions, one laptop keeps control of the Remote Front Panel at all times.
The problem:
The system was running flawlessly for 3 months of continuous use. Then, for no apparent reason, the indicators that display measurements from "Chassis 2" (specifically the DAQ) stopped updating.
If the user refreshed the browser, the Remote Front Panel client would reconnect to the RT Web Server and get updated values, but they were always static. Essentially, refreshing the browser took a "snapshot" of the data, but the indicators did not update continuously as before. At the same time, DIO inputs to "Chassis 1" responded appropriately to changes in state.
Refreshing the browser on one laptop would update the values for that laptop only, and the other laptop could be refreshed independently and have different values displayed, but both laptop's indicators were static. During this time, the DMM measured inputs were not changing and the "Chassis 2" DIO inputs did not change state (i.e., we could not perturb the inputs), so we could not determine if those indications were affected.
Also, the error console did not respond to user input until the browser was refreshed and the client reconnected to the target.
We know the RT application is running on the target because there is code that monitors the status of the loops by changing state every loop iteration and displays the status to the user.
Our short-term solution was to reboot the RT controller by powering down both chassis, starting "Chassis 2", then starting "Chassis 1". It's been running for a few days now without incident.
Since the data displayed after refresh was accurate based on comparison to gages in the system, we do not suspect a measurement problem.
Possible culprits:
1. The RT Web Server has malfunctioned in some way (memory problems, synchronization, etc.)
2. The MXI-4 link.
3. Cosmic rays? Sunspots? Nearby radar stations? Neighboring HAM radio operators (with massive amplifiers)?
If anyone has any ideas, they are welcome. We are concerned that this will be an ongoing problem, if only every few months or so.

Could you clarify a bit on how the PXI-6528 was acting while you were seeing these problems? Does this card have values display on the Remote Front Panel, and if so were they still updating properly? I believe you were saying that, but I wanted to be sure because that makes a big difference.
If everything became static, including the DIO card, at the same time, then I'd say see if your browser updated, or something in your network settings was changed without you noticing. Perhaps an update ran and reset some of your firewall settings, or an Internet Explorer update changed something that required a reboot.
If just the outputs of chassis 2 were the problem, and the DIO card values on your remote front panel still worked well, then it is most likely a problem with your MXI-4 cards or your fiber optic cable that cause the change in behavior.
Miles G.
National Instruments
Applications Engineer

LV2011 problem with several front panels

Hello,
There is a bug in my software and I don't know it is common to every one or not. This not to be worry, I will notify you anyway. When I open only one front panel and one block diagram which having a program to communicate with a serial device. In this case, if I choose the VISA resource name, it obviously takes some time to popup the USB and after it show the port and front panel will stay in front you until you choose the device. Here, every thing is fine but when I open several front panels and working on only with serial program front panel to choose the serial device in VISA resource name. Then after some time, it took me to another front panel. I have seen this problem several times in past two months. More, even when I am decorating the front panel and front panel took some time after pushing some controls and switched another front panel.
Is this bug? Or I common for every one.
Using labVIEW 2011.

I am certainly using labVIEW from two months. So, I did not use MAX in my past time. I only used one time to check my USB 6008 device but this is off topic here. I will tell you down here.
Suppose, If I open multiple VI's and I am only working with one VI that can communicate with my SERIAL device and the rest of the VI's(Block diagram and front panel) are rested. This case, if I click the drop downlist of "VISA resource name" of SERIAL VI, then it took some time(200ms or 100 ms, just it is a guess) to populate and it is switched to another front panel which were opened and rested before. Again, I need to come to my serial front panel again to select the COM port. This is one case.
If don't have any other VI's not opened than this serial Vi. Then it stays on the same front panel.
Is this bug came with labVIEW or is it common?

Clearing Previous Front Panel before displaying a new one.

hi,
My problem is clearing the old front panel. What I have is a VI with a CONFIG button. When user presses the config button front panel # 2 appears. There is a NEXT button on from panel #2. When you press the NEXT button front panel #3 pops up. The problem is that front panel # 2 stays in the background behind the new front panel # 3. What do i have to do to cancel the prevoius front panel?
Solved!
Go to Solution.

This will cancel the pervious window. Your booleans should be inside the event structure.
Reese, (former CLAD, future CLD)
Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
Attachments:
start with this VI-2.vi ‏8 KB
2.vi ‏17 KB
3.vi ‏14 KB

Calling vi front panel object update in a running sub-vi loop?

Hello All. I have a calling sub-vi with a "Start Test" button on the front panel. I passed a control reference for that Start button into a sub-vi that runs in a while loop. The while loop is monitoring that Start button and other things.
Problem: Once the sub-vi runs, it no longer takes updates from that Start button. My program never leaves that while loop in response to my Start button.
Is there some way I can make the sub-vi take an updated value from the calling vi?
Attached is the sub-vi (top level, LabVIEW 2011). Please note that I have already tried putting the Start Test terminal inside the loop, but that did not help. I put comments in the block diagram and the front panel to help identify the problem code.
I am going to get around this problem by running this whole vi through a loop in the calling vi, where I can easily respond to button changes. This is mainly an academic or curiosity problem now.
Thank you, Richard V
Solved!
Go to Solution.
Attachments:
Channel Setup.llb ‏286 KB

Lets just whip up a little example then shall we?
The subvi you see contains:
Go ahead and run the top vi. Press OK and watch the value of Value change (up to 20 times per second but that is faster than your eyeball).
Why the difference between this simple example and what you are seeing?
If I had to guess (And, I do since the caller wasn't encluded) I would suspect that you misswired the reference. With that over-burdened connector pane and no required terminals it would be fairly easy to do.
And thats where you might want to ricght-click the vi and deselect view as icon.
You'll find out that its a lot easier to wire the right terminals that way. Also, changing the terminals to "Required" for anything that is as important as an exit condition is a good idea. Perhaps even exit if the reference is null although that should cause an error on the property node. Did you shut off automatic error handling?.... Nope you didn't so there is a valid reference going into the sub-vi. But a reference to what? maybe not the button you think.
Jeff

Simple example - Break FOR loop inside an event structure based on Front panel event change.

I am running a for loop inside a state machine architecture that contains a FOR loop. How can I break this For loop based on Event change in front panel ??
Abhilash S Nair
Research Assistant @ Photonic Devices and Systems lab
[ LabView professional Development System - Version 11.0 - 32-bit ]
LabView Gear:
1. NI PXI-7951R & NI 5761
2. The Imaging Source USB 3.0 monochrome camera with trigger : DMK 23UM021
OPERATING SYSTEM - [ MS windows 7 Home Premium 64-bit SP-1 ]
CPU - [Intel Core i7-2600 CPU @ 3.40Ghz ]
MEMORY - [ 16.0 GB RAM ]
GPU - [ NVIDIA GeForce GT 530 ]
Attachments:
Case inside Event 3.vi ‏19 KB
Case inside Event.ctl ‏6 KB
Case inside Event 2.ctl ‏6 KB

Okay. Accpeting that the design is not favorable and not advantageous when my program expands. I have begin to follow producer/consumer programming architecture.
Please find the attached program which is a simple producer consumer with event structure. I wonder how could I stop looping around the producer and consumer loops over and over again. I am pretty sure that this ENQUEUE ELEMENT loops back to the consumer loop and starts from begining.
I hope my first program in PC architecture with State machine and Event structure is correct.
Abhilash S Nair
Research Assistant @ Photonic Devices and Systems lab
[ LabView professional Development System - Version 11.0 - 32-bit ]
LabView Gear:
1. NI PXI-7951R & NI 5761
2. The Imaging Source USB 3.0 monochrome camera with trigger : DMK 23UM021
OPERATING SYSTEM - [ MS windows 7 Home Premium 64-bit SP-1 ]
CPU - [Intel Core i7-2600 CPU @ 3.40Ghz ]
MEMORY - [ 16.0 GB RAM ]
GPU - [ NVIDIA GeForce GT 530 ]
Attachments:
Case inside Event 3.3-ProducerConsumer Event.vi ‏25 KB
Case inside Event.ctl ‏6 KB

How can I display the front panel of the dinamically loaded VI on the cliente computer, the VI dinamically loaded contains files, I want to see the files that the server machine has, in the client machine

I can successfully view and control a VI remotly. However, the remote VI dinamically loads another VI, this VI loaded dinamically is a VI that allows open others VIs, I want to see the files that contains the server machine, in the client machine, but the front panel of the dinamic VI appears only on the server and not on the client, How can I display the fron panel with the files of the server machine of the dinamically loaded VI on the client computer?
Attachments:
micliente.llb ‏183 KB
miservidor.llb ‏186 KB
rdsubvis.llb ‏214 KB

I down loaded your files but could use some instructions on what needs run.
It seems that you are so close yet so far. You need to get the data on the server machine over to the client. I generally do this by doing a call by reference (on the client machine) of a VI that is served by the server. THe VI that executes on the server should pass the data you want to diplay via one of its output terminals. You can simply wire from this terminal (back on the client again) to an indicator of your choosing.
Now theorectically, I do not think that there is anything that prevents use from getting the control refnum of the actual indicator (on the server) of the indicator that has the data, and read its "Value" using a property node. I have never tried this idea but it seems t
hat all of the parts are there. You will need to know the name of the VI that holds the data as well as the indicator's name. You will also have to serve all VI's. This is not a good idea.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

VI containing Event Structure will not receive front panel events in LabVIEW Real-Time.

Hi again, I'm working in my first UI (attached VI).
It works when running directly from PC. It doesn't when running from cRIO, there's the message "VI containing Event Structure will not receive front panel events in LabVIEW Real-Time". I've been reading and I found that "Event structures on RT targets do not support events associated with user interface objects, such as VI panels or controls. For example, associating the Value Change event with a control does not work. RT targets support only user events".
Is that the problem? If it is, how can I create Mouse Up, Mouse Enter, Value Change (or other user interface events) user events?
If I run my VI in FPGA mode should it run?
Attachments:
HMI.vi ‏33 KB

Since it looks like you are new to the whole RT and machine control, I recommend giving this a good read: NI LabVIEW for CompactRIO Developer's Guide
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Don`t close front panel in a loop

   I'm doing a numerical limit step that calls a labview module and show the measurement in the front panel.
   My problem is that I want to do the same mesaurement using the loop options, and every time the loop executes, my front panel is open and closed.
   The right behavior is opent the front panel the first iteration, do and show the measurements during the loop, and close the front panel in the last.
Really I can`t find any option to do this in only one step.

see at this link for response
http://forums.ni.com/ni/board/message?board.id=330&message.id=11573#M11573
Regards
Ray Farmer

Minimise front panel of vi containing timed loop = problem

Similar Messages

Maybe you are looking for