LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Triggered Digital output with DAQ 6221

Solved!
Go to solution

Dear Kevin_Price,

thank you again for your kindness and help.

I totally agree on your point 1 and 3 but concerning point 2, what is the point of having a non symmetric pulse? I mean, all I want to do is to delay a triggered generation, if the low part of the trigger is as short as the high part, I still have my daq waiting for the next pulse so I do not see the point in having two different times. The problem is that now as it is, I no more have errors concerning the DAQ generation and/or detection, but I have as DAQ output a signal with the same frequency as the chopper TTL.

I also tried not to use a pause node and to do that with an initial delay time in ctr0, to obtain something similar to what is shown in the "Delayed single pulse.png"  but nothing works.

I am pretty much desperate about it and at this point I do not know who to ask help to if not you.

Thank you in advance and sorry again for my constant need for help.

Kind regards

0 Kudos
Message 11 of 14
(563 Views)

Q: why a non-symmetric pulse?

A1: it's often the better choice because it's pretty common that only one of the pulse edges will affect trigger or sample timing.  The other is then fairly arbitrary.

A2: for your specific app, I'm not so sure now.  I no longer trust the assumptions I made about your intent when I was replying yesterday.

 

On that theme, I think I need a more thorough step-by-step walkthrough of your whole app.  Not so much the code, more the verbal description.  It seems to start with wanting either edge of an external photodiode signal to trigger some kind of digital output task after some delay.  Among the things that are unclear to me are:

  • freq & duty cycle of the photodiode signal
  • duration of trigger delay
  • # samples and duration of digital output to generate
  • compatibility of all the timing specs above.   Is it possible for the 1st delayed output to be still in progress when the 2nd photodiode edge asserts?   If so, what should happen with your app & tasks in such a scenario?

 

More notes on the DAQ config screenshot:

  • ctr1 output seems unused -- what was this meant for again?
  • several things about the signal and timing relationships don't seem quite right.  
  • it makes sense to me that the DO "pulses" would occur at the same frequency as the incoming photodiode signal.  The DI change detect "trick" lets you get 2 sample clocks per photodiode cycle.  But the DO task also requires 2 samples to produce a full pulse cycle on its 8 bits.   You have a doubling followed by a halving.
  • you *probably* need to route CO.Pulse.Term from ctr1 to the DO task (rather than from ctr0).  Also, ctr1 *probably* needs to pulse at a higher frequency.  The idea will be that each photodiode edge causes ctr0 to make a single pulse.  The high time of the ctr0 pulse needs to "unpause" the ctr1 task exactly long enough to emit 2 pulses to the DO task.  The DO task uses them as a sample clock that will make a full pulse cycle on its 8 bits.   This should further lead to the need for an asymmetric ctr0 pulse (told ya so Smiley Wink ).  Low time (or initial delay) will be used to set the triggering delay, high time needs to be 2/f1 where f1 is the frequency of ctr1 (which in turn needs to be more than double the photodiode freq).

 

That last bullet point is admittedly dense in content, but it also may be most of your solution.  *If* I've worked my way through understanding your app's needs correctly.

 

 

-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 12 of 14
(560 Views)

Thank you again,

I will try to explain it in words: I have a chopper rotating at a frequency f (same frequency of the photodiode, which is attached to its mask, of the order of tens of Hz), with a duty cycle of 50%. Each time a have a change in the chopper TTL signal I want to output a single trigger event going to a camera. Due to the configuration of the setup, I need the camera trigger to be generated with a time delay let's say τ, which can be changed every time I reinitialized the state (so that for each measure session is constant).

In principle, I don't know how many digital samples I want to send to the camera and it is not relevant since for a N images acquisiton, I will read N images from the camera memory buffer which will ignore some extra trigger pulse (so that the generation can go on with the chopper even if I am not acquiring). Together with that, since I will probably acquire with a chopper frequency of 80Hz, I would like to have a single pulse duration of 1ms.  

At the moment I think that all the timing specs should be compatible.

Let's move to the DAQ part.

Ctr1 is supposed to pause the trigger pulse generation, as shown in here , but for sure I am doing something wrong.

I will try what you suggested here, thank you again.

Kind regards

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0 Kudos
Message 13 of 14
(554 Views)
Solution
Accepted by topic author scozia123

I'll try to answer inline for context.

 

...I have a chopper rotating at a frequency f (same frequency of the photodiode, which is attached to its mask, of the order of tens of Hz), with a duty cycle of 50%. Each time a have a change in the chopper TTL signal I want to output a single trigger event going to a camera. Due to the configuration of the setup, I need the camera trigger to be generated with a time delay let's say τ, which can be changed every time I reinitialized the state (so that for each measure session is constant).

 

Ok, the DI change detection task will produce an internal "change detection event" signal on every change of the TTL chopper signal.  Ctr0 will produce a single delayed pulse after each of these change detection events.  Some combo of low time and initial delay will define the delay duration.  So far, so good on *this* part of things.

 

In principle, I don't know how many digital samples I want to send to the camera and it is not relevant since for a N images acquisiton, I will read N images from the camera memory buffer which will ignore some extra trigger pulse (so that the generation can go on with the chopper even if I am not acquiring). Together with that, since I will probably acquire with a chopper frequency of 80Hz, I would like to have a single pulse duration of 1ms.  

At the moment I think that all the timing specs should be compatible. 


Here I can't tell if your term "digital samples" refers to the retriggered pulse from ctr0 or to the DO task.  I agree that a 1 msec pulse duration with 80 Hz incoming chopper freq will be "compatible" for timing.

    If you only want to generate 1 delayed pulse in reaction to every rising or falling edge of the input chopper signal, ctr0 is already doing that.  You won't need the ctr1 or DO tasks.   You can use the ctr0 high time to set the high time to 1 millisec, though in this scenario I'd personally aim for a more minimal 1 microsec.  (Just double check that you meet the minimum width from the camera specs.)

 

 

Let's move to the DAQ part.

Ctr1 is supposed to pause the trigger pulse generation, as shown in here , but for sure I am doing something wrong.

 

I kinda steered you that way b/c I thought you needed to generate a more arbitrary digital output sequence on each triggering event.  If that had been true, the DO task should have used ctr1 output as a sample clock, ctr1 should be a much higher frequency than your chopper, and the ctr0 high time would need to be set carefully to control the # of pulses emitted by ctr1 and used as sample clocks by the DO task.

 

*HOWEVER*, it sounds like you don't need all that.  Just send the ctr0 out directly to the camera and remove all the ctr1 and DO stuff as discussed above.   (Note: the change detection DI task is still crucial.)

 

 

-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 14 of 14
(549 Views)