Start counter out when AO rises to specific level. Error -200077 on Start Trigger (Analog Edge)

[TeraTech]

Is it possible to delay the start of a counter output until it receives an analog trigger level? I have an application with two outputs. The first is a custom AO waveform and the second is pulse using a counter output. I need to start the AO first then start the counter output when the analog output signal rises to a specific level. The counter is in continuous output mode. I am using a USB-6363, in case that impacts the available functions and/or properties. I tried using the DAQmx Start Trigger (Analog Edge) vi on the counter task but I get this error:

Error -200077 occurred at DAQmx Start Trigger (Analog Edge).vi:7160001

Possible reason(s):

Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.

Property: Start.TrigType
Requested Value: Analog Edge
Possible Values: None, Digital Edge

Task Name: _unnamedTask<1A2>

[Bob_Schor]

 Hello, @TeraTech.  You've been using the Forum long enough to know better than to ask a question such as your posed without providing us "necessary information".

Please supply:

• Details on the DAQ device (model, settings).  Note that I've no experience with the USB-6363 ...
• Relevant VIs (best is entire Project) saved for LabVIEW 2019 or 2021.
• Better description (with details and specific values) that you'd like the code to accomplish.

Bob Schor

[Kevin_Price]

You *cannot* configure a counter task to use an analog trigger directly.  But there are indirect ways...

1. Since you're the one generating the AO signal, you could pre-compute the timing offset from the beginning of AO generation until you want the CO pulse train to start.  Set this value as the "initial delay" for the counter pulse train and trigger both tasks off a common signal, making sure both are started before the trigger can assert.

2. You can "borrow" an internal signal by adding a dummy AI task that uses analog triggering and looping back your AO output to an AI input.  The signal in question is the "analog comparison event".  When the analog trigger conditions are satisfied, it asserts an internal *digital* pulse which the CO task can use as a digital start trigger.

    When specifying the terminal for the CO start trigger, right click the terminal constant for the trigger source and select "I/O Name Filtering...".  Then you can check the box to "include advanced terminals" so you'll be able to find the analog comparison event.

3. You can also accomplish #2 without physical wiring.  Again, right-click the AI channel terminal to include internal channels and you can choose something like "Dev1/_ao0_vs_aognd".  This lets you do an internal loopback without messing around with your wiring setup.

-Kevin P

[TeraTech]

---

@Kevin_Price wrote:

You *cannot* configure a counter task to use an analog trigger directly.  But there are indirect ways...

1. Since you're the one generating the AO signal, you could pre-compute the timing offset from the beginning of AO generation until you want the CO pulse train to start.  Set this value as the "initial delay" for the counter pulse train and trigger both tasks off a common signal, making sure both are started before the trigger can assert.

2. You can "borrow" an internal signal by adding a dummy AI task that uses analog triggering and looping back your AO output to an AI input.  The signal in question is the "analog comparison event".  When the analog trigger conditions are satisfied, it asserts an internal *digital* pulse which the CO task can use as a digital start trigger.

    When specifying the terminal for the CO start trigger, right click the terminal constant for the trigger source and select "I/O Name Filtering...".  Then you can check the box to "include advanced terminals" so you'll be able to find the analog comparison event.

3. You can also accomplish #2 without physical wiring.  Again, right-click the AI channel terminal to include internal channels and you can choose something like "Dev1/_ao0_vs_aognd".  This lets you do an internal loopback without messing around with your wiring setup.

-Kevin P

---

Below is my first attempt, thus prompting the original post.

Kevin_Price, I think I understand, you cannot configure a counter task to use and AO trigger but you CAN configure a counter task to use an AI trigger. So this then allows me to wire my AO to an AI and use the AI trigger, correct? Does option 3 dummy AI task still take up a physical DAQ AI input pin? In other words that AI channel would no longer be available for other purposes/tasks elsewhere in my application?

After digesting your response, I altered my test vi attempting option 3. Progress! But the counter out (CTR0) still starts before the analog out (AO0) rises.

[Kevin_Price · Accepted solution]

The single trigger property wasn't enough to fully configure triggering for the counter task.  Also, the AI task should be triggered by an analog signal level.  The Analog Comparison Event is a digital *result* of the analog task evaluating its analog trigger condition.

I made only minimal mods to illustrate with comments in cyan.

-Kevin P

[TeraTech]

---

@Kevin_Price wrote:

The single trigger property wasn't enough to fully configure triggering for the counter task.  Also, the AI task should be triggered by an analog signal level.  The Analog Comparison Event is a digital *result* of the analog task evaluating its analog trigger condition.

I made only minimal mods to illustrate with comments in cyan.

-Kevin P

---

That works great! Thanks for clarifying and the marked up VI. 
(AO=yellow, CTR=blue)

[TeraTech]

---

@Kevin_Price wrote:

You *cannot* configure a counter task to use an analog trigger directly.  But there are indirect ways...

1. Since you're the one generating the AO signal, you could pre-compute the timing offset from the beginning of AO generation until you want the CO pulse train to start.  Set this value as the "initial delay" for the counter pulse train and trigger both tasks off a common signal, making sure both are started before the trigger can assert.

-Kevin P

---

@Kevin_Price, one more question on the implementation of Option 1:

You mentioned "trigger both tasks off a common signal".  However, I'm at loss as to which signal to use.  There are many options for the trigger source of the DAQmx Start Trigger.vi such as OnbboardClock, various frequency TimeBases and reference clocks. Depending on which I choose, the actual delay varies (as seen on my o'scope). 

 

[Kevin_Price]

When possible, I like to be the one that generates the trigger signal so that I can be sure all my other tasks are started and ready for it before I assert it.

With your X-series device this will be pretty straightforward.  Create a simple software-timed DO task that uses a single digital line, such as "Dev1/port1/line0".   Make sure you choose a digital line that performs double duty as a PFI pin!  Often this just means to use port 1 or port 2 rather than port 0 (which is often the only port that supports hardware-timed DIO and often doesn't support PFI-style signal routing options).

Your AO and CO tasks will configure their trigger according to the PFI pin designation.  For the sake of discussion, let's set it for rising edge polarity.  Then you will need to enforce the following sequencing:

1. Start your DO trigger signal task and set the line to Low.

2. Then start both your AO and CO tasks, which will now be armed and looking for a Low->High transition.

3. Generate a pulse by setting the DO line to High and then immediately back to Low.  You can now stop and clear the DO task because your AO and CO will be triggered and sync'ed.

-Kevin P

[TeraTech]

Thanks! I see how that's better, but then I still need a third DAQ terminal. 🙂 Is there no way to the syncing without taking up a physical terminal? Option 1 uses a DO terminal and Options 2 & 3 use and AI terminal. 

[Kevin_Price]

A tweak to option 1 is to generate the triggering pulse with a 2nd counter task.  Then the other tasks would specify a trigger source like "/Dev1/Ctr1InternalOutput".

You can then *also* explicitly set this helper task's output terminal to be a null string "", and the signal won't tie up a physical wiring terminal.  You'll still use up an internal counter channel resource, but no terminals.

This is actually true for option 3 as well.  No physical wiring terminal is needed when you use the internally routed "_ao0_vs_aognd" channel for the AI task.  You still use up the AI subsystem though.

-Kevin P