Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Motor Position and direction Control using Encoder

Status
Not open for further replies.

Fikadu

Junior Member level 3
Junior Member level 3
Joined
Feb 22, 2015
Messages
31
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
304
Hello every one. I am new to motor encoder. While trying to read motor encoder position counter and direction via Quadrature Encoder Pulse (QEP) , the position counter reading is good, where as direction reading keeps changing from 0 to 1, though the motor is moving to the same direction. why do you think this happens? The other thing is that, as obviously known the position counter resets to zero each time power is reset. As I am trying to control a variable capacitor position, I need to store a current position of the capacitor to a non-volatile memory for a next power startup. I have EEPROM for this, but as you know EEPROM is writing cycle limited memory. For my application, it may need to update the position to the EPPROM several times per second which may reaches to writing limit with in few time. I couldn't find a reliable solution for this problem. can you suggest me a better solution for the problem? is there any other mechanism to keep an encoder position count for the next start up without non volatile memory?

Thank you a lot

(F.Y.I My motor and encoder type is : pkp264d28a-r2el)
 

Hi,

For your next posts, please divide your bunch of words into paragraphs to make easier to read. A new_line is for free ;-)

why do you think this happens?
Hard to say without knowing details.
It's like asking "My car doesn't work, what can be the case?"
--> numerous possible reasons
In your case:
* noisy signals
* defective encoder
* wrong decoder algorithm
* defective decoder
* wrong wiring
* wrong timing
* metastable signals
* wrong interpretation
* wrong expectation
* ...
If you need help, then give details. Schematics, scope pictures, photos....

*******
, I need to store a current position of the capacitor
Why you need to store it? Usually encoders have a "zero position" signal. Then at power up run the motor to look for the "zero position" then go to the desired position.

need to update the position to the EPPROM several times per second
EEPROM wear out is no new phenomen. Thus there are a lot of solutions available. Just do a forum search or an internet search.
In short:
* spread data to a whole area of EEPROM cells
* reduce write cycles
I see no need to store the data several times per second.
* Write data only if the value really has changed
* Write data only on power_down event.

I couldn't find a reliable solution for this problem
* What solutions did you try so far?

to keep an encoder position count for the next start up without non volatile memory?
* use an absolute encoder instead of an incremental encoder.

Why don't you like "non volatile memory"?
* There are battery buffered RAM
* There is NVRAM (RAM combined with EEPROM)
Both are non volatile memories, but not suffering from early wear out.

Klaus
 

For your next posts, please divide your bunch of words into paragraphs to make easier to read. A newline is for free ;-)

Thank you very much for your really helpful answers.
And very sorry for not to divide my bunch of words in to paragraphs( I will try to use the new lines which are for free :grin::grin::grin: )


Hard to say without knowing details.


Again ,Sorry for make it very general.

If you need help, then give details. Schematics, scope pictures, photos....
Here below, a simple schematic for the encoder interfacing is attached. Actually, the same thing is observed from evaluation board with another encoder onboard.
You may find a source code implementation from the following link.


https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/728055/2686905#2686905


EEPROM wear out is no new phenomen. Thus there are a lot of solutions available. Just do a forum search or an internet search.
In short:
* spread data to a whole area of EEPROM cells
* reduce write cycles
I see no need to store the data several times per second.
* Write data only if the value really has changed
* Write data only on power down event.


I am trying to spread the data to all cells and also to update whenever there is change.
The problem here is, because I am developing impedance matching tuner , the capacitor position keeps changing quickly while matching.
In that case I need to keep the current position every single time. As a result, these two solutions may not good enough for my application.

As you mentioned, this can be solved by recording on RAM and store on EEPROM only when power is down.
But I haven't included power saving mechanism to my controller and don't have much time to redesign.

Why you need to store it? Usually encoders have a "zero position" signal. Then at power up run the motor to look for the "zero position" then go to the desired position.


The capacitor minimum and maximum values are set initially. It should be kept with in that range all the time.
Once the a power is gone, there is no way to know what the current position of the capacitor and where to move. let say 0% of the capacitor is set to 200pF , 100% is to 2000pF, and current position is at 50%(900pF).
Let shut down and restart. Now, we don't have any information where the capacitor is unless we store in non-volatile memory or using absolute encoder(but,the encoder I bout is incremental).


Thanks a lot once again.
Encoder_Interface.PNG
 

Hi,

Schematic:
No ESD protection, no filters, no schmitt tirggers. Are you sure the signals are reliable?
Did you check the sensor signals?
Maybe
* the signal is ringing
* the voltage levels don´t match your circuit
* the rise/fall rate is too slow
... causing multiple transitions, where one expects one clean edge.

--> The first thing you need are "clean signals". Else every additional transition may cause the direction bit to toggle.
*******

Code:
It says nothing how the "direction" is generated. Just one line:
Code:
RotateDirection = EQep1Regs.QEPSTS.bit.QDF;
You should have some datasheet/description how the signal is generated.

You are free to add code that includes some hysteresis to position and direction.
This may be one key to reduce write rate: Don´t write the new value as soon as it changes, but write it only after the value has changed by a pre defined threshold.
*******

The problem here is, because I am developing impedance matching tuner , the capacitor position keeps changing quickly while matching.
In that case I need to keep the current position every single time.
I wonder why you use a mechanically adjustable capacitor. Why no solution without mechanics? Varicap, switched capacitors... but I don´t know your capacitor range (200pF...2000pF?) and resolution.

I don´t understand the "power down problem". You say it is a impedance matching tuner, where the capacitor value has to change quickly.
So on power down, you surely loose tracking. After power up (it may be after 100ms or after one week) it has to find the tracking point anyways... unimportant how the value was just before power down.

There is the Z-signal at the encoder: Do you use it?
******

But I haven't included power saving mechanism to my controller and don't have much time to redesign.
I don´t think that adding a NVRAM at SPI or I2C and adding a small piece of code is a big task.
******

Now, we don't have any information where the capacitor is
If you use the Z signal you surely can know where the capacitor was after power up:
* Run the motor and count the encoder pulses until you find the Z signal.
* after that you may change direction of the motor and move the capacitor back the same count of pulses to the "power up" position... or to any other position.

I think there are a couple of ways to solve your problem. But the problem won´t solve itself. You have to do it. And yes - it will be some manageable effort. Just try it.

Klaus
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top