Why is diagram clean up corrupting my block diagrams?

A couple of times now (you'd think I would learn my lesson...) I've used the Clean Up Diagram option only for it to render my block diagrams completely unreadable. It's happened on two different systems now..
In this latest incident the flat sequence structure and the labels render as normal but the controls and constants are "smeared out" - for example, instead of being the usual small blue boxes the integer constants are rendered as very tall, thin rectangles. The data flow is completely impossible to discern. It's fascinating.
Anyone seen this before and know how to fix it?
Attachments:
reset_clock_frequency.vi ‏16 KB

I've seen something similar before and I believe this occurs when cleanup results in a block diagram that is larger than the maximum space allowed in the block diagram.  The VI you provided appears to go from ~-30000 pixels to ~+28000 pixels in the Y-direction, which is dangerously close to that limit. I'm not aware of any way to recover a VI once it's been saved in this state.
This KnowledgeBase article includes additional information on the maximum allowed size of the front panel and block diagram:
KnowledgeBase 3JEEP1ZH: Maximum Size for Front Panel and Block Diagram
http://digital.ni.com/public.nsf/allkb/62D66358BBF8A87186256FC50077FA17
Tom L.

Similar Messages

  • Block diagram out of... block diagram

    Hi, I need your help. Im the wrong person to this job, but I have to do this, so I'm dependent on your help. I need to explain how the LabView program (pasted below) works, but I don't understand it by myself I would like to ask if someone can create a simplified block diagram of the LV block diagram I paste in here. I would appreciate any help, and please take into considaration that I'm running out of time
    https://dl.dropbox.com/s/yd10z7yorxvbzux/LVdiagram.jpg
    It's a counter. Photon counter to be exact.
    Solved!
    Go to Solution.

    Hi Waise,
    I will try to explain you briefly what does this application do:
    Following materials might help you in understanding the concepts behind:
    http://www.ni.com/pdf/manuals/371022k.pdf
    This is the M series manual - the chapter 6.7 and 8 explains  how the digital lines work, the counter and what is a PFI.
    When you open the block diagram of your application you can see multiple branches going from left to write.
    The first one, on top is creating a path to a file. That path will be used to write data to a binary file. The data represents the number of pulses that are being counted as rising edges of a signal connected to counter 1. This information ca be read if you follow the logic on the second branch from left to right where the first VI is CI INT Edges (Counter edges), and it will count up, on rising edge of the signal connected to CTR1.
    Later, there is another task created for counter 3, that generates pulses. The pulses seems to have 10uS length and 50% duty cycle. The signal generated by that counter will be used as sample clock for the measurement and counter 1. Also, the same signal from counter 3 will be used by counter 4 to count the digital edge and create a clock that will clock the timed loop. Basically the frequency of the timed loop is given by the task on Counter 4 that counts the pulses generated with counter 3.
    The 3rd branch from left to right, creates three tasks on three digital output: Line 0, 1 and 2 where it is being controlled by three buttons F0, F1 and F2. Basically, your timed loop will have a specific iteration time, and with every iteration the buttons will be read and will update the digital output specified above.
    Whenver there is an error or the Stop button is being pressed, your application will stop and will close the binary file and dealocate the used resources.
    I invite you to look also in the manual specified above.
    Best regards,
    Ion R.
    Attachments:
    printscreen 1.png ‏178 KB
    printscreen 2.png ‏183 KB

  • Unresponsi​ve block diagram

    When I run my VI, a traditional State Machine, I cannot use any of the buttons on the block diagram toolbar, or probe the block diagram. Nothing on the block diagram is accessible, so I opened each state in a separate VI to see if the problem followed, but it goes away. This issue seems to only occur with this particular VI, but I have no idea how to troubleshoot it. I am currently running 8.5. Thank you.
    Solved!
    Go to Solution.

    NIPEN wrote:
    Seems that my FP was modal not default, which caused all my problems. Thank you very much to those that tried to help me.
    That makes some sense.  Modal FP means that no other LabVIEW window will be allowed to get focus unless the window is minimized.  Hence, although your mouse can move over the BD you get no clicks just bongs.  Thanks for posting the solution!
    Jeff

  • How to build cepstrum analysis block diagram and validating ?

    hello all.
    intoduce, i'm hogeng. i'm a newbie in using LabVIEW to vibration analysis (faults diagnostics).
    how to build the cepstrum analysis block diagram and validating the cepstrum block diagram?

    the advanced signal processing toolkit for LabVIEW provides cepstrum functions and examples.  These are also described in the manuals on line for the advance signal processing toolkit as well as on several developer zone documents.  Simply search ni.com for cepstrum. 
    If you need help analyzing a vibration signal with cepstrum, our sound and vibration team may be able to review a data file to assist you.
    Preston Johnson
    Principal Sales Engineer
    Condition Monitoring Systems
    Vibration Analyst III - www.vibinst.org, www.mobiusinstitute.com
    National Instruments
    [email protected]
    www.ni.com/mcm
    www.ni.com/soundandvibration
    www.ni.com/biganalogdata
    512-683-5444

  • Corrupt Block Diagram With Infinite Wires

    Hi,
    Has anyone every seen a corrupt Block Diagram as shown in the pic? Almost all my wires have stretched to infinity!
    I used "Clean up wire" on these wires, but that did nothing.
    Ironically, the VI runs -- but I can't develop further with the BD in this state.
    Any ideas, please
    THANKS PEEPS!
    Attachments:
    Screenshot 2015-03-26 18.16.56.png ‏78 KB

    There is a maximum size that the BD or FP can be.  If you are getting close to that size and the cleanup tries to make it bigger odd things can happen.  This might explain why nothing happens when you try to clean it up.
    http://digital.ni.com/public.nsf/allkb/62D66358BBF8A87186256FC50077FA17
    Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
    If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

  • 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

  • Why Is the Block Diagram Disabled?

    What did I do now?  Please look at the attached image.  A VI that I am using as a subVI in various different programs suddenly started looking like I had used application builder to create an exe file out of it (But I didn't!!).  The only options are Start and Run Continuously, and the block diagram is disabled.  What did I do to get myself in this mess?  How do I undo whatever I did, so I can edit the block diagram again?  Any help or suggestions would be greatly appreciated.
    Thanks!
    Solved!
    Go to Solution.
    Attachments:
    Disabled Block Diagram.png ‏259 KB

    Did you ever built a source distribution with the option set to remove the diagrams? In this case, the original must still be around somewhere.
    Since LabVIEW 8 you can no longer simply save without block diagram and you would not be able to upgrade such a VI to LabVIEW 2011, which it is now. (details)
    Of course it is possible that there is some corruption, but looking at the memory usage, the block diagram is blanked out.
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    NoBlockDiagram.png ‏38 KB

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

  • Corrupt block diagram

    Hi all,
    I have a VI which is able to open and I can even start the front panel, but when trying to open the block diagram, the screens stays white and Labview crashes.
    Is anybody able to open the block diagram of this file?
    Thank you in advance>
    Greetz, Bart
    Attachments:
    main_v_0_0_1.vi ‏165 KB

    Saved for LV2012
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome
    Attachments:
    main_v_0_0_1.vit ‏113 KB

  • Why does my block diagram change when I copy my code to another system?

    I am doing development work on a laptop on Win XP and using LabVIEW 2009 with service pack 1. When I copy the code to the target system, my block diagrams are changed and no longer fit the screen. Much of the code is spread out, mainly down. The target system is running Windows 7 and also has LabVIEW 2009, SP 1.
    I notice that any constants that are clusters are expanded when copying the code to the other system. I've gone in and turned off the autosizing for these clusters but they are still expanded. I like to shrink them to a small size for saving space.
    I've gone through and manually re-adjusted the block diagram on the target system, but when I copy it back to my development laptop, the same thing happens again. This is not an acceptable way to develop code and it has caused a real problem to proceed. I'm contracting this work and must develop this code offsite. Can anyone please help me with this? I can't keep restructuring my block diagrams every time I copy the code from one system to the other.

    Windows XP used Tahoma size 8 as its basic system font.  When MS came up with Vista, they changed it to Segoe size 9.  I'm not sure what Win 7 is, but I think it is the same as Vista.  That font change, and certainly font size change seems to be the underlying cause for block diagrams changing their appearance.  (And for front panel controls and labels as well.)
    LV seems to use the Windows system font as its default font.  Interestingly, it seems like the font sizes in LV are something like size 12, 13, 14, 15.  I think a size 9 is equivalent to a size 15, but I'm not sure about the comparisons.  (Check out this thread.)
    There are a few things you can do to try to make one system look more like the other.
    1.  Go into the Windows screen settings. In Vista, right click desktop, Personalize.  Window color and appearance.  Open classic appearance properties.  Try changing the color scheme from Windows Aero, to something like Windows Classic or Windows standard.  They both use Tahoma 8.
    2.  Or same as Step 1, but go further into Advanced button.  Pick on any option that uses font such as Menu, Message Box, Active or Inactive Title Bar and change the font there.  I'm not sure which of the items that has a font setting is the key one.
    3.  LV uses 3 fonts called Application, System, and Dialog.  I think each of those map to one of those Windows options, but I'm not sure which goes to which.
    4.  In LV, Tools/Options/Environment has a subsection called Fonts.   Those 3 basic LV fonts are selectable there.  There is also a checkbox for me which is checked and says to use default.  If you uncheck that checkbox, a Font Style button becomes enabled.  You go in there and you can choose fonts and sizes.  And the Application, System, and Dialog fonts as well as all the usual fonts names (Arial, MS Sans Serif, Greek, ....) are selectable along with fonts sizes.  Play around in there.  The whole section is very confusing, and I have no idea how it works.  I recommend going to this idea A better way to specify (default) fonts and putting in a vote.   Also this idea, Fix font behavior between windows versions, platforms & executables, deserves some love.
    5. Some of these settings can also show up in your LabVIEW.ini file.
    FPFont = "0" 15
    BDFont = "0" 13  (I think the "0" means app font, "1" means system font, and "2" means dialog font)
    Also,
    appFont="Tahoma" 13
    systemFont="Tahoma" 13
    dialogFont="Tahoma" 13
    (And if necessary, put these in your built application's .ini file)
    As you can see, there are a lot of different things going on and they also seem to conflict with each other.  I starting stumbling on the block diagram issue between working on my app on XP at work and on my Vista machine at home about 6 months ago.  I think my problem actually started with the front panel when I was trying to align labels, and use some arrow head decals on boolean buttons.  I think I did the customization of buttons in a couple different ways (because I did some, came back later to do others, and couldn't remember exactly how I did it.)  As a result some decals looked different than others when I changed machines.  And I swear going from XP to Vista, or Vista to XP the problem got both worse ways rather than let's say larger one way, and smaller the other way.
    Replying to your message is about as much to me trying to combine all the pieces of knowledge I've stumbled across over the past months and year as it is for trying to help you.  Hopefully, this information gives you some places you can look at and play with.  (I bet #1, would be a quick, easy way to solve your immediate problem, but I haven't really tried it myself to be sure.)
    I hope someone from NI who has a better understanding than me about these font issues could jump in and correct any mistakes I made, or add anything I might have left out.  What we really need is some sort of "nugget" or National Instruments white paper that really explains all of this in ways we can use rather than us stumbling around in the dark doing things trial and error to figure it out.  Generally, any changes to the .ini files require you to shutdown LV and restart it to take effect which can take a couple minutes.  And considering all the various combinations of things that can be done above, your talking about dozens of possible restarts, and sending .vi's between two different PC's with two different operating systems, before figuring these things out.

  • Why do I get an Error Code 70229 when running Block Diagram ?

    Hi everyone,
    This error is very weird because at one time I got the block diagram to run and it worked well then when I tried it again after reopening the block diagram I got this error . 
    Can someone help me please ?
    I am using SolidWorks Premium 2014 x64 Edition.
    The attached files show the version I got for SoftMotion and for Labview 2013 32 bit installed . 
    PS. I had Labview 2013 64 bit installed but I removed it. not sure if any files remained that may cause this...
    Thank you,
    Isaiah 
    Attachments:
    Softmotion.JPG ‏54 KB
    Labview2013.JPG ‏55 KB

    Read related topic
    Thank you & Best regards
    syrpimp
    =======================================================
    “You must continue to gain expertise, but avoid thinking like an expert." -Denis Waitley

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

  • Group block diagram objects

    I'm almost certain this question has been asked before, but my searches are coming up empty-handed.
    Why is it not possible to group objects on the block diagram?  I'm using 8.2.1, so if this has been implemented in a later version, you have permission to slap my wrist and send me to the corner for not paying attention.
    I think I recall the option being discussed in conjunction with the new "block diagram clean-up" feature of 8.6, but I think the general tone of that was that it would be cool to group objects and have them treated as a single object when cleaning up the code.
    I have some code which is generating a lot of user events, and when changing datatype (Typedef) it happens that I need to re-arrange things so that nothing is overlapping.  This is a right royal pain without being able to group the event data constant and the create event node together.......
    Shane.
    Say hello to my little friend.
    RFC 2323 FHE-Compliant

    livermor wrote:
    Has this been achieved yet?
    If you like this idea you should suggest it on the idea exchange board.
    Personally I don't really know how often I would use this, or find it useful but others might.
    Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
    If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

  • LabVIEW exits while editing block diagram unexpectantly

    Hi all, while editing block diagram in LabVIEW 2010, I have experience some strange behaviour from the software. I have two monitors, one has the front panel of main VI and the other - block digram of the specifed VI. When I switch from block diagram to front panel, and vice versa, every now and then the LabVIEW exits unexpectantly without the notice. Upon restarting the program again I get the undo.cpp error. I have attached the error log for my clarification on the type error that I am dealing with. Does anyone have any ideas why this is occuring? Thanks in advance for your help.
    Viktar
    Attachments:
    lvlog2010-09-17-09-35-46.txt ‏2 KB

    Thanks for all the responses. 
    I was using an existing VI as template to create a new program.  There were nested loops in the original program and I needed the logic for the outter loops only for the new program.  After deleting many objects in the 'yes' case in the inner loop, I was left with many loose wires in the 'no' case.  And that's when my problem started, when I was trying to delete them.  Yes, I tried rebooting my PC and that did not help.  The problem seemed to get progressively worse, as crashing started to happen even when I was only selecting a wire.  But somehow I was later able to select one wire, delete it, and did a save.  Then I went to the next wire, and so on.  My program is now cleaned up and I'm ready to go on.  I will experiment more when the problem returns. 
    Thanks again.

  • Error cluster constant appears different in two locations on a block diagram

    I am a newbie to LabVIEW. I have taken Core 1 & 2 and Machine Vision and I have not com across this before.
    The image on the right is obviously an Error cluster constant used in the block diagram to create an Error cluster and wire it to an error out terminal. As far as I can tell the image on the left is about the same thing, but why does it look different? The different appearance causes raises a concern that there is a difference in behavior that I do not understand. LabVIEW help suggets that both are Error constants. When I create a new error constant, it always ends up appearing like the right image above.  I have not been able to create someting looking like the image on the left.
    Could someone please confirm what the image on the left is on a blck diagram?
    Thanks,
    Bill
    Solved!
    Go to Solution.

    The image on the left is an error cluster control. It has a front panel presence and can be set either via the front panel or through a property node or local variable. The image on the right is an error cluster constant. It is a static value.
    Mark Yedinak
    "Does anyone know where the love of God goes when the waves turn the minutes to hours?"
    Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Maybe you are looking for