Encoder mystery

T Chap

I have an encoder on a motor, using the Prop encoder object. I have used the same encoder on many systems, same motor, same Prop main board and never a failure. All of a sudden this one project is acting strange. The motor is a brushless DC, running from a driver that the Prop controls via PWM and PID. The code tells the motor to run from 0(set at boot) to a preset destination. In this problem, on boot the motor runs the right distance, and maybe runs several cycles ok but then starts running shorter than it should by about an 1/8" (in the real world for the object being moved), it incrementally starts getting worse by the same amount. I sent someone to the site today and he ruled out mechanical slipping which would be easy to detect. I sent out a new Prop main board and new encoder. There is a CAT5 that carries the info from the encoder back to the main board, less than 10' but I have run up to 50' easy. We tried several CAT5 cables, then tried a shielded CAT5. So basically everything in terms of electronics has been replaced. This appears to be noise on the encoder lines, making the Prop think the motor has run farther than it has in fact. There are no caps on the encoder lines, and I am thinking that maybe some caps might help knock down noise if this is in fact the problem. Can anyone offer any other advise on what to look for on this? I am not near the project, and having to do this with someone that does not have a scope or a lot of experience with electronics. Thanks

RobotWorkshop

Do you have a picture of your setup? It would help to know specifically what encoder you are using and exactly how it is connected to the Propeller.

- Is the encoder a 3.3V device or 5V?

- Is the encoder wired directly to the Propeller inputs or is there any thing else inline (resistors, etc)

- What kind of outputs are on the encoder? Does it have something like an internal Schmitt trigger to condition the output pulses? If not a 74HC14 using a pair of inverters back to back on each of the encoder channels can clean up the signals.

With some more details we may be able to help.

Robert

Tubular

T Chap

My advice would be to scope the encoder outputs, ideally with a logic analyser than can store lots of pulses.

I have seen encoders fail - not talking the cheap ones but name brand German ones, and even after a relatively low number of cycles (1000's).

kwinn

Tubular's suggestion is a good one. You might even use a prop with an sd card to log the pulses and timing information. It could be noise caused by external equipment turning on or off that produces extra encoder pulses. I have seen a centrifuge and an Xray unit cause that type of problem. A power line monitor might help, and perhaps you can check to see if some new equipment was started up around the same time the problem started.

T Chap

Thanks guys. The system is installed in another state so I don't have easy access to it myself without taking the trip. Simple US Digital encoder, 5v, using 1k in series to the prop, no buffers. I have tried 2 encoders already, and two Prop boards. My guy on the other end doesn't have a scope, so it may be impossible to do this remotely. One easy idea comes to mind. If it is noise from some other device than my system, then I could write some test code on the prop that would beep if there are changes to the encoder while parked. I could also display on the LCD the current position. If the noise is always active, it seems the motor should be creeping when the controller is idle, as the PID should be trying to compensate for the change in position. Therefore if the motor is NOT creeping over time, then the noise may be a result of my systems motor noise or cables, in which the noise is only present on the lines when it is in motion, not idle. So a test code for the lines is not easy in motion.

RobotWorkshop

Depending upon how the encoder drives the outputs you may have better results adding a weak pull-up or pull-down resistor on each encoder line. Something like a 10K or 22K may do it. I had noise issues on a circuit and adding a couple pull-up/pull-down resistors in the proper places cured that problem.

Robert

Tubular

Is it a quadrature encoder (A and B outputs)? If so you could add a second cog and set its counters to count positive edges. Then if you move in one direction your A and B count should be within a couple of counts. But if you have noise this will show up quickly as a difference in counts. This only works for motion in one continuous direction, then you have to reset the counters before moving backwards.

Also what sort of frequency is put out when you are moving at top speed? The 1 kohm resistor helps form an RC lowpass filter, reducing the upper speed. You'd have to have a high speed for this to start becoming a problem, so I don't think its the likely cause. Just mentioning it in case.

How far is the encoder from the prop?

T Chap

Thanks for the other notes. I spoke to support at the encoder company. He said it is a push pull output with 8ma capacity. He said it seems like noise causing the extra pulses, which is why the motor is stopping short of the destination. He asked if the Prop Quadrature obj had the built in feature to reject invalid states. I have no idea. But, the encoder can only transition in certain ways. It cannot go from 00 to 11 without a transition step and vice versa. But, with random noise on both lines, enough 'coincidences' could accumulate.

kwinn

You might try 1K pullups on the propeller end of the cable with the 1K series resistors between the prop pin and the cable/pullup junction. That gives a reasonably low impedance at the end of the signal path.