LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Starting data acquisition from combination of two triggers

Solved!
Go to solution

I have a program recording data using DAQmx VIs: Create channel -> Sample clock
-> Trigger start (T1) -> Start.Retriggerable-> Analog waveform read (Sequence) Read vi is inside of a FOR loop. This way I am averaging predefined number of waveforms.
T1 is generated continuously by an external device.

Is it possible to start the Sequence programmatically by another trigger T2 from different external device, i.e. trigger T2 "arms" Trigger start vi to accept multiple T1s to start multiple waveform acquisitions synchronized with T1?

I did look into Start Arm Trigger, but to my understanding it works only with counters.

 

Thank you.

0 Kudos
Message 1 of 10
(2,927 Views)

I suggest you attach your VI so we can really see what you are doing.  It also gives us something to "play with" (i.e. to try out our ideas so we can be sure we are giving your good advice).  It also helps other Forum users who may have similar questions or want to do something similar.

 

Bob Schor

0 Kudos
Message 2 of 10
(2,924 Views)

I don't think you can do that using an AI task alone.  I think you *could* do this by pairing up the AI task with a counter task, if you have one available.

 

The counter would be setup to generate a retriggerable single pulse.  The low time and initial delay would be minimal (under a microsec).  The T1 signal would be the regular "Start Trigger".

 

AI would be setup to be retriggered by the signal with a name like "/Dev1/ctr0InternalOutput" (not at a LV machine to double check right now).

 

So far, all this does is very slightly delay the trigger signal you've already been using directly for AI.  The next part is the key.

 

*Also* configure the counter to use T2 as its "Arm Start" trigger.  The counter won't arm until T2 occurs.  Thereafter, it will pulse after every subsequent instance of T1.   Since AI is triggered by the counter now, you'll get the AI behavior you want.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 10
(2,903 Views)

Kevin, thank you for idea.

You meant something like this? For triggering data acquisition by counter from T1.

 

 

0 Kudos
Message 4 of 10
(2,868 Views)

That's a decent start, but I'd make several changes:

 

Crucial changes:

1.  The AI task should also be set to be retriggerable

2. You haven't sequenced the tasks carefully to do what (I think) you're aiming for.

3. The counter task needs to configure both the regular Start trigger (T1) plus an additional config for an "Arm Start" trigger (T2).  Search the forums to find more info & details (often from me).  The "Arm Start" trigger can only be configured with a DAQmx Trigger property node.

4. You shouldn't start and stop the counter pulse task inside your loop.  It should be started once before the loop and stopped once after it.

 

Suggested changes:

5. I'd explicitly start the AI task before the loop rather than relying on auto-start.  Auto-start is slower and could cause you to miss a trigger sometimes.

6. I'd make the counter pulse times even shorter, like maybe 0.1 microsec.  You should also wire this value to the 'initial delay' input.

 

Optional changes:

7. You don't have to explicitly define the signal "/Dev4/PXI_Trig0".  Instead of writing a specific value to the "CO.Pulse.Term" property, I would just *read* from it and wire the output over to the AI trigger config.  That leaves DAQmx free to use any available PXI trigger line, just in case there's a conflict on the one you've defined explicitly.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 10
(2,845 Views)

Kevin, thanks again.

Please see attached code with recommended changes.

Crucial changes:

1. I didn't set AI to retriggerable because it works without it.

2. Agree, my first step was just to start AI from counter pulse. When I placed start and stop counter pulse task outside the loop (item 4.) it worked.

3. I have added "Arm Start" trigger (T2), but when it is not present the code still acquires waveforms (T1 is running).

4. See 2.

Suggested changes

5. When I am placing Start and Stop for AI channel before and after the Loop, respectively, I am getting an error on Stop.

6. I "played" with different values for pulse width. It doesn't make a difference in behavior.

0 Kudos
Message 6 of 10
(2,819 Views)

Had a look, here's some more comments:

 

1 & 5.   These are related.  The error you get in your comment #5 is *because* you didn't do my suggestion #1.  I see that your current method "works", but it would work *better* the way I described.  (Here I define "better" as "less prone to missing a trigger at T1").

   As you have things, you're relying on the default "auto-start" property (settable with a DAQmx Read property node, but defaulting to True).  In this mode, a call to DAQmx Read will make the task work through transitioning all the way into start and run mode.  Because you have a finite task and you're asking to read the entire finite dataset all at once, the task will then auto-stop and revert all the way back to the state it was in before you called DAQmx Read.   From memory, I believe this extra overhead may take as many as 10's of msec, during which time you might miss a trigger.

   My suggestion would keep the task always in run state.  I believe (but can't test and verify) that in this mode, there's a much tinier window for missing a trigger.  Perhaps on the order of 1 msec.  Here's how I understand it.  As soon as the buffer fills, the DAQmx Read function is alerted to be able to retrieve all the data.  As soon as the data has been retrieved, the task is then free to re-arm for the next trigger.  (The alternative might be that it arms as soon as the buffer fills, independent of whether you retrieve the data.  In such a case, another incoming trigger before you retrieve the data would cause an error due to no space in the buffer.)

 

3. You need to *also* configure ArmStart.TrigType = "Digital Edge" on your property node.  It seems it defaults to the other choice, "None".

 

6. Yes it works with longer pulse times, but it would be an improvement to minimize the delay.  My suggestion of extra short pulse parameters minimize the delay from when the external signal triggers the counter until the counter triggers AI.  Unless there's a purpose for carefully choosing a specific delay value, most other apps should just use minimal values.   Not always crucial, but usually a good idea and generally a good habit.

 

New stuff:

7. The AI task probably should be started before the counter task so you know it's armed and ready to catch the very first T1 trigger occuring after the less frequent T2.  If the counter task starts first, it might be get the T2 trigger and generate several delayed T1 triggers before the AI task starts and "catches" them.  This need to start AI first is another reason to bring the Start and Stop outside the loop (and then also make AI retriggerable).

 

8. Your main loop ignores errors.  I would share a single error wire for both tasks, and then also react to errors in the loop.   You can right click the For Loop boundary and toggle the "Conditional Terminal."  Then connect the single error wire from the output of AI Read to the stop terminal.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 7 of 10
(2,807 Views)

Thank you, Kevin.

 

You are right about 1&5 and 7 (made changes).

3. I have added ArmStart.TrigType = "Digital Edge" on property node, but it stills behaves the same way (acquires waveforms without T2).

I will deal with errors later.

 

Zakhar.

0 Kudos
Message 8 of 10
(2,800 Views)
Solution
Accepted by topic author Zakhar

I didn't know that the order of properties is important. When I put ArmStart.TrigType = "Digital Edge" on property node first, the code starts working as required.

 

Kevin, thanks again.

 

Zakhar.

 

Message 9 of 10
(2,793 Views)

Actually, I didn't know the order mattered either.  I guess I've just gotten them in the right order by picking the top one in the list (which happens to be ArmStart.TrigType), then expanding the property node downward to reveal the next ones.  It's fortunate they're listed in the order that works correctly.

 

Tidbit: note that for *any* property node, properties are handled in top-to-bottom order.  You could expand to show the same property 3 times in a row, read then write then read again.  The first read gives you the old value *before* the write, the last read gives the new value *after* the write.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 10
(2,789 Views)