Labview wait for trigger

I have a pci 6221 and labview 2010.  I need a subvi to wait until it recieves a ttl trigger then exit.  Help?

Hi aricks,
Could you post your solution so that our other community members can learn from it? Thanks!
Tim W.
Applications Engineering
National Instruments
http://www.ni.com/support 

Similar Messages

  • Stopping program without waiting for trigger

    Hi everybody
    I have a problem that I just can't get my head around. I have a program that I use to aquire data. The program goes through the motions of waiting for the trigger, aquiring the data on the appropriate channel, displaying it, and loops back to waiting for the trigger. The problem is That when I want to stop my program while it is waiting for a trigger I must wait for it to recieve a trigger before it will stop excution.
    Is there a way for my program to stop the trigger vi when I select to end the program?
    Thanks
    Beaton
    - there is always an easy way, but it is always the hardest to find

    Hi Beaton,
    you have to split the 'wait for trigger time' into shorter sub-steps.
    Let's say you wait 10sec for trigger signal. Make a loop instead waiting 1 second for 10 times! After each iteration you can check for: 'break the loop (end program)' or 'trigger received' or 'any other error occured'. This way you can stop your program very easily - you can also make your own error state saying 'Error number 123456: stopped by user'...
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • Wait for trigger

    Hello
    I need help making a VI for waiting for a trigger. I am working with a TDS 2024 scope.
     I have to tell  the scope how long to wait for the trigger and if it does not find it in that time, then it will tell the user that no trigger was found.
    Can anyone help me with this?
    xxmidna

    Midna19 wrote:
    Hello
    I need help making a VI for waiting for a trigger. I am working with a TDS 2024 scope.
     I have to tell  the scope how long to wait for the trigger and if it does not find it in that time, then it will tell the user that no trigger was found.
    Can anyone help me with this?
    xxmidna
    Time to break out the scope manual and see what commands are needed to achieve this.  Put a VI together and then we can talk about refining it. 
    Alternatively, you can see if you can find some drivers for this scope.  I think Tektronix has pretty good LV support.
    (This assumes you know how to use the scope.)
    Bill
    (Mid-Level minion.)
    My support system ensures that I don't look totally incompetent.
    Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

  • NIScope CPU usage 100% when waiting for trigger

    Hello, I'm using a NI 5102 DAQ card and want to acquire single bursts. However when the Multi Fetch.vi is waiting for a trigger (and this can be up to a minute) the CPU usage goes up to 100 %. Is there any way to overcome this?
    Attachments:
    Current_ProjectSWEEP2withoutAgilentNEWScopeWrite_to_FilePOSTED.vi ‏98 KB
    ScopeSUB.vi ‏108 KB

    Yea, Ive noticed the same thing.  The niSope dll in the Fetch.vi grabs 100% CPU if timeout is larger than 1 or 2 seconds. 
    Has anyone talked to NI about this?  The problem is in that dll which is polling the PCI Scope Card.  That dll is not giving back any CPU if it waits for more than a second or two.
    John Dailing
    [email protected]

  • Extra empty groupName in TDMS file when using DAQmx Start New File & stop DAQmx while waiting for trigger?

    I wrote a VI that listens to an external trigger coming from a PFI line and saves a user-defined number of pretrigger+posttrigger samples into disk, and then the DAQmx restarts to wait for the next trigger. I used the DAQmx Start New File.vi to change the filename of each of the next file. However, I found that for each of the resulting TDMS files, there is an additional group that is added in addition to the real data. For example, if the groupName is set to "task_voltage", then there is an additional groupName called "task_voltage #1".
    I suspect that this is because the program preallocate diskspace using the old filename for the pretriggered samples, but when the trigger happens and the samples are ready to be written into disk, an actual new file is opened and saved. The reason I think this might be the case is because, say each file would be 50kB and I already have 1 file triggered and saved, before the second trigger comes in, I can see that the file size of the first file is twice as much as it should be (100kB), but the file size will return to noraml (50kB) after the second trigger happens and a second file is created.
    Does anyone know if this is really the case? Is there a way to configure the task so that this doesn't happen?
    Another question I have is that the program currently set up so that the VI will wait until a trigger happens to return the values. However, this means that if a trigger doesn't happen, the VI waits indefintely, and the "stop" button in the while loop is useless. I have to use the "Abort Execustion" button on the tool bar to stop the VI. Is there a way to interrupt and stop the DAQmx task even if the trigger doesn't happen?
    Thanks in advance for any help!
    Attachments:
    pretrigger_loop_new_file.vi ‏29 KB

    I don't believe there is a way to programmatically change/delete the group name in a TDMS file. What you can do however, is convert between TDMS and TDM using the VIs found in the Data Storage palette and then perform whatever modifications you need using the TDM utilities.
    Applications/Systems/Test
    National Instruments | AWR Group

  • How do I continuous​ly wait for a trigger?

    using labview and GPIB to control tektronix 3034B oscope. want to continuously wait for trigger. how do i get rid of timeout? I am using IVI instrument driver for 3034B

    Hi,
    You can use the low level adquisition VIs. First call Initiate Acquisition. Then use the Acquisition Status VI to determine if the acquistion is complete. This wait you can wait indefinitely.
    Of course, you could also set the timeout value of the ReadWaveform VI to something like 86000000 ms, which is aprox. a day of timeout .
    DiegoF
    National Instruments.

  • HSDIO conditionally fetch hardware compare sample errors (script trigger to flag whether or not to wait for software trigger)

    I am moderately new to Labview and definitely new to the HSDIO platform, so my apologies if this is either impossible or silly!
    I am working on a system that consists of multiple PXI-6548 modules that are synchronized using T-CLK and I am using hardware compare.  The issue I have is that I need to be able to capture ALL the failing sample error locations from the hardware compare fetch VI... By ALL I mean potentially many, many more fails than the 4094 sample error depth present on the modules.
    My strategy has been to break up a large waveform into several subsets that are no larger than 4094 samples (to guarantee that I can't overflow the error FIFO) and then fetch the errors for each block.  After the fetch is complete I send a software reference trigger that is subsequently exported to a scriptTrigger that tells the hardware it is OK to proceed (I do this because my fetch routine is in a while loop and Labview says that the "repeated capbility has not yet been defined" if I try to use a software script trigger in a loop).
    This works fine, but it is also conceivable that I could have 0 errors in 4094 samples.  In such a case what I would like to do is to skip the fetching of the hardware compare errors (since there aren't any) and immediately begin the generation of the next block of the waveform.  That is, skip the time where I have to wait for a software trigger.
    I tried to do this by exporting the sample error event to a PFI and looping that PFI back in to generate a script trigger.  What I thought would happen was that the script trigger would get asserted (and stay asserted) if there was ever a sample error in a block, then I could clear the script trigger in my script.  However, in debug I ended up exporting this script trigger back out again and saw that it was only lasting for a few hundred nanoseconds (in a case where there was only 1 injected sample error)... The sample error event shows up as a 1-sample wide pulse.
    So, my question is this:  is there a way to set a flag to indicate that at least one sample error occurred in a given block  that will persist until I clear it in my script?  What I want to do is below...
    generate wfmA subset (0, 4094)
    if scriptTrigger1
      clear scriptTrigger1
      wait until scriptTrigger0
    end 
    clear scriptTrigger0
    generate wfmA subset (4094, 4094)
    I want scriptTrigger1 to be asserted only if there was a sample error in any block of 4094 and it needs to stay asserted until it is cleared in the script.  scriptTrigger0 is the software trigger that will be sent only if a fetch is performed.  Again, the goal being that if there were no sample errors in a block, the waiting for scriptTrigger0 will not occur.
    I am probably going about it all wrong (obviously since it doesn't work), so any help would be much appreciated!

    Please disregard most of my previous post... after some more debug work today I have been able to achieve the desired effect at slower frequencies.  I did straighten out my script too:
    generate wfmA
    if scriptTrigger1
      clear scriptTrigger0
      wait until scriptTrigger0
    end if
    generate wfmA
    scriptTrigger1 = sample error event flag
    scriptTrigger0 = software trigger (finished fetching error backlog in SW)
    However, I am still having a related issue.
    I am exporting the Sample Error Event to a PFI line, looping that back in on another PFI line, and having the incoming version of the Sample Error Event generate a script trigger.  My stimulus has a single injected sample error for debug. For additional debug I am exporting the script trigger to yet another PFI; I have the sample error event PFI and the script trigger PFI hooked up to a scope.
    If I run the sample clock rate less than ~133MHz everything works... I can see the sample error event pulse high for one clock period and the script trigger stays around until it is consumed by my script's if statement.
    Once I go faster than that I am seeing that the script trigger catches the sample error event occasionally.  The faster I go, the less often it is caught.  If I widen out the error to be 2 samples wide then it will work every time even at 200MHz.
    I have tried PFI0-3 and the PXI lines as the output terminal for the sample error event and they all have the same result (this implies the load from the scope isn't the cause).
    I don't know what else to try?  I can't over sample my waveform because I need to run a true 200MHz. I don't see anything that would give me any other control over the sample error event in terms of its pulsewidth or how to export it directly to a script trigger instead of how I'm doing it.
    Any other ideas?

  • Using DAQ occurrence to wait for start trigger

    Hi,
    I'm trying to use digital triggers to start and stop datalogging. Every time start trigger appears, new file is created and data is acquired to file until stop trigger occurs. Now I'm using set DAQ occurrence and wait for occurrence functions to wait for start trigger before creating a new file. The problem is that after first stop trigger this occurrence method doesn't work. I believe it's because AI is not cleared and configured before calling DAQ occurrence again. Number of scans acquired is not zero, if I don't clear and configure AI again? Am I right?
    Do I have to clear and init AI everytime before occurrence config or is there a better way to make program wait for start trigger?
    Thanks in advance,
    Jakke

    Hi Matt99eo,
    Have you configured your device for triggering?  Although you have not mentioned your device specifically, the M series user manual provides a great explanation of digital triggering.  Using the DAQ Assistant, this can be configured from the triggering tab.  Hopefully this helps!
    Regards,
    h_baker
    National Instruments
    Applications Engineer
    Digital Multimeter Resources

  • Trigger error -deadlock detected while waiting for resource

    with table1 as (
    select '1' no,'1' id, 'N' flag,'' result from dual union all
    select '2' no,'1' id, 'N' flag,'B' result from dual union all
    select '3' no,'1' id, '' flag,'B' result from dual union all
    select '4' no,'2' id, 'N' flag,'B' result from dual union all
    select '5' no,'2' id, 'N' flag,'B' result from dual
    select * from table1
    I need to write a trigger with the condition that if Flag is set to 'Y', then all the values for the field 'result' for that particular ID should set a 'A'.
    For the above table if I run the below query
    update table1
    set flag= 'Y' where no =1
    The trigger result should be
    with table1 as (
    select '1' no,'1' id, 'Y' flag,'A' result from dual union all
    select '2' no,'1' id, 'N' flag,'A' result from dual union all
    select '3' no,'1' id, '' flag,'A' result from dual union all
    select '4' no,'2' id, 'N' flag,'B' result from dual union all
    select '5' no,'2' id, 'N' flag,'B' result from dual
    select * from table1
    I wrote the trigger as below...
    CREATE OR REPLACE TRIGGER test
    BEFORE UPDATE
    ON table1 for each row
    DECLARE
    PRAGMA AUTONOMOUS_TRANSACTION;
    BEGIN
    if :new.flag = 'Y' then
    update table1
    set result = 'A'
    where id = :new.id ;
    commit;
    end if;
    end;
    but giving follwing error.
    ORA-00060: deadlock detected while waiting for resource
    ORA-06512: at "test"
    ORA-04088: error during execution of trigger 'test'
    Please help to correct my trigger.

    # Firstly you cannot define trigger using on subquery clause - WITH. e.g. table1.
    # You might have used a trick to use PRAGMA AUTONOMOUS TRANSACTION to isolate trigger transaction from the main transaction but the deadlock will certainly going to occur as the main transaction already hold the row level lock which you are trying to update in trigger code.
    # We will try to use common technique to capture all the ID whose flag is set as 'Y' in row level trigger and then in statement level trigger after update will update the column - "resut" for the ID.
    This is very simple test code for demonostration.
    CREATE TABLE T
      NO      NUMBER,
      ID      NUMBER,
      FLAG    VARCHAR2(1),
      RESULT  VARCHAR2(1)
    INSERT INTO  T VALUES (1,1,'N',NULL);
    INSERT INTO  T VALUES (2,1,'N','B');
    INSERT INTO  T VALUES (3,1,'','B');
    INSERT INTO  T VALUES (4,2,'N','B');
    INSERT INTO  T VALUES (5,2,'N','B');
    CREATE OR REPLACE PACKAGE PKG_T_MUTATING AS
    TYPE IDTABTYPE IS TABLE OF T.ID%TYPE;
    T_ID IDTABTYPE := IDTABTYPE();
    PROCEDURE GET_UPDATE_ID(P_ID T.ID%TYPE);
    PROCEDURE UPD_T;
    END PKG_T_MUTATING;
    CREATE OR REPLACE PACKAGE BODY PKG_T_MUTATING AS
    PROCEDURE GET_UPDATE_ID(P_ID T.ID%TYPE) IS
    BEGIN
      T_ID.EXTEND;
      T_ID(T_ID.COUNT) := P_ID;
      DBMS_OUTPUT.PUT_LINE('T_ID ' || T_ID(T_ID.COUNT));
    END GET_UPDATE_ID;
    PROCEDURE UPD_T IS
    V_ID PKG_T_MUTATING.IDTABTYPE := PKG_T_MUTATING.IDTABTYPE();
    BEGIN
    V_ID := V_ID MULTISET UNION DISTINCT T_ID;
    IF V_ID.COUNT > 0  THEN
      FORALL i IN 1..V_ID.COUNT
       UPDATE T SET RESULT = 'A'
       WHERE ID = V_ID(i);
    END IF;
    -- Cleanup
    V_ID.DELETE;
    T_ID.DELETE;
    EXCEPTION
      WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
    END UPD_T;
    END PKG_T_MUTATING;
    CREATE OR REPLACE TRIGGER TRG_TEST_BU
    BEFORE UPDATE OF FLAG ON T FOR EACH ROW
    WHEN (NEW.FLAG = 'Y')
    BEGIN
    pkg_t_mutating.get_update_id(:NEW.ID);
    END;
    CREATE OR REPLACE TRIGGER TRG_TEST_AU
    AFTER UPDATE OF FLAG ON T
    BEGIN
    PKG_T_MUTATING.UPD_T;
    END;
    SQL>SELECT * FROM T;
            NO         ID FLAG       RESULT
             1          1 Y          A
             2          1 N          B
             3          1            B
             4          2 N          B
             5          2 N          B
    SQL>UPDATE T SET FLAG = 'Y' WHERE NO = 1 AND ID = 1;
    1 row updated.
    SQL>SELECT * FROM T;
            NO         ID FLAG       RESULT
             1          1 Y          A
             2          1 N          A
             3          1            A
             4          2 N          B
             5          2 N          B
    SQL>
    {code}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • All acquisitions wait for digital trigger, why?

    On one computer I have 2 eseries 6023 daq boards installed. One for a digital triggered acquisition, and the other for a continuous (chart recorder type) acq. When running the two seperate VI's, why does the the cont. acq. VI wait for the trigger on the other VI? Appreciate any help.

    Hi digger,
    AI Read.vi waits until the samples are in the buffer.
    Do following: Call AI Read.vi with 0 scans to read. Look in scan backlog output if any samples are available. If there are samples waiting call AI Read.vi with this output contected to the input scans to read otherwise do nothing.
    This prevents AI Read.vi from waiting until samples are in the buffer.
    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

  • Should I install 2009 labview on a new pc or wait for the new version?

    Solved!
    Go to Solution.

    The maintenance release is officially called Service Pack 1. It will be released sometime in Q1 2009, and future versions of LabVIEW should also expect a service pack in that timeframe. Stay tuned for exact release dates.
    Since you need LabVIEW installed to install the Service pack, I don't think there is any benefit to waiting, unless you want to wait for NIWeek in August, as mentioned
    Rob K
    Measurements Mechanical Engineer (C-Series, USB X-Series)
    National Instruments
    CompactRIO Developers Guide
    CompactRIO Out of the Box Video

  • When a vi hangs...how do I find out what it is waiting for?

    I have a vi.  It is "waiting for front panel activity".  I cause some front panel activity by pressing a control...and the vi functions.  I then press the same button again and the vi hangs, the front panel does not respond to any mouse activity.  When I run the highlight execution function it shows that the case controled by the value change of the control executes to the end in the true case, but then there is no further action anywhere on (in) the vi.
    How do you find out what the vi is waiting on to proceed, or which element "has the ball" so to speak.
    Thanks
    Stopped Humming for a while.

    If you have event structures, you usually have no longer any need for "wait for front panel activity". This was more of a cheap bandaid solution before the introduction of the event structure.
    Many front panel operation don't need to trigger any events or do anything, so spinning the "wait for activity loop" everytime something is clicked is a total waste of resources.
    You should create events only for  things that really do something while other controls (e.g. configuration) don't need to be serviced by any event. The control will keep the data until it is needed by the code.
    Here is an example:
    You need to set aquisition parameters (rate, # of points, etc.) then press a button to start acquisition. None of the paramter settings need any events or need to spin any loops. Once start is pressed, their last settings will get read from the terminal anyway if the code is layed out correctly. And so on....
    LabVIEW Champion . Do more with less code and in less time .

  • NiDCPower Wait For Event

    Hello,
    I am using the PXIe-4139 SMU to source a current sequence that starts when a trigger is received and takes about 40 seconds to complete.
    After the niDCPower Initiate VI I have inserted the niDCPower Wait For Event VI with a timeout set to 300 seconds to allow for enough time to receive the trigger and complete the sequence. This VI waits for the Sequence Engine Done Event.
    Now this works fine, however, when the user wishes to stop the programm for whatever reasons, they have to wait the full 300 seconds until the Wait For Event VI produces a timeout error and stops the programm. This is rather inconvenient. How can I change the programm so that the user can stop it even when the Wait For Event VI hasn't reached its timeout?
    I tried this:
    But this doesn't work. For some reason, I get a timeout error with code -200474 but the boolean operator returns FALSE.
    Any other ideas?

    If there an output on the wait for event VI that flags a timeout? If so, set the timeout short (like 100 msec) and wait for 3000 timeouts before continuing on.
    Oh, and use an event structure. Timeout event (timeout=0) checks the wait for event, value change event for button breaks out of loop.
    Mike...
    Certified Professional Instructor
    Certified LabVIEW Architect
    LabVIEW Champion
    "... after all, He's not a tame lion..."
    Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

  • "Waiting for real-time target (RT PXI target) to respond" error when the program waits interrupts

    Hi there,
    I have developed an application to detect interrupts generated by a electronic card and act in consequence. The program has been developed in labview but it calls a dll; that was created with labwindows. The dll is programmed to open the visa communication, enable events and install the interrupt handler and when an interrupt is detected, it reads the value of the different registers of the card and returns it to labview to visualize them. 
    The problem is that when the program waits for an interrupt, a prompt appears with the message "Waiting for real-time target (RT PXI target) to respond" and the only option I have is to click on the button to disconnect from the pxi or just wait. If I wait and I generate an interrupt, the prompt disappears and the application visualize the data like it was expected. 
    To wait for the interrupt the following code has been programmed in the function:
                    while (flag == 0)
                                    Sleep (1000);
    When an interrupt occurs, the value of flag changes to 1 and the function continue without any problem. I am not really sure, but probably here is the problem and probably this is not the best way to wait for an interrupt because the sleep function suspends the thread for the configured time, but at least the computing load in the PXI is between 0% and 1%. I was wondering if somebody knows how to wait for an interrupt without "lost" the communication with the PXI and if there is a better way to do it. 
    Any answer will be welcome and thanks for them,
    Jaime
    Solved!
    Go to Solution.

    Hello Naity,
    First of all, in which thread runs the waiting process? Is it scheduled in another thread than the function setting the flag?
    It scheduled in the same thread that I use to configure the communications and configure the card. Anyway, here is the pseudo code of the function interrupt that I programmed under labwindows,.
    char* interrupt(void)
    1. Open visa communications
    2.Install handler interrupt --> status = viInstallHandler (instr, VI_EVENT_PXI_INTR, IntrHandler, VI_NULL);   // the function IntrHandler will be called when an interrupt occurs
    3. Enable event PXI interrupt
    4. Wait
    while (flag == 0)
                  Sleep (1000);
    5. Visualize the data coming from the interrupt (registers and values measured with the card)
    6. Uninstall handler interrupt
    7. Close visa session
    The interrupt handler function IntrHandler is called immediately when an interrupt occurs and the pseudo code is like this
    ViStatus _VI_FUNCH IntrHandler(ViSession instr, ViEventType etype, ViEvent event, ViAddr userhandle)
    1. Disable some functions of the card to avoid damages. 
    2. Read registers and put them in a buffer
    3. Change the value of flag ---> flag = 1;
    In labview, I call the function interrupt with a call library function node (see the capture attached) and the program reads and saves the data from returned from the function.
    Secondly, I am not sure this method is the most elegant. You could for example register an event with the function and, insteand of setting a flag to 1, trigger the event and schedule it in another thread (if the function is thread safe). This could reduce your CPU Load even more and seem a bit cleaner to me.
    I've never used events before in labwindows but I will try to do it in this way. But anyway, I suppose that I should; somehow, wait the event to occurs in labview while the waiting for the event is programmed inside the dll...and probably the same prompt that i am trying to avoid is going to appear again, because I am not returning the "control" to labview (I mean, labview executes the dll and waits for the event to occur. Then the execution of the labview program is stopped in the call library function node executing the dll)
    Third point, which environment of development are you using?
    I am working with LV 2010 sp1 and Labwindows cv 10.0.1 and with the real time module.
    I did also another test, I divided the program in different functions, one to initialize the communication, another to wait until a interrupt has been detected and the other to obtain the data from the interrupt and close communications. With labview I call first with the call library function node the function to initialize, later I call inside a while loop the wait function like this
    int waitAseconds (double seconds, short stop_waiting)
    if(flag==1 || stop_waiting == 1)
    flag = 1; //to detect the stop_waiting button
    printf("flagAA =1 stop waiting = %d time = %d\n", stop_waiting, clock());
    return flag;
    else
    SleepUS(seconds*1000000);
    //a++;
    printf("flag a= %d stop waiting = %d time = %d\n", flag, stop_waiting, clock());
    return flag;
     and when the program detects an interrupt, the function returns to labview the flag and stops the loop. Finally, it reads the values and close communications. 
    In this way, the prompt appears but after running the application for 10 or 20 minutes and also i checked that there is a time gap between the executions in the loop.
    Thanks for your reply and your help,
    Jaime
    Attachments:
    capture.png ‏40 KB

  • NI Scope Wait for Acquisition to Finish Obselete in 2014

    Quick Question,
    In LabVIEW 2014, the NI scope Wait for Acquisition to Finish subVI is no longer used and is obsolete apparently, can some one tell me why this is and what I can use instead with the new 2014 NI scope blocks? 
    Thanks for your help!

    Query Acquisition Status until Status is "Complete"  To avoid infiate loops (missing trigger event) you should set a Timeout for the loop
    Alternately use hardwae and rout the End of Acquisition event to something
    Jeff

Maybe you are looking for