Having problems with encoder readings due to motor commutation noise

[jespestana]

Hello everyone,

I wanted to ask for advice with a hardware problem which I believe is rather usual.

Here I describe my application:

We are controlling an electric actuator for a robotics application. We are using encoders to take position readings and we need to perform analog acquisition for other measurements (such as force measured with strain gauges).

The problem is:

In summary, I am having problems to acquire properly position readings from a quadrature linear encoders and also some analog inputs. The cause  is the commutation noise generated by the motor drive we are using (which is a brushless dc motor Moog BN-23-23).

Our acquisition platform is a NI PXI-8106 with a PXI-1042Q chassis. We have two possibilities to acquire the signals. We have a multifunction DAQ M series NI PXI-6259 and a FlexRIO NI PXI-7951R with a DIO module NI PXI-6581R.

The commutation noise have a frequency of 30 kHz. In an oscilloscope we can see a series of noise peaks that are only present during a short period of time (about 1/10 of the period of the noise). The rest of the time the noise is not present.

The Accelnet amplifier module that feeds the electric motor provides us with a clock signal synchronized with the noise (which frequency is about 1/4 of the noise frequency). This clock signal provides a mean to solve the problem of the analog acquisition. We can use this clock to perform a buffered acquisition with an external clock in LabView connecting the clock to a PFI pin or to the FPGA card. But the noise is also corrupting this clock signal (we get a daqmx error warning us about possible glitches in the clock signal, and also stopping the acquisition). I believe that solving the encoder problem we can solve also the analog acquisition problem.

In the encoder readings the noise is making our counter count upwards or backwards gradually rather fast. We can get an increase in position of about 10 cm/second without any appreciable movement in the linear actuator.

It would be of great help if anyone could post the solution he is using to solve this problem.

Thanks in advance for your help,

jespestana

PS: I insist in my belief that we are having a hardware issue, because we are only having bad readings when the electric motor is working. I am convinced so because we have already performed encoder and analog readings using other drives, such as hydraulic cylinders. Thus, I think that it is not a problem of our software (of our LabView VI).

[John_P1 · Accepted solution]

Hi jespestana,

I'm not sure why the noise would be causing your encoder measurement to increment more slowly...  However I do have one suggestion on the M Series board (6259):

The M Series cards have built-in digital filtering on the PFI lines (see the M Series User Manual).  It sounds like the noise is a series of ~3 us pulses (1/10 of 1/30 kHz).  One of the available filtering frequencies that you may set on your M Series is 6.425 us, which should ignore any pulses (high or low) that are less than 6.425 us. You may set digital filtering with a DAQmx Property Node:

A caveat is that the driver only allows you to configure digital filtering for counter inputs on M Series devices.  So, you could use digital filtering directly on your encoder task but not for your AI Sample Clock.  A workaround can be found here, which involves configuring a dummy counter task to set the PFI filter for your AI task.  If you're using the same PFI line for your encoder and AI task, you should just be able to set the PFI filter through the encoder task and not worry about the workaround.

With regards to the Flex RIO, I believe you could implement something similar on the FPGA, but I'm probably not the best person to comment about this.  It would likely be a great deal more work than using the built-in filtering of the DAQmx API.

Best Regards,

[jespestana]

Hi John P.,

I think I have not been really clear explaining the problem with our encoder readings. In fact what happens is that the position measurement decreases at constant velocity when the actuator is not moving. It is not that the encoders counts increment more slowly. The problem is that we have encoder counts when there should not be any (encoder counts).

Your answer has been really interesting, we did not know that we have this option in our M series daq card. I think that we can solve both problems using your advice.

Besides ignoring little digital pulses are there any other hardware options that you would consider?

Thank you very much,

Best regards,

Jespestana

[John_P1]

Hi Jespestana,

Oh sorry, I misread your sentence about the encoder measurement.  Implementing digital filtering seems to be a reasonable approach to solving the issue, I can't think of any other suggestions.  If you have any issues implementing the filtering be sure to let us know.

Best Regards,

[KGM]

WE had something similar with an old small DC motor on a soil testing rig.
Our problem was simple . We had only to improve the shielding on the encoder cabling.

Just lucky I guess.

Kevin Mills

Unisa