Subvi daq loop ni a calling vi

Hi!
I have a vi that contains an event case structure which aquires data in an event driven way from a hardware. It is implemented via a DLL, and thus the DLL have to be initialized first. These init and DAQ parts are done in a flat seq. structure, so they follow each-other.
I need to place this whole thing in an other vi like a subVI. This other vi would display the incoming data, therefore it will contain a while loop. I would place my subVI in this while loop, so that it would give data continuously to my display event-drivenly. But in this way it would initialize every cycle.
So my question is, thet how should i solve this? I have seen such vi-s, that have more instances and there is a input param that i can choose, like "init", "write", "read". I would like something alike, or it is not the best way to do it?
Thanks:
Waszil

By now I have answered my question, i separated the tasks to 3 vi-s, so now it works fine. Sorry for tha flame.

Similar Messages

  • DAQ Assistant in subvi not updating output to DAQ board with each call...

    Hi All,
    I am calling a simple subvi that creates a user-defined number of pulses with "Square Waveform.vi."  This square wave (with the given total number of pulses) is then used as an input to a DAQ Assistant controlling an analog output signal on a NI USB-6259 DAQ board.  I am using Labview 8.5 right now.
    However, each time I call this subvi from my main program, the output I measure from the DAQ board is identical to whatever I set in the first call (i.e., if i created two pulses in the first call, I get two pulses on every call, regardless of the input I feed to the subvi).  The multiple calls to this subvi are made in sequential frames in a stacked sequence.  I believe stacked sequences are frowned upon by good labview people, right?  But putting that aside for the moment...
    The "#-of-pulses" input I give to the subvi is updated in a subvi front panel number indicator and a graph of this waveform.  Just not in the real output I measure from the board.  Why is the hardware output being asserted (with the original input value) before this new number can reach the DAQ Assistant?
    The sloppy fix to this is just to put that square wave creation code in my main program each time I need it.  This does work and fixes my problem.  However, I would like to use subvis to keep things clean.
    I am not a good Labview programmer, but have used this software for a number of projects and am stumped by this.  Any ideas?
    Thanks,
    John

    Hi John,
    I am running your code over here and seeing
    the same results.  I believe the problem is that the DAQ Assistant is
    being called inside a loop (really a sequence structure, but
    nonetheless more than once).  Sometimes it is difficult to troubleshoot
    the DAQ Assistant in cases like this--it is trying to be "smart" and
    seems to be avoiding re-configuring its parameters inside the loop. 
    This is intended to improve loop speed for when customers are
    performing continuous operations.  In this case, it is performing a
    finite generation, and the number of samples generated appears to carry
    over from one loop iteration to the other.
    It sounds
    like you have discovered one workaround for this already: putting a DAQ
    Assistant in each frame of the main VI.  Two other options that come to mind are:
    Use the lower-level DAQmx functions inside
    the sub VI.  Here you will have explicit control over when the task is
    created and cleared, and when parameters are set.  You can find
    examples of how to use the DAQmx API in the Example Finder at:
    Help >> Find Examples... >> Hardware Input and Output >> DAQmx
    Write
    a consistent amount of samples to the DAQ assistant by "zero-padding"
    your signal.  For example, instead of writing [10, 1010], try writing
    [1000, 1010].  In this case, it wouldn't need to reconfigure the number
    of samples to generate.
    One lesson to take away here is
    that the DAQ Assistant is good for basic functionality, but for more
    advanced control over the execution and configuration of your task you
    should learn to use the lower-level DAQmx functions.  In this case it
    sounds like the problem is actually a bug.  I'll file a bug report, since the DAQ
    Assistant is not checking for waveform timing changes even though your
    timing is set to Use
    Waveform Timing.
    Thank you for pointing out this odd
    behavior--out of curiosity which version of DAQmx are you using? 
    -John
    John Passiak

  • SubVI DAQ

    Hi! I'm building a data acquisition system using LabVIEW and an old
    ATMIO16E2 card. It is basically a collection of subvi's, each of which can
    and may be run independently. The main vi just controls the priority and
    timing of these subvi's and displays important inputs. Each subvi contains
    daq vi's (some of the daq vi's, eg wave acqui, are common to more than one
    subvi). They are all intermediate vi's and the iteration and clear terminals
    are controlled from the main vi. The problem is that the main program
    executes once with expected values from each subvi but then all acquisition
    go to zero. This is obviously a problem with daq vi initialisation. I tried
    re-initialising each daq vi on every subvi call and that works fine, but too
    slowly for my l
    iking. I was wondering whether it was a problem with
    re-entrancy (because of common vi's in separate sub vi's). Is there any way
    of solving it without saving each daq vi under another name? Is it possible
    to keep subvis open after the first call, hence making re-initialisation
    unnecessary? Any help would be appreciated.
    Leon

    If everything is being read at the same rate, make a single DAQmx task to read all of the channels in one shot.  In your case, that would be a single DAQ Assistant that has all of the channels.  Since your rates are fairly slow, you should be able to do everything in a single loop.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Update a front panel indicator from a loop inside a called vi. Without exiting

    I am looking for the best way to update some indicators from within loop within a called .vi.
    I need to update the front panle without exiting the loop.
    I am able to use functional global vi to update the values of front panel indicators from within my nested loops, but I am looking for the best way that these values can be read to update my indicators.
    Thanks

    Or a cluster of references, that way each reference can be named, and can be different types to match the respective indicator.
    There are also methods where you can just send in a VI reference, and in the subVI traverse all the controls and search for the appropriate references by name.
    Take a look at this long nugget.

  • Subvi flashing on screen when called

    Hi All,
    I have a subVI flashing up on my screen when called even though I have
    all options unchecked on the subVI properties box (from the calling
    VI). I have a sneaking suspicion it is something obvious. Any ideas?
    Thanks,
    Greg

    Hi,
    Have you checked the show "Front Panel When Called" and "Close Front Panel
    When Loaded" check boxes.
    Regards,
    Wiebe.
    "Greg Cole" wrote in message
    news:[email protected]..
    > Well, I learned something new there with the hierarchy screen at
    > least. Thanks.
    >
    > Problem still remains though. No breakpoints found and all options
    > are unchecked in the subVI properties dialog.
    >
    > I have 2 graphs in the subVI that flashes. That should not be the
    > cause though, correct?
    >
    > Greg
    >
    > Ben wrote in message
    news:<[email protected]>...
    > > Another thought;
    > >
    > > Goto the hierachy screen.
    > > Do ctrl-f
    > > select objects
    > > right click on selec
    t object>>>other>>>breakpoints
    > >
    > > do the search.
    > >
    > > You may have a break point set.
    > >
    > > Ben

  • How can I make a control inside a loop in a subVI change value when the calling VI's control changes?

    Hi.
    I think this is a pretty basic LV question, but I have not been able to find a good solution.
    I am attaching VIs that show the problem I am having, but obviously, the real application is a lot complicated, which forces me to try to do it this way.
    The issue is: I have a subVI with a Boolean control inside a loop.  When the control is true I want some action to take place.  When the subVI is run on its own, it works fine, acting properly when I set the boolean control to true via the LV FPGA interface from the host.  However, when I use it as a subVI, in which the top-level VI calls several instances of the subVI, I have the Boolean controls in the top level VI.  What is happening is that the false Boolean value with which the top-level VI starts is passed into the subVIs, and not updated, even though the control is inside the loop.
    Can any one suggest a good solution?
    Thanks,
    AlejandroZ
    Attachments:
    CallingVI.vi ‏7 KB
    subVI.vi ‏8 KB

    Hi.
    I know the example I posted might seem silly, but it was just to illustrate the problem I am having.  In reality this is the application:
    I have some LV FPGA code which uses a few FPGA IO to implement a serial link to communicate with a device.  Most of the time we are getting data from the device, so the serial link is used to send a read command, read in the data and put it into a FIFO.  However, I also wanted the VI to support sending data to the device, so I added an array control to put the data you want to send, and a boolean control to tell it you want to send it.
    Since sending and receiving data are done using the same FPGA IO, they cannot be independent operations, because they would garble each other. Therefore, in the subVI I have a loop in which I first read data if there is any to read, then check the boolean write control to see if there is data to write.
    As I mentioned, this works perfectly for talking to a single device.  However, we run into the issue of this topic when trying to replicate this for several devices.
    One easy solution is to not have the loop in the subVI, and have it in the calling VI (I am favoring this simple solution right now).  The only reason why I have not done this yet, is that the subVI has more than one loop, so I am going to have to create several subVIs.  I just posted to see if there was an even simpler solution...
    There have been some other possibly good solutions proposed here, though I am not sure if they work in LV FPGA.
    Thanks for all your responses.
    AlejandroZ

  • LabVIEW RT, Timed loop, finished late, Call by reference

    I have a timed loop triggered by the sample clock of a DAQ-Card. The sample Clock is 8 kHz and the loop will run with dt = 4. Normally the loop is running without finished late[i-1]. But from time to time it happens that the loop is running extremly longer which means instead of 0.5 millisec it needs 4 - 5 millisec. It seems this doesn't never occur while accessing DAQmx.
    The application uses plugin technologies and some of the VIs in the timed loop are preloaded and called by Call by Reference.
    Does those VIs inherit the priority, execution system and CPU of the timed loop?
    The application is running on LV RT 2009 on a Dual core PXI-Controller. The timed loop is bound to CPU 1. There is no  difference runinng the application from the development environment or as a startup application.
    For the measuring test  I modified the application in a way that I don't have:
    disk access for storing the result file
    TCP/IP communication
    Controls on the front panel of the top level VI
    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

    To keep you informed:
    I stripped the application and have left only the measurement storing module and the timed loop. The loop was using the microsecond timer running each 500 µsec. Additional all Non-Real-Time modules were loaded and only one module creates a XML string and sends it to the communication layer which will drop it because no TCP/IP port is open. The creation of the XML string is done each 300 ms.
    In this case I don't have any finished late iterations
    Next I added the DAQ Module. Now I get finished late again but with a lesser frequency as original.
    I removed all unnesseccary tasks from the DAQ moulde leaving one task for a PXI-4204 for using as the clock source for the timed loop. No I get finished late seldom.
     I removed the module which will send the XML string and I don't get finished late.
    Next I was adding code to see memory allocation. I can when memory allocation is changing but it is not related to the finished late iterations.
    Next time I have the chance to do more tests I will see which DAQ task triggers the finished late iterations. I have one AI task on a PXI-4204,  4 Counter tasks on a PXI-6602, 1 DI task on a PXI-6514, 1 DO task on a PXI-6514, 1 DI task on a PXI-6259, 1 DO task on a PXI-6259, 1 AO task on a PXI-6259 and 1 AO task on a PXI-6711.
    The AI task on the PXI-4204 is running in Continous Sampling (Single Point HW Timed is not supported), all other tasks exept the DI and DO are Single Point HW Timed.
    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

  • Is it possible to run a subVI in parallel with the caller VI?

    I have a front panel VI which calls numerous subVIs, one or two of which I would like to execute simultaneously with the calling VI. The front panel has time-dependant operations which are being prevented from running because it is waiting for the subVIs to finish, even though no data is required from them.
    Is it possible to call these subVIs such that they run silently in the background allowing the front panel to execute unhindered?
    I've looked at the Synchronisation features but is this what I need?

    shoneill wrote:
    > It's also very important to mention that the whole multi-threaded
    > execution CANNOT be reliably observed in highlighting mode in the
    > LabVIEW development environment. You need to let the VI run
    > full-speed to see this.
    >
    > Highlighting (to the best of my knowledge) forces single-threading, or
    > acts like it does.
    This is simply a convinience by LabVIEW since humans are inherently
    non-multi treaded. What you will see in parallel loops and which can
    still be distracting is that LabVIEW seems to randomly switch between
    different parts of your diagram. In fact this is also what is happening
    in normal execution but the execution switch is so fast (each individual
    operation typically taking microseconds it
    seems they execute in parallel.
    The nice part of LabVIEW since version 2.0 somewhere around 1988 already
    is, that it provides this seemless multithreading on every single
    platform even if the underlaying OS is not multithreading capable at all
    (Win3.1, MacOS).
    Rolf Kalbermatter
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Adlink daqpilot not working in subvi (DAQ/PXI-2204)

    Using DAQpilot from Adlink
    in Labview 2010 / windows 7
    I want to do n-channels, n-scans, single shot in a while loop
    The configuration is as follows: (see also attached task)
    -installed device: DAQ/PXI-2204:0
    -n-chs: 0-31 differential
    -10.000 Hz
    -30.000 scans
    -scaled data in 2D array
    The DAQ pilot runs once and continously in a sub vi:
    It also works when I place the task in a loop.
    But when I use it in a sub vi which is called from another vi in a loop it work the first cycle and the second not, third ok, fourth not. see diagram below:
    following error message:
    Attachments:
    test_3.vi ‏67 KB
    while_loop.vi ‏13 KB
    tset3.zip ‏4 KB

    Hello!!!
    You do not need to put the "Configuration Parameters Setting" inside a loop.
    These configuration are needed just one time.
    If you want to change these parameters for other acquistion, you can put these steps inside a case structure and when you need to change those configurations values you've just to call the "Configuration Case" and do it before the new acquisition starts.
    The acquisition need to be continuous, not the configuration.
    You can found code examples on this link below:
    www.ni.com/code
    Hope this helps,
    Regards.
    Barbara Pracek
    Engenharia de Aplicações
    National Instruments Brasil

  • Subvi in loop not working

    Hallo everyone,
    I just experienced a weird problem. (For demonstration, I attached a minimal configuration):
    If I run the min_demo_example.vi, it should tell me if the terminal is connected or not. It works great, when I just put the subvi “test_terminalconnected.vi” as it comes.
    The problems begins, when I put this subvi in a loop (don’t matter which, can be for, while, case, event,…).
    I really have no idea why. Either there is something very obvious or I’m just too dump.
    Would be very nice if someone could help me.
    Regards

    No.  I'm not going to rebuild any reference.  I think the VI basically worked the way it was programmed, and the problem is with the programming just like Bob was talking about.  I was seeing one or more errors related to your program, not to the structural integrity of the VI itself.
    To clarify Bob's point, the subVI is still a subVI.  If the subVI is on the main block diagram, then you can find it within the array of nodes that are on the block diagram.  If you have the subVI in a structure, then the structure is a node on the main block diagram, the subVI is a node within the block diagram of the structure.  You aren't going to find the subVI referenced in the array of main block diagram objects.  Your block diagram is actuall a tree of objects with items on different branches depending on whether they belong to higher level structures or not.
    There is a VI called Traverse for GObjects with iterates through all the branches of the tree and returns references to the objects.  You may find that useful to use.  You can find the Traverse if you search or start typing it into the Quick Drop window.

  • Subvi parallel loop terminatio​ns

    Hi all,
    I have multiple parallel loops (all in subvi).  What do you think is the most elegant way of implementing a clean user termination for all of the parallel loops inside subvis?  I want to hear what you think.  Thanks!
    Kudos and Accepted as Solution are welcome!

    Generally a local variable shoud be enough.  But there are a few more questions.  Is the front panel being opened when the subVI is called?  What is the condition where you want the subVI to stop?  Is it based on some data, a user interface action?  What does the subVI do?  Why do you have a loop in a subVI?

  • Using Control Reference to change subVI control - sub VI also called using a container

    Hello
    I am in need to update a control inside a sub VI that is also called inside a container in the main VI.
    Please see the project attached.
    My goal is simple -
    Change the "Main VI calling sub VI-Container.vi " panel's "FGV state"
    once the state changes, it needs to be propagated to the sub VI that is called within the container
    The sub VI's (sub VI called is "Check Time FGV.vi")  "FGV state" also needs to change when the main front panel's control
    How do I accomplish this ? just a FYI - the sub VI being called is at "C:\Projects\User Examples\Check Time with FGV\Check Time FGV.vi"
    Also my stop button functionality is broken, not sure why.
    Thanks for your help.
    Attachments:
    Check Time.lvproj ‏6 KB

    OK you have a few problems.  Lets address the Stop button first:
    Add a value change event for the stop button and put the stop button in that case.  Wire the button out of the event structure to the conditional terminal of the while loop.  WHAT IS HAPPENING:  You press "Stop" but the event structure is still waiting for an event so the loop never iterates.  Get rid of the wait.  the CPU will not be hogged unless you are generating events at warp speed.  No user can generate events that fast! so the loop will not be greedy.  The event structure does wait for an event it does not poll for them by running contineously.
    Now your subpanel.  You do know that the FGV runs once when you invoke the run method on it right?  You can change the contol value all you want but the vi won't do anything about it because the vi is not running.  And even if the vi WAS running changing the value of a control that is read once (outside the loop) would not cause the value on the wire inside the loop to change at all.  Does that clear up some of why what you are attempting will not work like that?
    Jeff

  • Make a subVI do something on first call

    Hello,
    I have a SubVI I made and I want it to do one thing the first time it's called and then as long as the program is running it should do another thing.  Right now I have a  "First Call" function wired to it, and that passes it a tru the first time my SubVI is ecounterd and a flase every other time... this works... but I was wondering if there is a way to do this from within the subVI itself?
    Thanks!
    Solved!
    Go to Solution.

    Why don't you place the "first call?" primitive inside the subVI?
    LabVIEW Champion . Do more with less code and in less time .

  • Spry fade loop - how to call properly?

    Hey everyone, I just picked up Spry yesterday. I'm more of an
    artist than a coder so I have a pretty basic question.
    I have a shop that runs with php SMARTY templates, that is
    why this code looks a little odd. I've simplified it here so that
    basically {$product_counter} is a number from 1 to 10 that is
    updated during a loop so that each product has a unique div ID. I
    am using it here to multiply the delay so that each DIV will run
    the productFade with an increasing delay.
    <script type="text/javascript">
    var productFade = new
    Spry.Effect.Fade('dz_product{$product_counter}', {duration: 500,
    from: '0%', to: '100%', toggle:true});
    setTimeout(function() { window.onLoad = productFade.start();
    }, {$product_counter}*200);
    </script>
    Currently it ends up working fine for the last div in the
    list, but the preceeding ones don't fire.
    Perhaps I shouldn't be using window.onLoad? I really don't
    even know how to call these so that they fire in succession, would
    it be better to have the loop in Spry instead of my template and
    just call it once? Any help would be greatly appreciated! Feel free
    to tell me how incredibly wrong I am on all fronts! Cheers,
    -Andrew

    ...of course I get it ALMOST working right the second after I
    post this. I had to create a new function for every instance. Now I
    have productFade1.start(); productFade2.start(); etc etc.. this
    seems to work but there must be a way that is better than 10 nearly
    identical javascripts?

  • Adding queue into a DAQ loop might cause blue screen

    Hi
    I am trying to use VISA to fetch data from a USB port. The data is put into a queue which is decoded in another thread. The pic below shows how my vi looks like.
    The problem is that after around 15mins of execution the windows got blue screen. The error message has to do with usbser.sys.
    I was at first suspicious of the USB virtual COM port's driver. However after I eliminate the queue part of this vi the blue screen problem is gone. The modified vi is like this:
    It seems that this queue is actually causing the pc blue screen problem.
    I have tried it with several different pcs and got the same result. I am using windows OS. 64bit and 32 bit have the same problem.
    The blue screen message is here:
    Has anyone encountered the same problem or had some clue of this issue?
    Thanks in advance!

    I agree with Bjorn, the problem is still likely to be with your USB read implementation.
    Consider the possibility that your system is not reading from the USB buffer sufficiently quickly. What value is in Bytes at Port? Is this value increasing rapidly (faster than you are reading?)
    Removing the Enqueue function perhaps also indicates that the queue write is taking time and preventing the while loop from spinning fast enough which could occur if the queue has a maximum element count (maybe you define the named queue elsewhere with a count limit and are failing to remove the queued elements quickly enough to prevent it from filling up?). You have no timeout wired to the enqueue function which means it will wait as long as it takes, stopping the loop. You might be better with a short (10ms) timeout, followed by a check to make sure it doesn't timeout.
    Also consider using shift registers on your while loop borders to ensure the VISA ref is maintained, the queue ref is maintained and the errors are maintained (although these aren't likely to be the source of your problem, it's always good practice to maintain your error data for handling).
    Thoric (CLA, CLED, CTD and LabVIEW Champion)

Maybe you are looking for