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

Similar Messages

  • 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

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

  • 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

  • Problème de blocage écran block diagram et front panel

    Bonjour,
    Je ne sais pas pourqoi, après avoir chargé Labview 2013 (après avoir utilisé LabVIEW 2012 SP1), dès que j'ai un block diagram ou front panel sur l'écran, je n'arrive plus à les manipuler après la première action.
    Pour y arriver de nouveau, il faut que je réduise toutes les fenêtres LabVIEW puis que je réactive celle qui m'intéresse. Je peut alors faire une seule action puis il faut que je recommence l'opération de réduction-agrandissement.
    Où est l'erreur, dans Windows (7), dans LabVIEW, dans une commande qui s'est mal faite ?
    Le problème ne se résouds pas si je redémarre mon PC.
    Peut-être faut-il que je désinstalle et que je réinstalle tout.
    Quelqu'un a-t-il déjà renconté ce problème ?
    Merci pour vos réponses.
    JPV67

    Bonjour et merci pour votre réponse.
    J'essaie de me dépatoiller de ce problème avec l'aide du service support [(Reference#7411882) Phone Support E-Mail].
    Malheureusement l'opération de désinstallation et de réparation qui m'a coûté 4h n'a pas abouti car j'ai toujours le même problème.
    Pour simplifier cela commence par ça :
    c'est l'écran d'accueil de LabVIEW.
    Si j'attends quelques instants avant de cliquer sur CLOSE de la fenêtre WELCOME to LabVIEW, je ne peut plus le faire !
    Même l'activation de la croix X de fermeture de cette fenêtre ne marche pas !
    Pour y arriver, il faut alors que je réduise cet écran puis que je le restaure et seulement alors je peux fermer cette petite fenêtre !
    Par ailleurs j'ai ce phénomène :
    Je ne sais pas pourquoi, après avoir chargé Labview 2013 [Version 13.0.1f2 (32 bits)] sur Windows7, après avoir utilisé LabVIEW 2012 SP1 sans problème, dès que j'ai un block diagram ou front panel sur l'écran, je n'arrive plus à les manipuler après la première action.
    Pour y arriver de nouveau, il faut que je réduise toutes les fenêtres LabVIEW puis que je réactive celle qui m'intéresse. Je peut alors faire une seule action puis il faut que je recommence l'opération de réduction-agrandissement.
    J'ai en fait le même problème avec la page d'accueil de LabVIEW qui devient inactive après la première action.
    Cela se produit sur le PC fixe.
    J'ai une licence site Université qui a été enregistrée.
    En espérant que vous aurez une solution...Cordialement,
    JPV67

  • 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

Maybe you are looking for