Start DAQ acquisition or reading on TTL rising front

[scozia123]

Good morning,

I agree with you in semplifying my code, but I cannot get rid of the DO task since this task is triggering the camera with which I am acquiring (and therefore I am checking whether or not the software performs as i want it to), and I have some doubt on getting rid of CTR1, in fact I introduced this task to delay the CTR0 counter so that for every period, I have a delayed TTL, not only for the first.....that is why I thought it was necessary to use another counter.

Is possible to programmatically introduce a delay in counter generation, for each counter event?

Anyway as soon I as can (next week) I will be able to make tests for what you are saying.

Thank you

kind regards

[Kevin_Price]

I'm not sure how to help further without first getting our conversation in sync.  Tracing back through these two related threads, I think we have not used certain terminology the same way and that has led to some misunderstandings of what each other really meant.

Forget all the DAQmx code and tasks for a moment and let's purely talk about signals and timing.   I'll start with what I've come to *think* is true:

1. There's a digital signal from a chopper wheel.

2. The state of the chopper wheel signal determines which of 2 beams is being routed toward your camera.

3. For each time the chopper wheel signal changes state, you want to delay by a specific programmable amount, and then send out a digital signal that will make the camera do a frame grab.  (Any given run will keep using the same delay value, but it should be changeable from one run to the next based on operator choice.)

4. Or maybe (?) you want to send a sequence of pulses to do multiple frame grabs?  But over in the original, other thread, it sounded like each chopper signal state change should result in a single delayed camera-triggering pulse.

5. It's important for you to control (or at least know) what state the chopper wheel is in for each image frame.  Since the chopper wheel state will alternate, this boils down to knowing (or controlling) the chopper wheel state during the 1st frame grab.

6. It will be important that the amount of delay from chopper wheel state change to camera-triggering pulse is short enough that the chopper wheel won't have changed state again 1 or more times.

In your current setup, what signal is physically wired to the camera to trigger a frame grab?

I *think* my advice here might have been what sent you down the path to have a 2nd counter and a DO task as well.  I didn't have as good an understanding of your overall system at that time and have since been suspecting that you probably don't need the 2nd counter or DO task.

Instead of a 2nd counter, there's probably a way to configure the 1st so that it can generate the necessary precision-delayed camera-triggering signal by itself.

Does the camera do a frame grab on a rising edge or on a falling edge of the trigger signal coming into it? 

Do you want to trigger one frame grab per chopper wheel transition or multiple?

-Kevin P

[scozia123]

Good Morning Kevin_Price

point 3 is indeed true, I want each chopper wheel signal change to be delayed of a programmable amount (this is due to the photodiode poition, which is not centered with one of the two beams).

I also agree on point 5, I need the first frames of each acquisition to be acquired at the same chopper position, no matter what it is.

And also poin 6 is true, but I want two point out that the chopper is not rotating faster than 25Hz, so a generated trigger of 1ms should be ok, also considering that the camera is triggered on the rising edge of the trigger (but I can choose it in principle).

Last, with each change event for the chopper, I want to do one frame grab.

At the moment, trigger task is the task sending the trigger to the camera, through an output channel on the board.

Honestly, I don't think that the software is far from doing what I want to...but I will follow your previous advise of tracking through an oscilloscope the single signals in order to understand what and why is not working.

Thank you again

[Kevin_Price]

Still trying to get *full* clarity.

7.  Re: 25 Hz chopper wheel.  Is that the freq of the square wave?   And is the square wave pretty symmetric with equal high and low times?   If so, then at 25 Hz, you get 20 msec each in high and low state.  I agree, plenty of time available to delay and place a 1 msec pulse.

From your latest description, I'm pretty sure you should only need the DI task you call "Dummy Task 1" and the CO task you call "DigitalCounter Task".   The end goal is to produce a triggering edge for the camera which is delayed by a precise amount from each chopper wheel transition.  You can use the output from "DigitalCounter Task" to place this edge.

I would plan around configuring the camera to trigger on a *falling* edge.  For the "DigitalCounter Task", it's easier to make a consistent delay from the Start Trigger (caused by a chopper wheel edge) to the *trailing* edge of the pulse.  It's also probably best to stick with the normal pulse polarity where the default idle state is low, thus meaning that the trailing edge will be a *falling* edge.

I'd configure pulses to have both low time and initial delay set to minimal values such as 100 nanosec.   Then your high time is the single parameter that (almost) solely determines the delay from chopper edge to falling edge camera trigger.  You'd calculate it from your estimated chopper freq and desired phase in degrees much as you have currently been calculating low time.  (Note that depending on how you've defined your phase, you might be missing a factor of 2 in that calc.)

-Kevin P

[scozia123]

Good morning Kevin_Price

7.  the frequency of the square wave is 25Hz and yes, the square wave has 50% duty cycle (except for non ideal jitter but it is ok not to take it into account).

I totally agree on your suggestions, that is why I implemented them into my software (as you can see in the attachments). Is it correct in your opinion?

On top of that, as far as I am understanding, with this solution I have posted the first trigger event that comes always after a Rising edge from the change detection event, so that every first frame I am acquiring should come from the same chopper branch; am I right?

thank you for your time and kindness

[scozia123]

I posted the wrong one, now the Vi looks like this.

kind regards

[Kevin_Price]

I still haven't heard any reason to think the DO task that you call "Trigger Task" is needed.   And in fact, I think it's presently a hindrance.  The DO task will produce one digital pulse for every 2 pulses from the CO task.  You want to trigger the camera on *every* pulse from the CO task, right?  So just physically wire the output pulse from the CO task to your camera and get rid of the DO task that isn't needed.

You can right-click the CO.Pulse.Term property and set it to be write-able, then you can specify a convenient PFI pin of your choosing to physically wire to the camera.

-Kevin P

[scozia123]

I finally what it had to be done, I cleaned every meaningless task as you said, now the situation is that reported in the attachments, with only the change detection task together with the counter output task.

But when running the code nothing happens (even though the chopper signal is what is expected and the PFI12 is working properly) i.e. nothing is output by port PFI12.

I feel like this is the last step to make it all work...but I have no idea why CO is not working, could you please help me, *hopefully* one last time?

kind regards

[Kevin_Price]

The first screencap showing config looks ok to me.  I didn't notice anything that looks out of place or incorrect.  [Edit: oh wait, I just noticed one thing I didn't catch before.  You'll want the call to DAQmx Timing for the DI change detection task to specify "Continuous Samples".  The default when unwired is Finite with a limit of something like 1000 samples.  So it should have run for about 500 cycles (1000 transitions) from the chopper wheel.]

So what exactly does and doesn't happen when you run?   What other things have you done to debug and troubleshoot the code (things like probes, breakpoints, etc.)?  I don't understand your comment that "the PFI12 is working properly" while also saying "nothing is output by port PFI12".

I'd be inclined to say the next troubleshooting step might be to further isolate the change detection and counter output tasks from all the rest of the code.  You should be able to select all that config code with your mouse, copy it, create a new vi, and then paste a copy of just the config code.  Add the little bit of code you need to start the tasks and then wait in a loop until you decide to stop and clear them.  Be sure to watch for any DAQmx task errors.

As you troubleshoot and debug, take notes about any code changes you make and differences in behavior that you observe.  I think you're really close, and am curious what the problem turns out to be since I thought the code in the screencap should have worked (at least for a finite # samples like maybe 1000).

You can often test some basic *concepts* using the shipping examples (menu "Help-->Find Examples...-->Hardware Input and Output-->DAQmx-->...".  For instance, run the example for change detection based DI.  Then also run an example for counter Edge Counting where you can configure to count edges of the Change Detection Event.  (This is a simpler trial test than the more complicated triggering config in your real app.  If the simple thing works, then add levels of complication a little at a time to see where things stop working.)

-Kevin P

[scozia123]

Good evening Kevin_Price

once applied the changes described before, I see no counter output by the DAQ.

I used an oscilloscope to check for signal coming from port PFI 12, and nothing is there.

So I tried (as you also suggested) the testing panel to output, with internal triggering, a counter output from the same port, and it worked (so that I am sure that PFI12 is not broken).

I also run something like the example VI for the change detection event, and it also worked.

So I tried once again to put it all together, (also the trigger line to the camera), but again nothing is acquired, resulting in a waiting error coming from the camera.

Conceptually, and also piece by piece, it works, but alltogether in does't! I have also checked once again for task starting order, but it is (it has to!)  correct.

I have also tried to check for the falling edge trigger camera mode and it also works.

Somehow the counter output task is not triggered by the change detection.

I will keep on testing, there is no way it is not working!

Kind regards