Quad Encoder as External Sample Clock

[steorn]

Hi,

We want to use a Quad Encoder as the sample clock for 6 Analogue Inputs. In brief, we want to make one sample per Analogue Input everytime the Encoder detects an angle change. In theory, as the encoder will always be rotating in the same direction, we should only need to route the A (or B) signal of the encoder to the Ext Clock source of the 6 analogue inputs.

We would also like to connect the same Quad Encoder to a Counter and thus be able to determine rotational position, again I see no problems here in theory.

My real question is how to buffer the samples...for example, a 14400ppr encoder rotating at 11 revolutions per second would result in the generation of 158400 samples for each of the analogue inputs, approximately 1million samples in total. We would like to read this buffer every second. Is this possible ?

I've read a lot on the subject and am a tad confused as to how to set up the task and channels such that a single sample will be aquired per Analogue Input for each encoder sample clock signal. 

Any clarity that could be shed on this would be greatly appreciated.

Many thanks,

Shaun.

[steorn]

Looking into this some more it seems we have two solutions. We're useing a PCI-6259 DAQ card so we could

A) Create a Digital Input task to detect either rising and/or falling edges of the Quad Encoder's A and B outputs. Then use the resulting "change detect pulse" as the sampling clock by specifying the "ChangeDetectionEvent" as the AI source sample clock via a call to DAQmx Timing.

 Question is, what resolution would we get from a 14400 pulse per revolution quad enconder. I've also read somehwere that the max rate of the "change detect pulses" is 5MHz, is this correct ?

B) Use the Quad Encoder's A or B signal as an "External Scan Clock".

Again what resolution could we hope for with a 14000ppr Quad Encoder..1/4 ?

And finally, how should the buffer be managed such that all six analogue inputs can be sampled per intermittent sample clock such that we only have to perform a read every second. I find buffer management in this regard a little confusing in the official NI docs.

Again, any input here would be greatly appreciate....and if this is the wrong topic to post thne please advise which topic would be best.

Thanks in advance,

Shaun.

Message Edited by steorn on 10-10-2007 08:19 AM

Message Edited by steorn on 10-10-2007 08:21 AM

[Kevin_Price]

Shaun,

Apologies in advance for the second-guessing here.  It's fairly common around here that there'll be a posting where someone describes a fairly difficult / complex task they're trying to do.  After a couple rounds of questions, it then turns out that a much simpler approach is actually quite acceptable.  I just want to check this part out up front here.

So, do you really definitely need to sample those analog signals at >100 kHz?  Are they providing useful dynamic information at a high enough bandwidth to justify the need to handle >1 Meg/sec of samples?

That kind of data rate should surely be do-able, but is getting into the realm where you'll need to be more careful and deliberate about the details to make it robust.  If all that extra information is truly valuable it'll be worth it, but if not -- maybe not.

A. A 14400 ppr encoder *probably* means you get 14400 quadrature cycles per rev on both channels A and B.  In which case, you could resolve up to 57600 incremental positions per rev.  Not everyone uses the terminology consistently though.  It might mean a maximum resolving capability of 14400 positions, which would imply 3600-cycle/rev quadrature.

    The 5 MHz rate limit for the change detect pulse sounds familiar, but I couldn't say with 100% certainty.

    The general idea of setting up a change detection task is the only way I know of to produce a pulse at each quadrature position.  A good plan if you need to gather position-correlated data at the maximum possible rate.  Bear in mind that for most encoders, the increments within the 4 quadrature states will likely vary in size considerably more than say, one rising A to the next rising A.  So you may find that the issue of unequally-spaced samples is more trouble than its worth.

B. Using either the A or B signal as an external scan clock is probably a simpler approach.  It leaves open the option of using a counter to divide this down further by some integer if you wanted to reduce your sampling and data streaming rates.

   As to the buffering, you should be able to configure your data acq buffer to be several Megasamples in size.  Big enough to hold several seconds worth of data.

-Kevin P.

[steorn]

Hi Kevin,

Glad you picked this one up as i've read a lot of your posts before and feel you have a good knowledge base to help.

Lets start with teh encoder, it can produce 14400ppr in Quad mode (3600 normally). Its max operating speed is about 2000rpm. We're looking to get as good a resolution as possible and, as such, could opt for a 40,000ppr encoder in quad mode if desired. But lets run with the 14400ppr for now and please assume we do need to sample at every pulse as this will provide us with more dynamic visability.

So we're looking to sample the 6 Analogue Inputs 14400 time every revolution, up to a max speed of 660rpm (i.e. 11 revolutions per second). Thats a total of 158400 * 6 samples per second (i.e. 950400 samples in total)

If we use a change detection task then it should produce a pulse for each one of the 14400 encoder pulses - is this correct ? We only want one sample from the 6 Analogue Inputs at the occurance of each pulse - effectively providing us with position stamped samples. We also want to connect the encoder to a counter so we can determine angular position. Again i can't see a problem with this but perhapps you can ?

As you suggest, the alternative is to use A or B as the external scan clock, effectively providing us with one sample from each of the 6 Analogue Inputs for each rising edge (or falling)  of A (or B).

My buffering concern is not so much the size but how to read it. We develop in C using LabWindows/CVI and we want to be able to read the buffer every second to avoid software timing issues (Windows XP OS being what it is). So how can we read the buffer (a max of 950400 samples) every second without losing a single sample. My confusion lies with how this buffer is managed.

A further requirement is to timestamp these samples...and i'm afraid I have no Idea how to achieve this yet. I believe we could settle for just using the timestamp of the encoder pulses and ignoring the real world delta time that will exist between each Analogue Input sample. But it would be cool if we could actually time stamp every sample.

Again, thanks for getting involved on this. Please let me know if anything is not clear. In the meantime i'm drilling through the forums to try and shed more light on this.

Cheers, Shaun.

[steorn]

Hi Kevin,
We've had a bit of a requirements change here. We've decided to use the A channel as the scan clock and we intend only to sample on rising edges up to a max of 3600 times per revolution (i.e. imagine 3600ppr). Therefore we'll be generating 3600 * 6 samples per revolution (i.e 21600) which, as our PXI card max sampling freq is 1M sps, allows us to run thesystem at a max rotational speed of 2777 rpm.

During one second then we'll be aquireing, and hence hoping to read, 999720 samples per second. Its pretty much the same scale of samples as I previously mentioned, just a different way of getting there. Each sample will thus be position stamped each 0.1 degree.

All well and good so far but the issue of buffer management and timestamping still exist. Hopefully, both these posts will help clarify our question better.

All the best, Shaun.

[Kevin_Price]

Thoughts in no particular order:

You may want to wire your encoder A,B into digital port 0 and use change detection anyway.  Then you can easily change your sampling basis by choosing which DI line changes to detect.  If rising and falling on both A and B, you get a sample for each quad position.  If rising only on A only, you get your latest plan -- lower position resolution, higher rotation rates supported.  This approach would make it fairly easy to switch back and forth at run-time though since all the underlying code would be the same.

Another subtle (potential) advantage: You can config your sampling to be sensitive to the trailing edge of the change-detect pulse.  This makes sure that the encoder edge which caused the change detect pulse to fire will have also caused the counter register to increment/decrement before sampling occurs.  Using an encoder edge directly as a sample clock for an encoder-measuring task risks a hardware race condition -- is the position count buffered before or after it increments (decrements)?

Timestamping:  You've used up one counter to measure the encoder position, but you can use the other counter to timestamp the change detect pulses.  There's more than one way, but I would configure to count edges of the 80 MHz internal timebase while using the change detect pulse as the sample clock.  That gives you a direct measure of cumulative time.  (Sorry, no help on syntax as I only use LabVIEW). 

Note: the counter measurements may be an overall system bottleneck.  They will demand near-continuous access to the PXI bus to push data from the board to system RAM because the board has only a 1-or-2 sample FIFO on board.

Buffer Management:  Under LabVIEW, I would read from the tasks and send the data directly to a Queue.  Some parallel code could then read from the queue and do whatever else (display?  store to file?).  I'm not sure what to suggest for CVI.  The real key is to create a producer-consumer architecture with parallel code loops.  Run your data acq with high priority as the producer, shuffling off the data from the NI-managed data acq buffer into a you-managed buffer.  Run 1 or more consumers at lower priority that pull data from the you-managed buffer and display it, store it, whatever.

Under LabVIEW, parallel code is not only easy to create, it's almost hard to avoid.  NI's "Queue" primitives work very well for this kind of producer-consumer pattern.  Dunno what you've got available for CVI.

If you only want to service your data acq loop once per second, I'd recommend sizing the data acq buffers for at least 3 seconds of data.  However, I'd be even more inclined to service the data acq loop 5-10x per second with maybe 1 second of buffer.  This would reserve more memory for the you-managed buffer which, at lower priority, is more likely to need it.  You could then choose to service the you-managed buffer at a slower rate (while extracting larger chunks at a time) if you want.

-Kevin P.

[steorn]

Thanks for all your input Kevin.

The small FIFO size is indeed a concern but i'm hoping DMA can handle it sufficiently. Although we're generating 999720 samples per second, if we ignore the delta time difference between each of the 6 AI samples then we really only need to timestamp the encoder changes. So we'd effectively need to shift 166620 counter values per second. From looking at some of the knowledge base articles on NI it would appear we're pushing it a bit but then a lot of these articles are out of date, i.e. tested on a Pentium III 500MHz with 128 MB etc. I've read buffered event counting rates of 150 to 200Khz so we might just be okay.

In CVI we can use core threads to execute the buffer reads in paraelle. The board has an on-board mem of 4095 samples so I assume it will only push these to the PC RAM buffer when nearly used up, i.e at a max of 999720 samples a second it should transfer on-board mem contents say 250 times a second. The question now is will this interfere with the DMA shifting of counter values mentioned above.

Its effectively this area of DAQmx that confused me.....oh well, back to trawling the docs and forums again.

Message Edited by steorn on 10-12-2007 09:11 AM