Motor Positioning, Inertia, & SX
nick bernard
Posts: 329
it's like you know,
i have a position encoder (8bit) attached to a DC motor. this feedback encoder is wired to RB. the motor is controlled by 2 relays that determine the direction of rotation. the sx controls both relays via FETs.
There is an identical position encoder (let's call it the command encoder) with a knob wired to RC. the program will turn the motor until the position of the feedback encoder matches the position of the command encoder.
simple right?
eh no - occasionally the motor will overshoot the command position because the motor needs time to stop & inertia keeps things moving for a bit. i did some crude measurements and determined that at full speed the position encoder changes LSB at 24 times a second. The SX is sampling the feedback position every .5us or 2000000 times a second so i should have plenty of time to emplement some type of control scheme to resolve this problem.
i was simply wondering if anyone has had any experience with transient control with the SX or any other advice that could help with this situation.
see the encoder at
http://www.encoderdevices.com/download/ed_21/ED-21.pdf
and also a crude one-wire schematic
and some code
thx
nickB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
Post Edited (nick bernard) : 2/16/2005 10:59:43 PM GMT
i have a position encoder (8bit) attached to a DC motor. this feedback encoder is wired to RB. the motor is controlled by 2 relays that determine the direction of rotation. the sx controls both relays via FETs.
There is an identical position encoder (let's call it the command encoder) with a knob wired to RC. the program will turn the motor until the position of the feedback encoder matches the position of the command encoder.
simple right?
eh no - occasionally the motor will overshoot the command position because the motor needs time to stop & inertia keeps things moving for a bit. i did some crude measurements and determined that at full speed the position encoder changes LSB at 24 times a second. The SX is sampling the feedback position every .5us or 2000000 times a second so i should have plenty of time to emplement some type of control scheme to resolve this problem.
i was simply wondering if anyone has had any experience with transient control with the SX or any other advice that could help with this situation.
see the encoder at
http://www.encoderdevices.com/download/ed_21/ED-21.pdf
and also a crude one-wire schematic
and some code
thx
nickB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
Post Edited (nick bernard) : 2/16/2005 10:59:43 PM GMT
Comments
In most DC motors this is a simple matter of creating a "shunt" across the motor terminals after power has been removed or
redirecting the generated power into a storage supply. In most AC induction motors, applying a small DC voltage has a
similar braking effect.
....Also, if you know you are going to "stop" the motor, then ramping the speed down will also work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe - Mask Designer III
National Semiconductor Corporation
(Communication Interface Division)
500 Pinnacle Court, Suite 525
Mail Stop GA1
Norcross,GA 30071
Post Edited (Beau Schwabe) : 2/16/2005 11:16:57 PM GMT
heres the first link i came across: http://www.ecircuitcenter.com/Circuits/pid1/pid1.htm
Post Edited (Paul Baker) : 2/16/2005 11:25:23 PM GMT
in any case i think i have a solution:
1. predict where the motor will stop so we can stop it early.
2. how early depends on how fast its moving
so all we have to do is subtract the previous position from the current position and multiply it by a constant, add that to the current position and voila
i may have a problem with timing since the sx is operating sooo fast but when i start twiddling with the assembly i think something will come up...
off to the think tank
nickB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
But a PID controller would be the best.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.TerryHittConsulting.com
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
If you used a mosfet or something you could slow the motor using PWM.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.TerryHittConsulting.com
·
here's a pic i found on google
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
Post Edited (nick bernard) : 2/17/2005 2:15:23 PM GMT
With all that said, if you will only have on/off control of your target motor, my best suggestion is to derive inertial equations to calculate what the total rate of travel will be once the motor is switched off for a given speed, and when the position reaches the point where the inertia will take it to its intended position, switch off the motor.
my courses were all mathy. when we had to develop controllers for missles and broomsticks the plant was modeled by mathmatical models (laplace or z transform).
and yeah thats what i was saying. something just like this, (Z^-1 is the previous sample) where you add an "expected position bonus" to your feedback before pushing it into the comparitor.
the trick is finding out how often to sample the feedback
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
Not knowing much about your current set-up, I will throw some things out that you have probably considered, so please don't be offended... stuff like using the upper 8 bits of the 9-bit encoder, and using 1:1 ratio for the pulleys, etc.
One of the challenges for this project is getting the time domains straight.· At 24 LSB steps/second that is 42 milliseconds/step;·so you have things happening in the millisecond range.· The knob is probably getting turned faster than that, when it is actually being turned, so you may need to deal with that;·and of course, the CPU is screaming.· Setting up a 100uS interrupt, for instance, and using a couple prescaling counters to perform different tasks every 100uS, 1mS, 100mS, etc. will help.· If you want to get real fancy, you can have the program calculate the motor speed, in mS/count, instead of using the estimated value...
One thing that will help is to think in terms of "how many milliseconds until the thing is in the correct position given how long it has been running", instead of "how many counts on the encoder is it from the desired position".· In order to calculate this you need to know the (difference in encoder counts) X 42 mS/count - (how many mS to stop).· The (how many mS to stop) value can probably be loaded from a small, 16 byte(?) table, and the index into the table is how many mS (or ten's of mS)·the motor has been running (relay energized).· You will have to build the table by experimenting with different on times.· You could proabably write a test program to turn the motor on for different durations of time, and measure how much it moves when turned off.· So you need to keep a counter that is·reset upon energizing a relay and counts up to some limited value (15 for instance) every n mS while the relay is energized.· The rate at which this counter is incremented is one of those time domain things mentioned above; it will be handled by some prescaler in some timed interrupt...
So, as the thing is moving you calculate the above formula every 1mS, let's say, and when the answer is somewhere near zero, you de-energize the relay.· Remember that the uncertainty is 42mS·(per LSB count).·
I am curious about a couple things.· If the demand encoder is turned to a point where it would be "shorter" for the motor to turn the other direction, does it continue in the original direction, or does it reverse direction?· When it reverses direction, for any reason, is there a time delay between deenergizing one relay and energizing the other?· Is is feasible to give the motor a little "bump" in the reverse direction to make it stop quicker?
I guess I got a little carried away, but it is an interesting project... ;-)
Jim.
·
thx for the reply jim.
to answer your questions the comparitor algoritm does find the shortest path from Command to Feedback and i did not add a delay for a change in direction. also i dont think that i can "bump" the hydraulics like that because thats almost what i'm doing now with 1 lsb of overshoot and i'm sure it will be too "violent" for the drive.
this project initially was running on a BS2SX. but when i got the sx chips in a few days ago i realized they would provide much better control over the unit and a bs2sx could still handle the position displays.
in short i've been working with the sx for 3 days and i really dont know to much about interrupts (because i just got to that unit in the al williams book). but i used to program intel 8086's in college so the assembly is comming quite natural. i figured there would be a method to time sample rates i just know know much about it.
whoa is me.
any help?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
Post Edited (Paul Baker) : 2/17/2005 8:00:43 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life
Post Edited (nick bernard) : 2/17/2005 10:35:48 PM GMT
if the gain is high enough, you basically squash away any need to model the system.
what is the bandwidth needed?
i use PID all the time without the need to model a system. the only time i ever modeled a system is when i had to play with a robotic arm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
League Bowling.... it's not a sport, it's a way of life