Front panel remains after terminating lavbiew application

I have created an application from a LabView VI. I'm launching the application from LabWindows. I'm monitoring for the application to terminate. However, when I terminate the LabVeiw application, the LabView front panel is displayed and the LabWindows application terminated function doesn't see it as terminated until I close the front panel. Why is the VI front panel being displayed when the application is terminated. I have the program to run in dialog center screen. Once the application terminates, the dialog disappears and the LV front panel appears.

I like to put the Close invoke node inside of a Conditional Disable Structure. This way the front panel only closes when you are running an EXE and not when you are playing with the code.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Attachments:
Close Front Panel.png ‏10 KB

Similar Messages

Selecting front panel properties after runing causes crash

After I run my program (which uses several call library function nodes to access numerous dll files) and then try to alter the properties of a front panel control labview crashes. Sometimes it simply locks up, other times it displays a recoverable error message, and finally sometimes it displays a hard error message from which I cannot recover and only send an "error report." While the errors are annoying I really want to know why changing the properties causes them which may lead me to other problems in my code. Thanks for any thoughts you can provide.
-Dave

NIDave wrote:
> Thanks for the reply Jeremy, I try to change them manually after the
> program stops. I use a property node to alter other controls but not
> the one I discovered the problem on. I am suspecting a memory leak
> within the dll or some problem with the way I am passing strings and
> arrays in and out of my call library function nodes. (I initialize
> the strings and arrays before the function is called, so I am leaning
> toward an issue in the C code.
Well here you go. Calling a DLL and then getting (delayed) crashes in
LabVIEW absolutely always means that the DLL is trashing some memory it
shouldn't. This either happens by passing wrong data (DLL expects by
reference and you pass by value) or arrays and string not initialized or
not intialized to be large enough. Last but not least the DLL of course
can just simply be buggy and do stupid things.
So you will have to verify somehow that the DLL works correct outside of
LabVIEW. If you have verified that, then you need to check all
parameters of all function calls into the DLL to be correct and also
large enough for the DLL.
Especially make sure that for strings you allocate 1 more byte than the
longest string the DLL may want to write into, and for arrays that you
allocate the right number of elements of the right type. Sometimes the
documents state that the array must be at least 100 elements long but if
this is an integer then that amounts actually to 400 bytes.
> Also another oddity, when I first open labview and run the code it
> works great, however if I try to close the VI but not labview then
> run it again it fails. I think that labview is not dropping the dll.
> Is there a way to force it to release the dll?
Not really. A DLL should not depend on being unloaded to be callable
again. But the error you describe could be because of several reasons.
Basically make sure you call any existing Close or similar function at
the end as well as initialization function in the beginning. Also the
error could be related to the DLL trashing memory somewhere. So try to
get the DLL to work properly without any bad effects after having it run
once including no crash when unloading the VI, closing any front panel,
doing some LabVIEW edit functions or last but not least closing LabVIEW.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to stop my 1553 Remote terminal application from locking up the Front Panel when the Bus Controller application is causing msgs traffic over the 1553 bus. This simulation uses WIN98SE with excalibur ISA cards.

This simulation has several transmit and receive messages. The fastest message refresh rate is set to 50Hz (20 ms).

Hi,
Can you provide some more information about what hardware and software you are using? What is your application? Thanks!
JenK

My front panel controls are disappearing after the vi starts. Anyone one know how to fix this?

I have some vis that ran fine on an older machine, but with the new computer controls on the front panel dissappear after awhile and can be made to reappear after closing and reloading the vi. I am not doing any programmatic hiding of any controls. The controls can also be made to reappear by stopping the vi and selecting them with a tool, but then they disappear again when you run the vi again. I played around with "bring to front" but that doesn't fix the problem and read a post about OpenGL problems associatted with 3D controls. Any ideas on what to try to fix the disappearing controls?
I

If you right-click on the terminal and choose 'show control' and then the control can be seen, then it is not hidden behind other controls, decorations, etc. Just to ask a dumb question: have you right-clicked on the terminal and tried Find --> Property nodes to make sure that the control(s) is not being hidden somewhere in your code? Are you passing any control refnums to any subvi's?
"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal

Error accessing Remote Front Panel on RT Target after upgrade to LV2011

I'm upgrading a real-time application (target is a desktop PC running the LabVIEW real-time) from LabVIEW 2009 to 2011. Under 2009, it was possible the view the main VI remotely by browsing to a static HTML page that embedded the front panel. After upgrading to LabVIEW 2011, instead of the front panel image I get an error saying "Server does not support Remote Panels." I have already gone through the list of possible causes from "Server Does Not Support Remote Panels" Error When Connecting to Remote Front Panel, and none of these resolved the problem. I am using the standard LabVIEW web server, there is a direct ethernet cable connecting my computer with the real-time system, and I have recreated the web page to reference the correct plug-in version. I reformatted the RT system and then did a clean install of the components from LabVIEW 2011 (using the Add/Remove Software feature in Measurement and Automation Explorer). I also created a new test project with a new simple VI; I was able to access that VI remotely on port 8000, but not on the default port 80 (which used to work under LabVIEW 2009). What changed in the web server between LabVIEW 2009 and 2011? Can I use the standard HTTP port 80 to serve a static page with an embedded VI, or does this now only work on other ports (and if so, why)? Will I need to recreate my entire project in LabVIEW 2011 in order to get this working at all?

Got it working, after much experimentation. Seems to require installing exactly the right combination of items on the RT target, as some items (web services? web configuration? the "application web server"?) apparently run a separate web server - or instance of the web server - on port 80, which prevents remote front panels from being served on that port.

Can't remove Front Panels in Application Builder

I have had a few issues using Application Builder (v7.1) in regards to it removing or not removing front panels for my subvi's when I was trying to compile. Here are the conclusions I came to if anyone else runs into the problems I had.
Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.
Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.
For problem 1, I decided not to worry about linking the files dynamically in the Application Builder, but to just make sure the Application Builder would include their front panels. For problem 2, I had to figure out what was making Application Builder force the front panels to be included when I deemed it unnecessary, so that I could fix them not to be included. Basically then, going through my VI's that were forcibly included, I came up with a list of stuff I began checking for each time I would run into one where I didn't want to include the front panel. I have attached my list to this post.
My solution for problem 1 was then to use a customized appearance for my static-linked / dynamically loaded VI's, and disable the menu bar (forces the front panel to be included by Application Builder without changing appearance, since I never actually see the FP). My solution for problem 2 was often to remove property nodes referencing text on the front panel controls. Sometimes I was able to perform a numeric->text or enum->text conversion instead of referencing the text of the control itself, and sometimes I realized I didn't want anything to change and that it was ok to include the front panel so I could (for example) get a list of strings for my enum control.
I have attached the reference list I came up with of things to check for to make sure your VI properties are set correctly if you are trying to get Application Builder NOT to include the front panel of your subvi. The list might not be complete, but it's helped me to narrow down things very quickly and find the problems I was having.
Attachments:
ThingsToCheck.doc ‏61 KB

m3nth wrote:
Problem 1) Some of the front panels were being removed for dynamically loaded VI's, which were not set as dynamic VI's in the Application Builder, but which were static-linked VI's in the program (so they were loaded in memory as linked subvi's but called dynamically). When the Application Builder decided to remove the front panel for those VI's, there was an error when loading them dynamically.
This is expected behaviour. The application has no way of knowing that these VIs will at some time be called dynamically. That would require analysing and understanding the entire program and in cases where you calculate the dynamic VI to be called at runtime it still wouldn't be feasable to do so.
m3nth wrote:
Problem 2) Some of the front panels were NOT being removed for subvi's that I didn't want to have their front panel built into the compiled program. Loading front panels that are not needed uses extra memory, but there was no way to change the option to not load the front panel for certain particular subvi's in Application Builder--the option was grayed out.
There are several reasons why a front panel is needed. One of them is when the VI is called dynamically, even if the FP is never displayed and AppBuilder will account for that for VIs which have been added as dynamic VI to the project.
The other is when a VI uses some Property Nodes or Attribute Nodes as they are called now.
So to solve your problem 1) you could also just drop some property node in the diagram of such VIs and be done with it.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Application with many Front Panels

Dear all,
I am working on an application which has 3-4 front panels.
Like, when the application starts, the "User Profile" panel is shown. From there i can move on to 2 different panels.
1 panel is for Taking data from the new user. another for taking test of the user.
i want to know is it advisable to display each panel from different VI, or, shud i have them all in a single VI and handle them by making Visible property On/Off.
Thanks,
Ritesh
Solved!
Go to Solution.

I think that the best way to do it would be to use the tab control. Place all the controls or indicators for each different "front panel" that you would have on the different tabs and then make the tabs visible/invisible. That way you only have one contol/indicator to keep up with. You could do a search for creating a wizard in LV. You would also benfit by using a statemachine type architecture for this.
WOW, while I was typing the message there were 2 more replies, all with pretty much the same answer..
Great minds think alike!!!!
Message Edited by Joe_H on 03-23-2009 10:48 AM
Joe.
"NOTHING IS EVER EASY"

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 .

How to resize the front panel to fit different resolutions

I m using LabVIEW 8.2 on Windows XP SP2
I've tried both “maintain proportions of window for different monitor resolutions” and “scale all objects on front panel as the window resizes” selected but just messed up everything when i switched to another different resolution. It's annoying since I'm using 22 inch monitor to do the coding but the user supposed to run it on laptop or wince.
Any solutions to it?
Thx in advance.

Thank you all. Following is the reply from NI support. I think the best way is to edit vi in low resolution.
One of the easiest ways to tackle varying screen resolutions is to design
the front panel to the lowest resolution that you expect it to run on. It
should then look acceptable on any screen larger than that.
However, you can get a bit more tricky by programmatically determining the
computer's screen resolution and then dynamically changing the size of your
front panel objects. Use an Application Property Node and select
Display>>All Monitors to return the current screen size. Then, according to
the screen size, you can size the control or indicator programmatically
using the Size property node for your front panel objects.
Ultimately, these issues have often been a result of font size issues.
Specifically, this can be a problem when two machines have different
desktop theme/font settings. If your objects are coming out in different
sizes on different computers, you can setup up LabVIEW to use the same font
on different systems by modifying the .INI file.
The easiest way is to do this: use Tools->Options->Fonts from the LabVIEW
GUI. You can then set the system fonts to anything you want. After you
have done this on one machine, open your INI file (it is in the same
directory as the LabVIEW executable) with any text editor and copy the
corresponding entries to another file. Add these entries to the INI files
on any machines you want to lock to font. You will probably run into
issues if you are supporting different platforms (Windows and Mac or Mac
and Linux, for example), since the fonts you want may not be available on
both platforms. There are Windows fonts available for both Mac and Linux
platforms, so this can be somewhat ameliorated.
This is all I can think of, but that's not to say these are the only
solutions. You might check the Discussion Forums, as many of our LabVIEW
Champions have tackled similar issues and offer their expertise as well.
Here's just a few threads that I'd like to refer you to:
How to make the size of VI and controls unchanged irrespective of the
resolution?
http://forums.ni.com/ni/board/message?board.id=170&message.id=273613&requireLogin=False
How to program the front panel size to fit different monitor resolution?
http://forums.ni.com/ni/board/message?board.id=170&message.id=87160&requireLogin=False
I hope this discussion helps you along the way in your application
development. Please let me know if you have any further questions/comments
and I would be happy to discuss them with you.
Otherwise, it was a pleasure assisting you and thank you for choosing
National Instruments.

Lights on front panel of Envy 120 printer disappeared

After a paper jam, the front panel lights stopped lighting. The error message said that I needed to change the color ink cartridge (which unfortunately was only a couple weeks old). I changed it but no lights. I could still print via the computer but was unable to use the "copy" or "scan" feature since I was unable to "touch" the lights on the front panel. After speaking with HP, they decided it was a hardware issue, and even though I was only 5 months past my warranty, had no solution other than to buy a reconditioned printer from them for more cost than the price online. However, I noticed when I printed something directly from the computer, the front panel opened, the arm swung out to hold the newly printed paper, and the LIGHTS CAME ON! So my solution is to keep a piece of paper forever on the "arm" to make sure the front panel stays open--I can then access the "copy" feature because all the lights now work. I know this is not a GREAT solution, but it is at least allowing me to use up my several cartridges of new ink until I get tired of having a defective printer.

Hi @SHF710
I would leave the printer on and unplug the power cable, then after a minute, plug it back in. When the printer starts up it should open the display panel on its own. Also, please ensure you have the printer connected directly to a wall outlet and not into a surge protector.
If the issue persists, I suggest using the following link to ensure your printer has the newest firmware; Critical firmware update to improve printer performance.
If the issue remains unresolved still, I suggest calling HP. If you are in Canada or US call 800 474 6836, or you can Contact HP Worldwide.
I hope this helps. Please let me know if one of these recommended solutions resolves the issue.
Please click the Thumbs up icon below to thank me for responding.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please click “Accept as Solution” if you feel my post solved your issue, it will help others find the solution.
Sunshyn2005 - I work on behalf of HP

Display and interact with a vi front panel on remote C++ app

Hello:
I am new to LV and need a little advice. I need to display a LabVIEW VI front panel in my C++ .Net application that users can interact with to view real-time spectrum data. The C++ app (client) must reside on a separate computer(s) from the VI so that the client can connect from anywhere around the world and interact with the VI.
I am not sure about the basic architecture that should accompany a good solution. We want to use TCP/IP but not DataSocket. I do not have access to Measurement Studio but I do have access to LabVIEW Professional Development System v 8.2. Can anyone provide suggestions on what I need to do in order to
1. Connect to my TCP server using my C++ client app - I have already written TCP client and server code which communicate but now I need to integrate LV
2. Get access to the VI sitting on that server
3. Send the VI front panel to the client for display
4. Allow the user to modify parameters on the front panel displayed on the C++ client, send those changes back to the server, and refresh the front panel displayed in the C++ client given the new parameters (I would like a real-time display of the spectrum to always be available)
Is this possible? Has anyone done this using C++ .NET in VS2005? Are there examples I can mimic or references that will help direct me? I have searched and searched through NI's help and found a lot of good stuff but I'm still feeling confused about the best way to utilize LV.
Thank you in advance!

One more question ... what if I could use Measurement Studio? The documentation seems to indicate that it's easy to create network applications and therefore it would be easy for me to re-create our VI's front panel using Measurement Studio components in my C++ app and then simply connect those components to the networked hardware (TCP/IP or DataSocket) that could be located anywhere in the world.
Depending on what components you are using in your LabVIEW panel, it is probably pretty easy to build a Measurment Studio application to look like a LV panel.
Given that, you could use network shared variables to move data across the network, no TCP programming necessary -- I think that this is pretty easy to do, but I don't know the specifics about variable programming in that environment. Also, you will probably need to add some smarts to the server side to make sure that it is reading to and writing from variables in an appropriate manner.
Question: why can't you just use LabVIEW for the client application also?

Why does the Font color change on my front panel?

I'm using the Font Dialogue to change the color of highlighted text on my front panel. After I save and reopen my app some of the Text will revert back to their original color (Black). Is this a bug in or am I missing something?

I assume that you want all control labels with white text. If I change the black ones to white and save the VI, the white text color is retained.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
Control Console.vi ‏90 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

HP Pavillion HPE-510f, Windows 7, 64 bit with front panel A/V RCA inputs

When i connect devices thru the AV inputs on the front panel, I cannot find an application that recognizes the device. For example, JVC Camcorder so i can playback or just playing music thru these inputs. Is there a driver that needs installling?

Hi Hodgewaco,
As indicated in the title, the front A/V RCA and s-video are input ports. To use those ports with your videocam you are going to need a capture program. ROXIO has commercial programs that should work with those input ports but check with ROXIO Sales. Usually ROXIO has a 30 trial period so if you are not satisfied the your can get a refund. Be sure to inform ROXIO about the exact model of camera that you are using, the output connection type and the format of the video stream.
HP DV9700, t9300, Nvidia 8600, 4GB, Crucial C300 128GB SSD
HP Photosmart Premium C309G, HP Photosmart 6520
HP Touchpad, HP Chromebook 11
Custom i7-4770k,Z-87, 8GB, Vertex 3 SSD, Samsung EVO SSD, Corsair HX650,GTX 760
Custom i7-4790k,Z-97, 16GB, Vertex 3 SSD, Plextor M.2 SSD, Samsung EVO SSD, Corsair HX650, GTX 660TI
Windows 7/8 UEFI/Legacy mode, MBR/GPT

No front panel audio/ no front/back panel inpu

I have 32bit windows vista home premium and a x-fi platinum card and the audio inputs on the back or front panel dont work. The speaker plug will work on the back, but the headphone plug on the front wont work either. There is a red light coming out of the optical input on the front so the unit is powered. The ribbon cable is also hooked up correctly. Ive fooled around with the selecting default device settings in the sound mixer and it still does nothing.

Guess I should post what I'm using:
Intel Q6600
MSI P6n SLI platinum mobo
8800gts
3gb ddr2 ram
creative x-fi platinum
windows vista home premium.
I recently upgraded the mobo proc and ram and upgraded to vista. under xp with my Athlon 3000+ the front panel worked, after the upgrade its no go. The only ports that work on the back are the mic and the speakers.

Front panel remains after terminating lavbiew application

Similar Messages

Maybe you are looking for