LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

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?

0 Kudos
Message 1 of 8
(233 Views)

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

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 2 of 8
(195 Views)

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

Screenshot (102).png

Screenshot (101).png

0 Kudos
Message 3 of 8
(188 Views)

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

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 4 of 8
(178 Views)

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

Screenshot (109).png

Hasham622x_0-1726199194666.png

 

0 Kudos
Message 5 of 8
(141 Views)
Solution
Accepted by Hasham622x

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

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
Message 6 of 8
(127 Views)

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

Hasham622x_0-1726554418873.png

 

0 Kudos
Message 7 of 8
(42 Views)

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

 

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 8 of 8
(28 Views)