Continuous analog sampling on an encoder edge, with alignment to an index pulse

[murpia]

Can someone help with the correct setup for continuous analog sampling on an encoder edge, with alignment to an index pulse?

Here's the current setup (programmed in C# based on "NI-DAQmx: Continuously Acquire Voltage Samples Using External Clock in .NET" example).

The machine has a 360 count encoder with an index pulse is wired so the 360 pulses are the sample clock and the index pulse is the start trigger. Buffer size set to 360. The first sample set works OK, the sampling is triggered and my C# callback is called once the buffer has 360 samples. The encoder shaft is rotating at 3000rpm so the sample clock runs at 18kHz and the callback is 50 times per second.

I want to immediately start another acquisition with no delay, using the index pulse to ensure my 360 sample buffer is always aligned with the rotation of the machine.

Calling AnalogMultiChannelReader.BeginReadMultiSample inside the callback results in the acquisition skipping a rotation until the index pulse comes around again. So my acquisition is not now continuous but every other rotation. How do I fix this? Do I need to change the start triggering method of the task somehow?

Thanks, Ian

[JamesC]

Hi Ian,

The skipping of one rotation is expected behaviour as it takes time to rearm the trigger.

As you have code that works at the moment to take 1 revolution of data (360 pulses) just turn that to a continuous acquisition, where you use the index pulse to start at a known point. You are then doing a HW timed acquisition on the data linked to the rotation speed of the shaft. Therefore you know every 360 sample is the index pulse again, so you can apply post processing maths to work out number of revolutions and so on.

Regards
JamesC
NIUK and Ireland

It only takes a second to rate an answer 🙂

[murpia]

Hi James,

Thanks for your reply, in the meantime I reconfigured the acquisition in a similar mode to your suggestion. I use a buffer of 360 samples and load each buffer into a separate waveform for post-processing.

This works OK, but I am concerned that any glitch on the encoder signal will put my acquisition 'off' by an encoder edge and cause drift over time. The electrical enviroment is quite noisy. The ideal scenario is as follows:

Acquisition is started by encoder index pulse.

Acquisition sampling is done on the encoder edge signal.

On the next encoder index pulse we should have 360 samples.

If we have a different number a glitch has occurred and we reject that set of samples.

If we have a glitch, we need to restart the acquisition on the encoder index pulse.

Any way I can think of to do this means we would lose 2 full rotations of data on a glitch, the rotation with the glitch and the next rotation while we wait for the next index pulse. Any suggestions?

Regards, Ian

[John_P1]

Hi Ian,

Just a couple of questions:

Which hardware are you using?

What is the phase difference between your encoder and Z Index pulse?  Do you have A and B signals to work with?

The answers to the above questions will tell us the best way to go from here.  One thing you might consider (if using a 660x, M Series, or X Series board) is to use digital filtering to eliminate glitches.  You can refer to your device documentation for more information.

Best Regards,

[murpia]

Hi John,

The hardware is a USB-6211. We may consider an upgrade, but it must be USB for portability.

The encoder is fully featured with 6 TTL output channels: Index, A, B and Index_Bar, A_Bar, B_Bar (inverted). According to the datasheet Index is edge aligned with the B channel, and the Index pulse width is 25% of period (i.e. 50% of A or B pulse width).

Looking at the timing, it's feasible to set a start trigger for the acquisition using +ve edge of either Index or Index_Bar.

We currently run the system at speeds up to 4000rpm, so the frequency of the encoder signal is 24kHz. However, in the future we may want to go faster, even up to 12,000rpm which would be equivalent to 144kSamples/s (we acquire 2 analog channels).

I will look into digital filtering the signal.

Thanks, Ian

[John_P1]

Hi Ian,

The M Series boards do not have re-triggerable Analog Input, so unfortunately the time it would take to re-arm the acquisition in software will be too long.  From the rising edge of A_Bar to the rising edge of Index you have 3/4 of a period of your signal, which would only be 5.2 us in the 144 kHz case (31.25 us in the 24 kHz case).

If you're going all the way up to 144 kHz, the only filter setting that you could use would be the 125 ns setting (guaranteed to pass 125 ns, guaranteed to reject 100 ns).  This should give you noise immunity for any glitches less than 100 ns.

I can think of a workaround using the counters but it is not quite as straightforward as running a shipping example:

1.  Configure a buffered period measurement of the index line.  Measure the period in terms of ticks of one of the encoder lines (e.g. rising edges of A)

2.  Configure "implicit timing" for the period measurement.  This means on every rising edge of of the index, you will sample the amount of ticks that occurred since the last rising edge.

3.  Use the value read from the Counter task to tell your DAQmx Read (for a Continuous AI Task) how many samples to acquire.

Steps 1-2 should be enough to tell if the digital filtering is removing all of the glitches--if there are glitches you would notice an inconsistent number of pulses returned by the counter, to compensate for the behavior you will have to implement step 3.  The only problem is that at 12,000 rpm you will be sampling the counter at 720 kHz.  This is going to be far too fast for your SW loop to keep up with, so you will have to read more than one period back at a time.   You would need to measure several periods of the counter at once (enough so your loop can keep up), add the values from each sample, and read back the entire array of AI data at once.

On another note, X Series boards do support re-triggerable analog input but are not (yet) available in USB form factor.

Best Regards,