Front panel / Block diagram sometimes disappear

Hi, I am running LV7 on Windows XP. When I have a few windows open
with front panel and corresponding diagrams, some of those windows
disappear after being minimized or put in the background. When I try
to restore the window,Ctrl-E or task bar, only the function- and tool
palettes get focus.
This is very annoying! please help
/Pelle
PS. I hade the same problem with LV6.1"

Here is the answer.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Similar Messages

  • How can I unlock a front panel/block diagram in LabVIEW 7.1?

    I inherited LabVIEW (7.1) code  that when I try to edit, I am not allowed. I can access and used Functions and Controls, but I cannot connect or delete them back. The mouse indicator is a hand all the time. It does not change to cross hair or wiring tool.
    In the  Security section of VI properties "Unlocked(no password)" is selected.
    How  can I fix the problem?
    Thanks for your help. 

    Sounds like you have got the automatic tool shutoff, go to menu and select window/ tools pallette and then turn back on the automatic tool. I think this is where it is located for 7.1.
    Joe.
    "NOTHING IS EVER EASY"

  • 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

  • Front panel not showing controls

    i have encountered a very strange thing where very often all of my front panel control displays will disappear. Closing and reopening the vi does not really solve the issue either. none of the controls should be hidden....
    where the panels should be:
    but arent:

    vi should be attached
    Attachments:
    odor controller 8+1.vi ‏76 KB

  • How do I get the Label for a Front Panel Control to appear in the Block Diagram but not on the Front Panel?

    How do I get the Label for a Front Panel Control to appear in the Block Diagram but not on the Front Panel? On the Front Panel I am making a complex control that consists of a Slider and a Numerical Input box. Both Controls display the same information and either can be used for Input. When one changs, the other is made to display the same value.
     But I only want the Slider to display the Label on the Front Panel, to avoid confusion. On the Block Diagram however, I want both controls to display their Labels so that I know what they are. How do I display the Label for a Control on the Block diagram, but not display its Label on the Front Panel?

    No.  The Label Visible property is separate for the front panel control label and the block diagram terminal label.
    How did you start out with the block diagram's label not being visible?  Whenever I drop a control or indicator, the label is always visible on both the FP and BD by default.  Maybe there is a LabVIEW option that causes new controls/indicators not to have their labels visible by default, but I have yet to find it.  I don't think an item should ever be dropped without the label visible, good LabVIEW coding practice demands that the labels for control terminals on the block diagram be visible so that you know what control or indicator a wire is going to.
    That being said, I have seen a lot of VI's posted where the label for the terminal on the BD is not shown (against good programming practice.)  I've gone to the BD and right clicked to show the label.  Sometimes, the people have an empty label (which will turn off the visibility for both the FP and BD) and I'm forced to add some text of my own into the label so I can figure out what their code is doing.  When I add some text to the label, at that time, I find both the BD and FP labels become visible.
    Are you dealing with controls that have empty labels to start?
    Good programming practices:
    1.  Always have a name for all of your controls, never use and empty label by deleting the text in the label.
    2.  Make the labels unique.  For example, don't have two controls both called Stop.  How do you know quickly know which terminal relates to which control?
    3.  Always show the labels on the block diagram, so you know the function of a control's terminal.  If you want to hide the label on the FP, that's okay.
    4.  If you want a different label to appear on the FP than whatever you actually called the control, then use the caption.  You can hide the label and show the caption.  This is useful if you need to programmatically change what the "label" is on the front panel such if you are making an application that needs to change its user interface such as for a foreign language.

  • Close front panel but leave open block diagram

    Is there a way to do this? I would like to have my block diagrams of a few subvi's open but front panels closed so my task bar isn't so cluttered. It's not a big deal, I was just curious
    CLA, LabVIEW Versions 2010-2013

    Chris_VH wrote:
    No current way unfortunately.
    A colleague and I actually just put in a product suggestion for this yesterday.
    So if they fix this do I give you or them credit for the solution?
    CLA, LabVIEW Versions 2010-2013

  • I created boolean references in my main vi block diagram and copied them to my sub vi front panel. when wire my reference in my main vi to one the input node of the sub vi the wire is broken. the error says its a class conflict why?

    i created boolean references in my main vi block diagram and copied them to my sub vi front panel. when wire my reference in my main vi to one the input node of the sub vi the wire is broken. the error says its a class conflict why?

    Expanding and clarifying what BJD said;
    After you create the temporary sub-VI that BJD mentioned, open its front panel and copy the reference control that LV created when it created the sub-VI.
    This reference control will be correct class etc that you need. Use the control to replace the original control that you were attempting to wire up.
    The technique of "create sub-VI...copy" always works for me.
    There is one more thing that you should watch out for.
    The mechanical action of the boolean can not be set for latch action when attempting to read the value using a value property node.
    Trying to help,
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Block diagram, front panel messed up

    Why do block diagrams and front panel controls get bunched up and screwed up when you open vi's on different computer with different labview versions.
    Can anything be done to prevent this?
    Does everybody have this issue?
    Thanks,
    Dustin

    You can _try_ to address this issue by right clicking on the vi's icon when it is open in the edit mode, select "VI properties", select "Window Size". Under this selection there are two selections that   _may_  help, they are supposed to partially address the issue you are describing. I never had much luck with them in the past, have to admit I have tried them in a while, try to find out what the target system's resolution is and develop the code in that resolution.
    Putnam
    Certified LabVIEW Developer
    Senior Test Engineer
    Currently using LV 6.1-LabVIEW 2012, RT8.5
    LabVIEW Champion

  • Bug: Front Panel objects relative position change when placing merge VI onto Block Diagram

    I've posted a bug report on LAVA, here:
    http://forums.lavag.org/Front-Panel-objects-relati​ve-position-change-when-placing-merge-VI-onto-Bloc​...
    If someone at NI can reproduce, can I please get a CAR #?
    Thanks,
    -Jim
    Solved!
    Go to Solution.

    Donovan B wrote:
    Hi Jim,
    After my previous post, I also saw this behavior, so I decided to do another test.  If there are no decorations in the VI set to “Merge VI” (“Place VI Contents” for LabVIEW 8.5 and later) the controls and indicators are still not selected when dropping the VI from the Functions palette.  I checked this behavior back to LabVIEW 7.1 and it is consistent throughout that controls and indicators are not selected.  (Consequently, so is the fact that when decorations are present they don’t maintain the relative position).
    I am not sure if this would be better suited as a CAR or product suggestion since it has been this way that long, but it does not appear to be related to the fact that decorations are present in the Merge VI.  It does seem strange that the decorations are selected though.  Looks like the best way to work around this is to drop the VI from the Controls palette.  Hopefully, it’s not too much of a hassle.
    Hi  Donovan,
    Thanks for checking in.
    >  I checked this behavior back to LabVIEW 7.1 and it
    is consistent throughout that controls and indicators are not
    selected.  (Consequently, so is the fact that when decorations are
    present they don’t maintain the relative position).
    This just means that not many people use this feature.  However, now that VIPM Professional makes it so easy to edit the palettes, I'm sure that others will start complaining that this doesn't work as they expect.
    > I am not sure if this would be better suited as a CAR or product suggestion
    since it has been this way that long, but it does not appear to be
    related to the fact that decorations are present in the Merge VI.
     Just look up the functional specifications for this feature and see if all objects are supposed to be selected.
    But seriously, is there a reason that only the FP decorations are selected?  Surely this would be documented somewhere, if there was a good reason for this current (IMO, buggy) behavior.
    > It
    does seem strange that the decorations are selected though.  Looks like
    the best way to work around this is to drop the VI from the Controls
    palette.  Hopefully, it’s not too much of a hassle.
    That's not a reasonably work-around, IMO.  It doesn't make sense to drop Block Diagram components onto the Front Panel.  For example, this bug affects the JKI State Machine.  It doesn't make sense to drop a State Machine onto the Front Panel.
    So, I'd file it as a CAR/bug, and then wait to see how LV R&D feels about it.  If they can find some valid reason for why Controls and Indicators shouldn't be selected, then that's fine (and hopefully someone will explain it to me).
    Thanks,
    -Jim

  • What is the best way to keep the block diagram/ front panel clean?

    Hello,
    I am relatively new to Labview so I'm not able to tell if I'm overcomplicating my programs or making my block diagram too cluttered. I was wondering if there were some ways to tell whether I could simplify my programming just by looking at it (perhaps only experience helps for these things) ? 
    I have attached my VI here. Currently, it has the capability to monitor the voltage and current from two motors. On display, you can see a indicator with the voltage and current values and there are charts toward the bottom that can display waveforms from different motors with a drop down menu. 
    The front panel is rather clean in my novice opinion, but the block diagram seems messy to me, just at first glance. I foresee a problem occuring in the future however. In the future, I will have to scale the VI to monitor 50 motors. All the programming will be the same as the one I have now, except it will have 50 indicators and unfortunately 50 times pretty much everything. I would like to avoid this, but I'm not sure how I could.
    I am using a USB 6009. I am using its four differential inputs to monitor the voltage and current of two motors. In the future, I will be getting more DAQ units (25 total because 2 motors can be monitored for each DAQ). The new DAQs will help will help with more resource space, but I think complicate things with the additional potential of 24 more DAQ Assistants (as used in my code). 
    Thanks for any help you might be able to provide!

    It usually is mainly experience that will teach you the best methods to make your code look pretty. I don't know anyone who is proud of their first from-scratch application. There are a few resources out there to help with best practices, like this group on ni.com, but you'll learn the most from your own development.
    Your front panel looks great. FPs in general are really up to you. You can make it look as ugly or pretty as you want. When you have some duplicate controls and indicator groups, you should utilize clusters and arrays to simplify. You could use a little bit of cleanup in that regard, but not much. Also, personally, I hate reading red text unless it's a warning of some sort.
    Your block diagram could use some cleanup in a modularity sense. You have a lot of repeated code, which you could consolidate in to a subVI that is used in multiple locations, or in a For loop. A general rule of thumb is to keep your block diagram within a single monitor. You shouldn't have to scroll. Your application is pretty simple, so it's hard to mess it up
    Here are some specifics about your block diagram:
    Right click your terminals on the block diagram and uncheck "View As Icon". You're welcome.
    Duplicate operations on each waveform "(x*2-4)/16": create subVI and/or run the waveforms through a For loop.
    You do a lot of 2-element arrays and then indexing. Just replace those with a Select node based on the numeric.
    All of your code is running every time, including your property nodes at the bottom, which is unnecessary. As you learn LabVIEW architectures, you will learn how to bypass this with initialization and exiting code, but for now you should put a case structure around those for only when the motor numbers change.
    I'm not sure how you're timing your main loop, but you should put a delay in there because you don't need the DAQmx node to be pulling as fast as your CPU will allow.
    There are free intro videos you can watch to learn what NI would suggest in terms of coding and teach you some of the basic features and such. Here's a three hour course, and here's a six hour course.

  • 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

  • Why cannot the block diagram view of a VI show the "connector pane" view in the UR corner, like the front panel view does?

    Perhaps there is a good reason for this that I just haven't figured out. I haven't seen any questions about it searching the NI site, however.
    But it just seems totally inconvenient to always have to go to the front panel to get to the connector pane view, especially if some of those connectors are hidden. Then I have to go to the block diagram, guess which control/indicator I want to unhide, go back to the FP to check it on the connector pane, then go back and hide it again, and repeat if necessary. Even if the C/I is visible on the FP, it's still an extra step or two.
    When I'm building connections using the block diagrams and planning where to put connectors in subVIs so they would be easier to wire up (line up inputs/outputs on sides, not have to go top-to-bottom, etc.), it sure would be nice to be able to work totally in the block diagram realm.
    Cameron
    To err is human, but to really foul it up requires a computer.
    The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
    Profanity is the one language all programmers know best.
    An expert is someone who has made all the possible mistakes.
    To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):
    LabVIEW Unit 1 - Getting Started
    Learn to Use LabVIEW with MyDAQ
    Solved!
    Go to Solution.

    Yamaeda wrote:
    Good idea, put it in Idea Exchange!
    It has been there for a while already. No need to duplicate....
    LabVIEW Champion . Do more with less code and in less time .

  • I am trying to create an executable vi that will call out another vi and show its front panel in the executable​. When I try this I recieve this error message "top level vi (my main vi) was stopped at unknown on the block diagram of (my sub vi)

    I am trying to create an executable vi that will call out another vi and show its front panel in the executable.  When I try this I recieve this error message "top level vi (my main vi) was stopped at unknown on the block diagram of (my sub vi)

    Well the most common way is to enclude the vi's in the build spec either directly in the dependancies that the App builder automatically generates OR by declaring them in the build spec as "additional enclusions" (like you must do for dynamic vi calls in your app.
    I have heard rummors about My.app Stuff.vi in a nugget Intaris posted- and I've wanted to dig deaper into Intaris' claims- but have not tried it myself.
    If you go down the stuff.vi route Keep us curious guys posted
    Jeff

  • How can I create multiple front panels for a single block diagram?

    Hello,
       I have developed a VI with multiple controls and indicators that needs to run on computers with screen resolutions ranging from 800x600 to 1680x1050. The problem I'm having is that the front panel does not properly scale for this range of resolutions by checking the options in the "VI properties" option. Is there a way to create multiple front panels of various sizes for my block diagram and programmatically select the appropriate front panel based on the screen resolution?
    Solved!
    Go to Solution.

    See the attached Zip file.
    I have two different front panels.  Open either one and run it.  They both call MainCode.vi which takes the references passed to it and register for events.  From there, it does all the work of the code you would have put in your front panel .vi.
    This way each front panel can be laid out however you want for each screen resolution.
    Attachments:
    MainCode.zip ‏22 KB

  • Image of the front panel and block diagram

    Hi,
    I need to get some info from the block diagram but I don't have labview in my computer. can some one please open it and post a picture of both front panel and block diagram.
    It may not open properly, but that is okay.
    Thanks,
    Sujay.

    Here you go

Maybe you are looking for

  • Trouble compiling procedure

    I have the following procedure that I am trying to complile, logged in as TMMGR: CREATE OR REPLACE PROCEDURE UPDATE_TMS_LOAD AS v_err_msg VARCHAR2(150); CURSOR cur_load IS SELECT * from tmmgr.load; BEGIN FOR load_rec IN cur_load LOOP BEGIN INSERT INT

  • To find out the table which gives me the vendor no. to whom i pay brokerage

    Hello Everyone!       My question is,            In PO i have two different vendors... one vendor is the one from which we purchase goods and second vendor is the one to whom we pay brokerage. We mention the brokerage amount in 'ZBR0' condition type.

  • RequestDispatcher exception?

    Hi, Following sample code trying to forward a jsp page and pass a parameter to the next page String t = "test"; request.setAttribute("t",t); try{ RequestDispatcher aDispatcher = request.getRequestDispatcher("UnitScr.jsp"); aDispatcher.forward(request

  • Tutorial On Alv Grid...

    Hi All, Can you please Give me Step by Step Tutorial on ALV GRID. Thanks & Regards. yunus

  • AirportExpressON; no network detected

    Airport Express is working with green light but network is gone. It's not even listed as a choice. I've been using it since March and this week I cannot figure out what's happening. I've connected ethernet directly to computer to get online. I'd like