usage of quadrature encoder with M-series DAQ

[Kevin_Price]

Can you rephrase or expand?  I tried reviewing the thread and I'm not sure I know what measurements need to be kept separate.  I thought the main problem was to to synchronize tasks, 1 of which is analog input and the other of which is counter-based encoder position measurement.

-Kevin P.

[frankie_ger]

Sorry for the confusion. What I forgot to mention in my original post was that my thought was to let one NI card perform two parallell but unrelated measurements, each using an analog input and one counter input in the way i described in my first post. The input to the counters are two separate quadrature encoders.

The proposed solutions works fine if only one measurement is performed, but because two separate ones are performed, I can't rely on only one "change detection event", as I assume it is not possible to know from which of my two measurements the event comes?

/ Roland

[Kevin_Price]

Not sure you're going to be able to get there from here.  You can only have 1 hardware-timed AI task running at a time on an M-series board -- and using the change detection event counts as hardware-timed.  The only way to have 2 independent and simultaneous AI tasks is by using an on-demand software-timed scheme.

Also, you can similarly only have 1 digital input change-detection task at a time.

Best potential workaround I can think of:

A. Create 1 DI task that uses change detection.  Wire both channels of both encoders to digital inputs on port 0 and be sensitive to both rising and falling edges.

B. Create 1 AI task that uses the change detect event as the sample clock.  Include both AI channels of interest in the 1 common task.

C. Create 2 counter position measurement tasks for the 2 encoders that use the change detect event as the sample clock.

D. Sort out the extra data with some software post-processing.  Each sample taken will have been ultimately caused by either encoder 1 or encoder 2.  By tracking the changes in encoder value or DI bit states, you can determine which encoder caused each sample.  Then you can pay attention to the appropriate AI channel at that sample #.

E. Simple code will get you about 95% there.  Little gotchas that remain include: handling rare cases where both encoders changed simultaneously, and handling the very first sample where you can't easily determine which bit changed.  Also, be sure to start the AI and CTR position tasks before starting the DI task.  This way, all the tasks depending on change detect events will be armed and waiting before any changes are detected, thus ensuring that their samples will be in sync.

-Kevin P.

[frankie_ger]

Thanks Kevin. My backup plan is to trigger both the analog and the counter tasks on the edges of each encoder (which is connected through an LS interface circuit).

This will give me hardware timing, but I will have the problem that the tasks are out of sync when they start as each startTask() call takes some time. However this can *almost* be solved by starting the CI task before the AI task, then checking how many samples were read on the analog and counter task the very first time (I have a while loop where both buffers are read). I then remove any extra counter samples as the CI task began before the AI task, and those samples are from before the AI task started.

There will still be a small sync error though, because the two sequentital reads will be separated a bit in time. However as the frequency is moderate (5 kHz), only one or two encoder ticks passes between the reads() and that is an acceptable error for this application. Thanks for all help gain!

/ Roland

[Kevin_Price]

Not sure exactly what kind of interface circuit you're thinking of, but I think you've fundamentally got a constraint at the data acq board -- only 1 hardware-timed AI task can run at a time.   You'll be sampling both channels each time you would ideally only care to sample one of them.  Then, in order to correlate the encoders, I think you'd also need to sample both of them with each analog sample.  I can't think of a way around this.

So, any way you slice it, I think you'll still be stuck with some software post-processing.  Also, be aware that when you use the encoder signals as your sampling clock, you really don't have any true timing information in your acquisition.  If both encoders come to a full stop for a long time and then start moving again, you won't know that from the data.  The data only shows what's out there at the instants that the encoders make transitions without regard to the time between transitions.

-Kevin P.