Three counters: 2 single pulses and 1 double pulse

[michberk]

Hi everyone,

I am trying to figure out if this is double. I have 3 counters where I can force pulses.

My idea is to use counter A for a single pulse of duration A and counter B for a single pulse of duration B and the two use counter C for a double pulse so that I have one pulse at the same time as A and one as the same time as B.

This is how it should look like. The time between the start of A and C1 is d(A_C) and between B and C2 is d(B_C).

What I tried to use was a CO.Pulse.Time for A and B to stablish their high times and then CO.Pulse.Freq for C where I set the frequency accordingly (1/[PulseA+Pause+PulseB-d(A_C)-d(B_C)]) and the duty cycle by multiplying the frequency with the length of the pulses. After this I set Finite Samples and only 2. 

The problem with this is that when I use the DAQmxTiming VI and I set Two Pulses, the program ends up outputting two pulses of each: two A, two B and two C. Is there any other way to do it so that the double pulse is only with one counter?

Thank you in advanced.

[Kevin_Price]

It appears that you've coded in a way that suggests you'll have a known, fixed timing delay from the start of pulse A to the start of pulse B.  (Yes, I realize many timing parameters are front panel controls that a user can vary.  But for a given run, the timing is predefined rather than being calculated based on some measurement.)

With that being the case, I would approach it a different way.  I'll be assuming you have a modern era counter that supports buffered pulse output.

- First I would use 3 separate counter tasks, which allows you to define each counter's timing behavior distinctly.   The reason all of them generate 2 pulses is because they're all in a task that's been defined to generate 2 pulses.  That makes each counter in the task pulse twice.

- Then I would configure *all* of them to be start triggered by a signal that your code can control.  Depending on your device, this might be a simple DO line or it could be a 4th counter pulse.   All 3 counter tasks should have called DAQmx Start before you assert the trigger signal.

- Counters A & B would *not* call DAQmx Timing, leaving them to the default behavior of generating a single pulse

- You're already calculating the extra delay that makes counter B pulse later than counter A.  Keep doing that.

- Only counter C's task should call DAQmx Timing to define a 2-pulse finite sampling task.  Before starting this task, you'll need to write 2 sets of pulse timing parameters to the task to define the timing of the 2 pulses you're generating.  The time in the initial idle state should be d(A_C) longer than the initial delay for pulse A.  You'll be doing something similar for pulse C2, but have more little time segments to add up to make sure you place it the right amount of delay after pulse B.  But very doable.

- Kevin P

[michberk]

I have followed your advice: 3 independent tasks = 2 CO Pulse Time (A and B) and 1 with CO Pulse Freq + Timing Implicit + Counter 1D Time 1Chan NSamp (the input here is an array of 2 clusters with two numbers: high time and low time)

All of the tasks have the trigger definition and start afterwards. When all of this is defined, I trigger.

The Timing Implicit has Sample Mode: Finite Samples and Samples per Channel: 2. It works!!

But the delay is not correct. Even when task A and task C have both a delay of 0, the pulses don't start at the same moment. I think I don't understand quite right what you explained in your last point.

[Kevin_Price · Accepted solution]

It's been quite a while since I've done any actual tinkering with buffered counter output, so what I can give you is more of an approach than an outright solution.

You have control over the timing of the C pulses.  There *will* be a way to align with task A in the way you want, provided that both tasks use the same signal as a trigger *and* that trigger signal doesn't assert until after both tasks are started.

You define 5 timing intervals in your code.  For the sake of experimenting and learning, make all 5 intervals distinct from one another.  That'll help you understand which one(s) need to be changed in your real app to bring about alignment with A.

1. Initial delay - sorry, I simply don't recall for sure what role this value plays for a buffered pulse output task that's also triggered.  Experiment and observe.  Include runs where you leave this input unwired to observe default behavior.

2. Low Time(0) - it's possible that initial delay replaces this or adds to this in defining the time from trigger ede to first pulse rising edge.  It also may have no effect whatsoever, I just don't recall.  Use very distinct values to help make this more clear.

3. High Time(0) - no notes, wired value should occur

4. Low Time(1) - no notes, wired value should occur

5. High Time(1) - no notes, wired value should occur

-Kevin P

[michberk]

I managed! 

Delay set to 0

Low Time 1: delax

High Time 1: length of C1

Low Time 2: pause in between

High Time 2: length of C2.

Thank you so so so much!! You're input was amazing!