Can I use APFI0 hardware trigger as external clock in NI-6255 Mass termination for retrigger approach

[Hasham622x]

Hi All,

First of all, I apologize for any inconvenience. I am currently using the NI-6255 MT and attempting to capture a set of signals from multichannel inputs with each trigger pulse. For the hardware analog trigger, I used APFI0 at a 360 Hz signal with a falling edge. I set the sample clock to the onboard clock with finite samples, two samples per channel, and a sampling frequency of 48 KHz.

Ideally, this setup should complete within 1 second to collect 360 samples from the AI channels, but it's currently taking around 5 to 6 seconds, which is five times longer than expected. I introduced a "Control Task Commit" status, which brought the run time down to the mentioned 5-6 seconds. Before that, it was taking 20 to 22 seconds to collect 360 samples using a retriggerable approach.

I’ve attached the LabVIEW (LV19) version of the code. Could you please advise if there's any way to further reduce this delay, as I’m still experiencing longer run times than expected?

[Kevin_Price]

Though you've reduced the Stop / Restart overhead by committing the task prior to the loop, you haven't *eliminated* it.  You're also only reading 1 sample per trigger in your loop rather than the 2 you say you want.

The best way to approach this is to retrigger in hardware rather than in software.  A newer X-series device would natively support hardware retriggering of an AI task, but your older M-series device doesn't.  There's a workaround (see this example) that uses a retriggerable counter pulse train as the AI sample clock, but that will only work for a digital trigger signal.

I don't know for sure what your specific device does and doesn't support, but here's a method that has worked for me in the past.  Modify the linked code as follows:

- configure the AI task for an analog edge trigger, just as you've been doing in your own code

- for the retriggerable counter output task, set the trigger source to be the device's "Analog Comparison Event".  (You may need to right-click the terminal constant, choose "I/O Filtering" and include "Advanced Terminals" to get access to this internal digital signal)

With the analog signal started, falling edges should be noticed by the analog trigger circuitry and generate an internal digital pulse known as the "Analog Comparison Event".  This retriggers the counter to generate its 2 pulses per trigger which the AI task uses as its sample clock to capture 2 samples per trigger.

  All these samples get buffered up, so you can just wait and read your 360 samples all at once, knowing that they represent 2 samples each from 180 distinct trigger events.  180 triggers at 360 Hz means the task should complete in 0.5 seconds.

-Kevin P

[Hasham622x]

Hi,

Thanks for your reply and guidance. I tried this example by using guidance which you shared but it is not running give errors...

If you dont mind could you please guide me on this point "for the retriggerable counter output task, set the trigger source to be the device's "Analog Comparison Event".  (You may need to right-click the terminal constant, choose "I/O Filtering" and include "Advanced Terminals" to get access to this internal digital signal)" 

Kind regards

Hasham

 

 

[Kevin_Price]

I made a few mods to your code in-place.  Give it a try.  Notes:

- counter task changed to digital triggering, looking for the device's Analog Comparison Event.  (Note: check the syntax on this terminal, I had to type it out longhand since I don't have any attached devices that support analog triggering)

- analog task changed to finite sampling, based on # triggers times samples per trigger.

- removed the loop around DAQmx Read because of change to finite sampling.  Now DAQmx Read is simply called once to read all samples, no more loop

- removed sequence structures and used error wires and dataflow to enforce sequencing where important.  Counter task is started first, but is waiting for Analog Comparison Event as a trigger.  Then AI task starts which will activate the analog trigger circuitry and allow an Analog Comparison Event pulse to occur.  This pulse in turn triggers the counter task to generate the 2 pulses that act as a sample clock for the AI task.

-Kevin P

[Hasham622x]

Hi,

First of all, thanks for your reply. I ran the code as earlier, and it was giving an error for a counter for the sample clock "Retrigger able counter", for which when I selected Dev1/freqout then, I did not get the same error. After that, I got this error, and again, I got the same error.

Kind regards

Hasham

 

[Kevin_Price · Accepted solution]

Ok, my mistake on the first part.  I used MAX to create a simulated 6255 and found where I went wrong.  The trigger source for the counter task should be "/Dev1/AnalogComparisonEvent" rather than what I previously typed out long-hand ("/Dev1/ai/AnalogComparisonEvent"). 

The drop-down selection on the front panel could probably have steered you toward the correct syntax.  Take a little time to explore the options for future reference, especially when right-click for I/O Name Filtering and include Advanced Channels.  It's sometimes also handy to check the Limit To Device box.

-Kevin P

[Hasham622x]

Hi,

First of all, I apologise for the delayed response, and I want to thank you for your guidance. I applied your suggestions to the code, and it is now running and successfully capturing data. I set the analog trigger level to 0.8 V with a falling edge trigger. However, the captured values range continuously from -5 V to 1.2 V, even though they should be below 0.8 V.

I also tried to connect the timer in the code, but it is not working.

Kind regards

Hasham

[Kevin_Price]

I'm pretty limited in what I can speculate from here.  Mainly I can suggest some troubleshooting steps to try and have you report back some detailed observations & results.

1.  First let's explore AI capture and triggering on their own.  Go back to the shipping examples and do an analog voltage continuous acquisition, both with no triggering at all and then with your analog start trigger parameters. 

    Try them both with your normal signal (which should cause triggering to succeed) and also with a channel wired to AGND (which should cause the triggered example to timeout waiting for trigger conditions that never happen).

2. If you get triggering success with your normal signal, bring up a Counter example for counting edges.  Configure it to count the "/Dev1/AnalogComparisonEvent" signal.   Start it first.

    After the counter example is running and showing a constant 0 count value, start up your analog acquisition example using your normal signal.  Even though the analog task only reacts to the first analog trigger event, you should see that the counter keeps incrementing as the triggering circuitry keeps noticing additional trigger conditions.

-Kevin P

[Hasham622x]

Hi,

First of all, I apologize for the delayed response. Thank you for your guidance. I tried the example of continuous analog voltage measurement. Initially, I used analog trigger parameters with the sample clock source set to "Onboard Clock," where I received continuous values (ranging from 1.0 V to 0 V) after the trigger, which I had set to 1.0 V.

In the next step, I changed the sample clock source to "Dev1/Analog Comparison Event" with one sample per channel (sample mode "continues sample") and was able to capture values close to the trigger point. This method was fast enough to capture all data points near the trigger value. I also tried the finite samples voltage example by switching the clock to "Dev1/Analog Comparison Event" I set total samples for which I needed 100 samples/channel and sample mode "FInite sample", and it successfully captured values based on the trigger level.

However, the re-triggerable finite code still exhibits the same behaviour that I previously shared with you.

I've attached the code in which I’m trying to measure the total run time. Since this version does not use a loop, I attempted to use timestamps but was unable to get the correct values.

[Kevin_Price]

I've mainly been around a LV2020 system and couldn't look at the finite re-triggering code again until now.

Looks to me like you may need to change the trigger polarity for the counter task from Falling to Rising (which was, BTW, the polarity I had originally set when I first posted the example back in msg #4).

The "Analog Comparison Event" is an internal digital signal that pulses or toggles when the analog triggering conditions are satisfied.  The polarity of this internal digital signal is independent of the polarity setting for the analog task trigger.  Sometimes it's necessary to do experiments to figure out when these internal signals are active high vs. active low so that you know what polarity to configure.  Changing your counter trigger polarity from falling to rising is just such an experiment.

-Kevin P