dealing with vibration noise in encoder readings

[evanmc]

Python 3.9

CRIO 9053

9411 module

Automation Direct/koyo trd-n5000-rzwd encoder (5000 pulses per rotation, totem pole output)

192 mm circumference wheel

Now that I have the encoder readings working, I have hit my next problem.

The bit of code below reads things just fine, but when I slap the side of the encoder, I see a series of spikes that incorrectly lead the the conclusion that the encoder has moved backwards and then forward by 0.038 mm.  Looking at the trace, I can see why -- my scope skills are not that great, but I measure the spike at 7.8 ms.

This may just be no big deal, given that the error I see over 15 seconds of repeated vibration yielded total false movement of 0.038 mm, a value far below the precision I need -- but still, I want things to be tidy.

Is there a mechanism I am overlooking for dealing with this?  Just using the minimum pulse width does not seem to be the best way forward here.

self.log.debug("Begin rotation detection using Angular Encoding")
task = ni.Task(new_task_name=constants.RIO_TASK_NAME)
#channelA = task.ci_channels.add_ci_ang_encoder_chan(counter = 'Mod3/ctr0', decoding_type = EncoderType.X_1, zidx_enable=True, units=AngleUnits.DEGREES, pulses_per_rev=1000, initial_angle=0.0)

# Add the channel as an angular encoder without Z index support, as we really don't care about the number of rotations
channelA = task.ci_channels.add_ci_ang_encoder_chan(counter = 'Mod3/ctr0', decoding_type = EncoderType.X_1, zidx_enable=False, zidx_val=0, units=AngleUnits.DEGREES, pulses_per_rev=self.encoderClicksPerRevolution, initial_angle=0.0)


channelA.ci_encoder_a_input_dig_fltr_min_pulse_width = 0.0001
channelA.ci_encoder_a_input_dig_fltr_enable = True
channelA.ci_encoder_a_input_term = 'PFI0'
channelA.ci_encoder_b_input_dig_fltr_min_pulse_width = 0.0001
channelA.ci_encoder_b_input_dig_fltr_enable = True
channelA.ci_encoder_b_input_term = 'PFI1'
channelA.ci_encoder_z_input_dig_fltr_min_pulse_width = 0.0001
channelA.ci_encoder_z_input_dig_fltr_enable = True
channelA.ci_encoder_z_input_term = 'PFI2'

task.timing.samp_clk_overrun_behavior = nidaqmx.constants.OverflowBehavior.TOP_TASK_AND_ERROR

task.start()
previous = 0.0
running = True

# This loop will run until things are gracefully shut down by another thread
# setting running to False.
while running:
    try:
        ang =task.read(number_of_samples_per_channel = 1) #nidaqmx.constants.READ_ALL_AVAILABLE)
        #print("Current register is {}".format(channelA.ci_count))
    except nidaqmx.errors.DaqError:
        self.log.error("Read error encountered")
        continue

    # If the current reading has changed from the previous reading, the wheel has moved
    if ang[0] != 0 and ang[0] != previous:
        try:
            # Put the current angular reading in the queue
            self._changeQueue.put(float(ang[0]), block=False)
        except queue.Full:
            self.log.error("Distance queue is full. Reading is lost.")
        previous = ang[0]

 

[Kevin_Price]

My main thought is:

Congratulations!

1. You are able to detect small vibrational motions caused by striking the encoder

2. Your use of quadrature successfully prevents those vibrations from causing any *accumulation* of error.

Whenever your physical system is at perfect rest, your encoder sensor will be at some unknown "phase" between 2 adjacent transition points.  There's no getting around it, that's just the nature of having a quantized measurement.  There is no information available between those 2 points.

   So it might take only a tiny disturbance to create a vibration-based transition or it may require a larger one.  No way to know.  And therefore, no way to reliably *tune* things like minimum pulse width to try to block it. 

   But the beauty of quadrature is that after the low-to-high transition you see changes the tracked position, the following high-to-low transition changes it right back again.  The single increment of change you sometimes see after 15 seconds of vibration is just the system settling to a slightly different final resting place, something that's pretty inevitable with real life systems, friction, and other hysteresis effects.

So basically, don't worry, everything's working as it should.

-Kevin P

[evanmc]

OK, thanks.  I will not worry about it, then.  This system will be deployed in an environment where vibrations may be encountered (a trailing odometry wheel behind a tractor), so I just wanted to see if I can deal with it.  

[SteveD123]

Kevin

Kudos given because of your point about the new licencing policy. With this and their departure from the direct sales model NI have removed everything that made them great.

Things are even worse in Labwindows land, where the software basically will be abandoned, even if you do buy a year's right to use the compiler. Shame, it was a really good development envionment and the direct sales model meant that you just dragged in your regional sales engineer if there was any problem, software or hardware.