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

Similar Messages

  • 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.

  • Storage VI blocking on front panel interactio​n

    For some reason that I can't figure out, the "write data" storage vi (and perhaps others) will block during
    front panel interactions. For instance clicking on a ring button will block until you select something.
    The button doesn't have to be on the same VI either. Also editing a separate VI, when you right click
    and start looking for the right function in block mode or widget (I forget the labview term) in the Front Panel, 
    will block the write.
    The problem with this is that my main program is saving data from a ring buffer, so if someone takes
    too long making a selection, I've lost data. I attached a VI that can demonstrate the bug
    (at least on what I can try it on). I've gotten the attached VI to work with labview 8.0 and labview 8.0.1
    Attachments:
    Storage Vi Bug.vi ‏42 KB

    Hello,
    Thank you for posting this well written description and
    great small example which reproduces the problem!  This seems to be only occurring with the
    write data like you mention.  I’m not
    exactly sure the cause, but I filed a bug-report on it (3ZNC2Q3A), so we can
    investigate here.  I’m betting it has
    something to do with user interface interactions between the controls and the
    write measurement file VI, as components from each could run in the UI thread
    and block each other.  Unfortunately, I
    don’t see any immediate workaround without having to change a few things up
    with your program structure.  For example,
    instead of a ring, you could just have one or two checkboxes for the options
    and see which the user has pressed.  Because
    the write file VI is the only one that is blocked, you could conceivably separate
    your data acquisition thread and your file IO thread (many times it’s a good
    idea anyway).  Using the Queue datatype,
    you could add all the data to the queue in the non-writing loop, and write to
    file in the separate file IO loop.  If
    the write to file blocks the data will continue to queue and no data will be
    lost.  This is known as a
    producer/consumer VI design pattern. 
    Your consumer would be the file IO portion of your code.  Check out the tutorial of this structure here.
    Are these alternatives acceptable?  Unfortunately, with the way the write VI
    interacts with the user interface thread I don’t see any way to avoid this
    problem.  I apologize for any problems
    that have occurred as a result of this behavior.
    Travis M
    LabVIEW R&D
    National Instruments

  • New monitors resolution effects on block diagram

    I recently got a new PC from IT with quad display outputs.
    I got new monitors with different resolutions from the old monitors I was using.
    Has anyone noticed when opening old projects on a new display that the block diagram layout becomes a lot different ?
    For example, look at the attachment, look how large the "Bundle by name" box is, and how it has consumed all objects around it.
    Solved!
    Go to Solution.

    Did you go from a PC that was running WinXP to Windows 7?
    The default system fonts for Windows 7 are a size larger than the WinXP fonts.  And generally LabVIEW uses one of the system defined fonts on the block diagram.  (Also, on the front panel.)  So when you make the change from XP to Win7, everything looks larger, and stuff that was lined up neatly before is no longer lined up and can overlap.
    Search the forums for Win7 fonts.  There are several threads that discuss this.  You can add some items to the LabVIEW.ini file to define the block diagram, front panel, and the system, application, and dialog fonts to be related to a specific font rather (such as Tahoma 8 in XP, rather than the windows defined font which changed over to Segoe UI 9 on Windows 7.

  • What VIs do not have block diagram?

    Hi,
    I'm studying for CLAD and theres a question in the CLAD Topics details about what VI do not have block diagram?. I read in help that polymorphic VIs don´t have Diagram Block or Front Panel ( Labview help / Creating Sub_VIs). However, I can see that if I make double click in  a polymorphic VI, for example,  Read Key.vi or DAQmx Timing.vi they have front panel, moreover, they have a diagram block, so I am missing about that......
        I know too that VI express do no have diagram block or front panel, the have a configure window. If I select open the front panel option,  the VI express changes to Sub-VI and I have access to front panel or block diagram. So I think VIs express are those VIs that do not have diagram block. Am I right?
     Anyway, there a doc or paper that give me information about this topic?
    Thanks for the anwsers....
    Solved!
    Go to Solution.

    The fact that controls have the .ctl extension does not mean that they are not a VI. You could rename a .ctl file to have a .vi or .caribbean extension and it would still work the same.
    LabVIEW considers them to be VIs and displays then in the All VIs in Memory property and other places.
    Incidentally, looking at the help for the VI Type property shows the following:
    Indicates the type of VI. Invalid VI type, Standard VI, Control VI, Global VI, Polymorphic VI, Configuration VI, SubSystem, Facade VI, Method VI. LabVIEW returns the invalid VI type value for invalid VI references.
    LabVIEW returns the SubSystem value for subVIs for the LabVIEW Control Design and Simulation Module that you can place only on a simulation diagram.
    The Configuration VI type is not supported.
    The last two are both used for XControls and both have diagrams.
    Try to take over the world!

  • 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

  • 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

  • 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.

  • 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

  • How do I automatically make new front panels and block diagrams a certain size and screen position, like able to fit on a 1024 x 768 screen?

    I'm studying for the CLD and I notice that one of the requirements is this:
    Develop block diagrams to fit a screen resolution of 1024 x 768.
    When I create a new VI, its resolution is slightly too big: 1110 x 768.
    When I create a subVI via the menu item Edit >> Create SubVI, it is way too small: 800 x 543.
    For both methods of creating new VIs, I would like to specify both the screen position and window size. But if that is not possible in LabVIEW, I'd like a quick way to make this happen. I see some property nodes for VIs where I could write a subVI that could do this for the front panel, but that is awkward. And it does not apply to block diagrams.
    Is there a clever way to do these things?

    bmihura wrote:
    I'm studying for the CLD and I notice that one of the requirements is this:
    Develop block diagrams to fit a screen resolution of 1024 x 768.
    When I create a new VI, its resolution is slightly too big: 1110 x 768.
    When I create a subVI via the menu item Edit >> Create SubVI, it is way too small: 800 x 543.
    For both methods of creating new VIs, I would like to specify both the screen position and window size. But if that is not possible in LabVIEW, I'd like a quick way to make this happen. I see some property nodes for VIs where I could write a subVI that could do this for the front panel, but that is awkward. And it does not apply to block diagrams.
    Is there a clever way to do these things?
    It doesn't mean the default size of the window. It means once your code is complete, your block diagram should be small enough that you can see all your code when its on a monitor of that resolution. Before you test, set your computer monitor resolution to 1024x768. Write your code. If all the code on your block diagram can be seen without scrolling, you will be fine. They won't measure this explicitly. They are basically just saying "you shouldn't have a huge block diagram."
    CLA, LabVIEW Versions 2010-2013

Maybe you are looking for