Buffered counter read returns delayed data?

[RGA]

I'm using a buffered counter read on a PXI 6608 card to provide triggered quadrature encoder measurements. I'm using additional counters to generate a pulse train that triggers the DMA on the encoder counter. The pulse train output looks fine and happens at the correct times relative to the master trigger, so the DMA should be happening at the correct times.

The problem is (I think) that the data that I read from the buffer are delayed relative to the trigger that starts the pulse train and the DMA transfer. For example, if I start moving the encoder, then start the acquisition, the first data point returned is at a non-zero value - the counter should be reset at the start of the transfer and have a zero value. It's cle
ar from the trace that the data returned are missing the first part (how many depends on sampling rate, etc.). However, the CounterReadBuffer.VI does return the correct number of samples.

I've set the CounterReadBuffer.VI to return data "relative to start of buffer" but it looks like I always lose some data at the start. Is it possible that the DMA is not happening on the pulse train (I have verified that the pulse train is correct in duration and frequency)? It seems more likely that the buffering is getting messed up somehow.

In summary, it looks like the first value in the buffer is taken some time after encoder counter starts counting, so I'm missing the first part.

Any guesses on what's happening here?

Thanks,

rgames

[Shea C]

Hello RGA,

Thanks for your question about quadrature encoder measurements using counters on the 6608. It sounds like you�re loosing some data that you expected to be at the beginning. I don�t think that you are simply missing the first part. Without seeing any screen shots or simplified code I think it sounds like you might try changing the read/search mode in the Read Counter Buffered.vi. Also make sure that you don�t have an offset set to occur. If you have a simplified vi that demonstrates this it might help me understand the problem better.

Other resources can be found on the ni.com website by clicking the support tab at the top of the home page. Then search from Technical Resources at the top of the page for your topic. I hope these resources help! Let me
if I can provide any other resources for this issue.

Shea C.
Applications Engineering

[Kevin_Price]

Could there be either an error or an indeterminacy (i.e., a "race condition") in the configuration sequence?

It sounds to me like your encoder counter is getting armed and begins to track (but not save) position before the pulse train counter begins generating your acquisition clock.

As soon you arm/start the encoder counter, it starts to "pay attention" to any movements going on and keeps its internal count register updated. It doesn't begin to store buffered positions via DMA until the acquisition clock pulse train starts up, which may occur later.

It sounds to me like you may want to set up like this:

1. Configure both the pulse train counter and the buffered position counter to have triggering enabled. Be sure to feed the same trigger specs i
nto each config chain.

2. Make sure both are armed/started before the trigger signal can be generated. I find it helpful to use the error cluster to enforce dataflow-based sequencing.

If you set up this way, the encoder counter won't "pay attention" to motion until after it sees the triggering signal, so its value will be 0 at the time of the trigger (unless you've explicitly programmed it otherwise). That will also be the same instant the acq. clock pulse train is started.

Note: because there will be a finite time between the trigger and the first active edge of the acq. clock, your first buffered position value may not always be 0. But it'll probably be quite close. If you can live with a non-square acq. clock pulse train, you can reduce this finite time down to the sub-microsecond level, even for slow acquisition rates, by increasing the duty cycle of the the acq clock pulse train.

[RGA]

That makes sense - I was under the impression that the counter didn't start counting until the DMA transfer started.

Thanks,

rgames

[RGA]

One other question - is there an example that shows how to do triggered buffered position measurements?

I'm using a master trigger ported to RTSI 4 to start the pulse train and the encoder counters. However, when I try to use CounterSetAttribute.VI to assign "start trigger" to "RTSI 4" I get an error (invalid param ID). Is that the correct way to go about it?

Thanks again,

rgames

[Kevin_Price]

Unfortunately, I can't presently get at a LabVIEW 7 computer to verify what I know from v6. I'll try to post an example in the next couple days -- feel free to nag if I forget. 🙂

Anyway, I think your approach for the start trigger sounds fine -- you should be able to specify RTSI 4 as the triggering signal. Could the enum value "start trigger" you referenced be expecting a parameter such as "enabled" rather than "RTSI 4"? Double-check the extended help for 'Counter Set Attribute.vi' and dig down into other examples of triggering counter operations. There are several parameters to set when you configure for triggering.

Circa LV 5.1, NI released a new palette with some nice utility vi's for counter/timers, including one for configuring
triggering. I don't know whether LV 7 incorporates this palette by default or not, nor whether the old stuff can be installed into LV 7, but here's a link:

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/7e9396933ffbc87286256adf007536c8

Some of the files used to reside somewhere like:
"\examples\daq\counter\ni-tio.llb"
Maybe you can still find them there.

Good luck!

[Kevin_Price]

Attached is an example that ought to work. It started as a working app of mine, but I had to strip it way down to the essentials. I tried to be careful, but if it misbehaves let me know.

Note: there's only one subvi in the library that isn't from either the vi.lib or examples directory under the LabVIEW install directory. It's the dirt-simple utility named 'CTR cfg - counter num to group.vi' that I made a habit of using in *all* my counter apps to guarantee that I'd get a unique group # for each counter I programmed.

If you dig into 'Counter Start Trigger (NI-TIO).vi', you'll see the details you asked about. The way to specify what signal to use as a trigger is by using 'Route Signal.vi'.

Also, in the attached example you'll s
ee an answer to another question you recently posted -- the equivalent to 'AI Clear' is found by giving the 'reset' command to 'Counter Control'.

Happy counting!