Arm Start trigger (work-around) for analog-input task

[550nm]

Greetings,

I have two counter tasks: ctr0 produces a continuous square-wave, ctr1 produces a GUI/user-initiated pulse. I would like to Arm an AI task on ctr1 pulse (rising) and Start the AI on ctr0 (rising).  The problem is Arm-Start doesn't seem to be valid for AI tasks(?)  Is there a work-around - that does not require using another counter? 

Thanks!

[Kevin_Price]

The concept of arming is unique to counters, it doesn't really have a meaning for AI tasks.  So let's take a look at the functional behavior you're looking for and find another way to accomplish it.

Sounds like you want to trigger AI on the first pulse from a continuous pulse train that occurs after a user/GUI initiated pulse.  I think there are a number of possible options.  For example, since user/GUI timing is already pretty imprecise, you could just start the AI task on the GUI event.  The next continuous pulse will serve as a trigger to sync the AI with that pulse train.  Whether or not you also generate the ctr1 pulse depends on whether it has any other purpose in your system.

-Kevin P

[550nm]

Hi Kevin,

Thanks for the reply.  ctr1 is used to synchronize another task with the AI task. I really need the AI task to wait for ctr1, then "Start" on first edge on ctr0. FYI: these two events will be ~500us apart.

I'm open to any solution, but also wonder if the idea of a "virtual" counter-task is realizable. Such a "virtual-task" would wait for Arm(ctr1), and Start on ctr0, then (somehow) the task's "Started" signal would be routed to AI Start trigger.

[Kevin_Price]

I'm gonna need more complete info about signals and timing, their meaning and purpose, and a model # for the DAQ board(s).  Some questions:

1. Is ctr1 driven in any way by signals from ctr0?  Or is it entirely independent and is started via software in response to a GUI event?

2. Is ctr1 a single pulse or a pulse train?  If pulse train, finite or continuous?  How else is it used (you mentioned sync'ing another task)?

3. Describe that other task

4. Is the AI task finite or continuous?  Is it triggered just once or is it retriggerable?  If retriggerable, do you need the same sequence every time, i.e., ctr1 to "arm", then trigger off next ctr0

5. What frequency is ctr0?  Is it used for anything else besides triggering AI after the "arming" event?

-Kevin P

[550nm]

---

@Kevin_Price wrote:

I'm gonna need more complete info about signals and timing, their meaning and purpose, and a model # for the DAQ board(s).  Some questions:

1. Is ctr1 driven in any way by signals from ctr0?  Or is it entirely independent and is started via software in response to a GUI event?

2. Is ctr1 a single pulse or a pulse train?  If pulse train, finite or continuous?  How else is it used (you mentioned sync'ing another task)?

3. Describe that other task

4. Is the AI task finite or continuous?  Is it triggered just once or is it retriggerable?  If retriggerable, do you need the same sequence every time, i.e., ctr1 to "arm", then trigger off next ctr0

5. What frequency is ctr0?  Is it used for anything else besides triggering AI after the "arming" event?

-Kevin P

---

For the record: I tried to frame the problem in a simple way.

In fact, the application uses 8 counters (all on a PCIe-6612) and nine tasks - including the AI task (PCI-6132) - all running concurrently during a DAQ.

I will try to answer each question.

1) The "GUI-initiated" pulse is actually on Ctr4.  The "continuous" pulse-train is on Ctr3.  Ctr3 and Ctr4 are related. External triggers (~1KHz) trigger a retriggerable pulse on Ctr1. Ctr1 is tick source for Ctr3 configured to divide-by-two( so, 1KHz Ext. triggers imply 1KHz on Ctr1, implies 500Hz on Ctr3).

Ctr4 will trigger (once) on the falling edge of Ctr3.

NOTE: The Ctr4 "Enable" initiates a pulse-train (on Ctr6) that goes to an external device to synchronize it with DAQ.  If our AI does N scans, we need to send N+1 pulses to the external device, the "+1" pulse occurs between Ctr4 rising and Ctr3 rising.   

2) Ctr4 is a single pulse.

3) See 1)

4) The AI task is finite

5) In an earlier product Ctr3 output was used by an external device.

    It's possible Ctr3 won't be needed (externally) anymore, though, I'd rather not make that assumption at this point. 

Thanks/Cheers!

[Kevin_Price · Accepted solution]

Let me make sure I'm with you.

The ctr4 single pulse task is started in response to a user/gui action.  It is configured to trigger off the next falling edge of ctr3 (driven indirectly by ~1 kHz external pulses, divides freq by 2 to output ~500 Hz).  The ctr4 pulse initiates a pulse train from ctr6 that's sent to an external device to keep it sync'ed with AI.

AI itself wants to trigger on the next rising edge of ctr3 that follows the initial rising edge of ctr4, roughly 500 usec later.

My first thought had been to just call DAQmx Start for the AI task in response to the same user/gui action that makes you now call DAQmx Start for the ctr4 pulse.  It would then trigger off the next ctr3 rising edge.  If not for the other syncing going on, this probably would have been fine.  The response time from a user/gui action until calling DAQmx Start *might* shift you from one cycle of ctr3 to the next.  If not for syncing, it kinda doesn't matter.  But with syncing, it's important that both ctr4 and AI are synced to the *same* cycle of ctr3, and that isn't guaranteed by just putting both DAQmx Start calls in parallel.

Perhaps you can use a DAQmx Trigger property for the AI task to get pseudo-hardware sync?  You mentioned the ~500 usec from ctr4 rising to ctr3 rising.  Whatever the exact #, I presume that's under your control via counter config, right?

So it seems to me that you could have AI trigger off ctr4 rising while configuring for that same delay value using the properties "Delay" and "Delay Units".  (They're under the DAQmx Trigger property node at 'Start->More->...')   So ctr4 rising becomes the actual trigger, but the delay value shifts sampling over so that it's *as if* you triggered off the next ctr3 rising.

-Kevin P

[550nm]

Hi Kevin,

I think your suggestion will work!

It's a great relief to have a solution to this problem.

Many thanks!

Cheers!

[550nm]

Hi Kevin,

I'm seeing

"

Code: -200436
DAQmx Start Task.vi:1

Possible reason(s):

Start trigger delay is not available when an external sample clock source is specified.

"

Any other ideas?

[Kevin_Price]

Didn't realize your AI task used an external sample clock.  Do you get that error even when you specify the delay in units of "Ticks"?   The enum values and help seem to draw a distinction between "Timebase Ticks" and "Sample Clock Periods", though I'm not certain what would be considered the timebase for an externally clocked AI task.

Another idea would be to let the finite AI task run off an internal timebase so you can set up the trigger delay in time units.  You'd probably need to get a scope involved to make sure the internally-driven AI sample clock pulses line up appropriately with the ctr6 pulses going to your external device.

  A more meticulous version of this idea would be to move the ctr6 function over to the AI card.  Then the counter pulses and the AI sample clock would be derived from the same internal timebase, and there'd be no chance they'd drift relative to one another.   I doubt this level of meticulous will make any real difference unless your finite AI has a fairly long duration.

-Kevin P

[550nm]

Hi Kevin,

Thank you for the additional ideas.  I probably won't get back to testing this, though, as I've implemented an ugly work around.

On the subject of DAQ-board counters: There are two, but I (previously) encountered errors when trying to use them.  Our system routes several signals between the counter-board and the DAQ-board connector (via RTSI cable).  These signals use the same DAQ PFI pins as the DAQ-board counters.

Thanks again for working on this.