Finite Retriggerable Analog Input Using LabVIEW with DAQmx

[John_P1]

Overview
This VI allows you to perform retriggerable analog input with E or M series DAQ devices.

Description

One limitation of E and M Series DAQ devices is the inability to natively perform retriggerable analog input. One workaround is to generate a retriggerable pulse train that you can use as a sample clock for a continuous Analog Input task.  This example shows how you may use the two on-board counters of an E or M Series device to generate a retriggerable pulse train to be used as the sample clock for the Analog Input task.

Requirements

• LabVIEW 2012 (or compatible)
• DAQmx 9.5.5 (or compatible)

Steps to Implement or Execute Code

1. Pick Physical Channel(s) and enter the required parameters
2. Run the program and the retriggerable analog input will be shown in the graph

Additional Information or References
VI Snippet

**This document has been updated to meet the current required format for the NI Code Exchange.**

[ThomasAUNCC]

John,

I am using an USB-6210 and was referred to this document in order to complete a task that I am attempting.  I would like to be able to use a rotary encoder I have as a digital trigger for several analog channels.  I have been told that this is not offered directly on the USB models but it seems that you're workaround above may help.

I am confused about a few things (I am a novice when it comes to LabVIEW):

What should I put in as the AI Sample Clock and the Counter Sample Clock?

If I only want to take one sample when my encoder sends a pulse do i need to worry about the frequency value (I want the sample as close to the pulse as possible)?

Thanks,

Thomas

[John_P1]

Hi Thomas,

I added a screenshot of the front panel that should hopefully help clarify.  The AI sample clock source should be the internal output of whatever counter you are using to generate the retriggerable pulse train.  The counter sample clock is set to "Implicit" meaning that there is no actual sample clock, but rather as soon as one pulse is completed the next pulse will begin immediately generating (the task is "implicitly" clocked by its own pulse width characteristics).  The trigger of the counter task would be whatever PFI line you want to connect your external triggering signal to.

If you only want to take one sample when your encoder sends a pulse, you shouldn't need this example--instead just use an External Sample clock shipping example.  For instance "Cont Acq&Graph Voltage-Ext Clk.vi" should be a good starting point.  You could just use the encoder pulses as the sample clock.  You can find this example from LabVIEW by navigating to Help » Find Examples, then go to Hardware Input and Output » DAQmx » Analog Measurements » Voltage

The example attached here is more useful if you want to re-trigger multiple samples of acquisition off of an external signal.  For single-sample acquisitions just use the external signal directly as a sample clock.

[PaulRijk]

I was pointed to this document because I had problems with retriggerable readings.

Indeed, the suggestion here solves the problem.

BUT, Why is the first sentence in this article ("One limitation of E and M Series DAQ devices is the inability to natively perform retriggerable analog input") not the first sentence of the manual and specs of the DAQ device ????

That should have saved me for days of trial&error !!

Paul

[John_P1]

Glad the code helped, and sorry you had to go through several days of trial and error before finding it.  One good resource NI has if you ever run into problems like this in the future is the discussion forums (link) which are free for anybody to use.

I guess as far the documentation goes, it's typical that most things not mentioned in the manual are not supported by the device.  For example, E Series cards don't support PFI filters on the digital lines, but it is not explicitly mentioned in the manual.  E/M Series don't support sample-clocked, buffered counter output tasks, but again this isn't called out.  To keep a more concise manual the policy is generally to stick with what is supported by the device in the manuals.  If in doubt, it's always a good idea to ask!

Best Regards,

John

[christophe.A]

This code was really helpful to understand multiple errors of my M Series DAQ Device.

But what is the difference between that example and Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi (DAQmx Examples) ?

It seems to me that they do exactly the same and I don't see why it needs to buffer data.

One more thing : why do I see everywhere that we need 2 counters to achieve the functionnality ? I guess it is one for digital trigger source (CTR n GATE) and the second one for generation (CTR n' OUT).

Regards,

Christophe.A

[John_P1]

Hi Christophe,

Both examples are similar, this one just uses the DAQmx default buffer sizes depending on your specified sample rate (unless the default is less than the size of your acquisition, in which case the buffer will be the size of your Samples per Trigger).  The shipping example explicitly configures the buffer to be the length of your finite acquisition + 1000 samples.

The shipping example also uses a DAQmx event (Every N Samples) to initiate the read.  Whereas this example just tries to read immediately and will timeout if no trigger occurs.

So, in practice both pretty much do the same thing.  I think I made this example originally because it demonstrates the bare-bones of what you need to configure in order to use the counters to implement retriggerable analog input.  The shipping example does the same thing but it has some extra stuff that may or may not be desired depending on your application.  I do like using DAQmx Events in general, but I don't think it's necessary in this example snippet which was intended to show how to use the counters to perform retriggerable analog input.

Finite counter output on older DAQ devices (M Series for example) requires the use of both counters.  Internally, one counter generates a gating signal for the other one.  On X series and the newer cDAQ chassis (not the 9172) this is no longer necessary.  The counters on these devices actually have a paired internal counter to generate the gating signal which is transparent to the user.  Then again, on X Series Analog Input is natively retriggerable and doesn't require the counter workaround at all.

[christophe.A]

Thanks for answering.

I still have difficulties to understand the 1 or 2 counters thing. In your program, I don't see any property node linking the CTR0-GATE to CTR1-SOURCE. Do I have to understand that it only needs 1 counter or that the operation is transparent ? I guess that on older devices i will have to add a bit of code to link the 2 counters, indeed?

And can I choose Digital trigger source as PFI0, counter retrigerrable as ctr0 and counter ouput as ctr0-InternalOutput ? All signals I need on the same counter. I am asking this because your example show ctr0 for the generation and PFI3 for the digital trigger source, which I understood first as the use of the 2 counters.

Christophe

[John_P1]

Hi Christophe,

The driver configures the 2nd counter in the background so the operation is transparent to the user.  The same code should run on both old and new hardware, and will only error on old hardware if you are using the 2nd counter for something else.

The PFI lines are actually interchangeable on M Series, so you can pick whatever one you want.  The counter you use (e.g. ctr0) should be the same as the internal output that you are using for your AI sample clock (e.g. ctr0InternalOutput).

Best Regards,

John

[Bauch@Berkeley]

Hi John_P1,

this VI is great. I have two questions, would be great to get some input:

1) Is there a specific reason why the sample clock for AI is continiuous? I would like to acquire a fixed number of samples and would just change the mode to "finite" and then connect the number of samples accordingly.

2) Do the input trigger pulses need to be spaced equidistantly? I have some problem with this VI and suspect the trigger to be the culprit, that comes in at varying times.

Thank you so much,

Erik