Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Back-EMF speed detection in motors
11 views
Skip to first unread message
Tim Wescott
Mar 22, 2013, 1:51:29 PM3/22/13
to
I'm working on a project that involves replacing some existing
electronics with some that I've designed. It's controlling the speed of
DC brushed motors. Since the original equipment uses a knowledge of the
applied voltage and the motor current to infer back EMF and therefor
motor speed, that's what I've done, too.
My problem is that my equipment is consistently sensing the speed as
being faster than it really is, by a constant amount -- except when the
motor is stalled, when the reading is correctly zero. So I end up
servoing the motor speed to a figure that's a 20-30 RPM higher than
desired.
It's not just a mis-calibration of the motor torque constant or the
resistance -- if that were the case, then the motor speed error would
depend on the command speed or the applied torque. I can easily
calibrate out any dependence on torque (by adjusting the calibrated motor
resistance) and I can get a 1:1 correspondence between increments in the
commanded speed and increments in the actual speed. But I'm left with
this @#$% offset.
Has anyone seen this? Anyone care to hazard a guess at what's going on?
Thanks.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
electronics with some that I've designed. It's controlling the speed of
DC brushed motors. Since the original equipment uses a knowledge of the
applied voltage and the motor current to infer back EMF and therefor
motor speed, that's what I've done, too.
My problem is that my equipment is consistently sensing the speed as
being faster than it really is, by a constant amount -- except when the
motor is stalled, when the reading is correctly zero. So I end up
servoing the motor speed to a figure that's a 20-30 RPM higher than
desired.
It's not just a mis-calibration of the motor torque constant or the
resistance -- if that were the case, then the motor speed error would
depend on the command speed or the applied torque. I can easily
calibrate out any dependence on torque (by adjusting the calibrated motor
resistance) and I can get a 1:1 correspondence between increments in the
commanded speed and increments in the actual speed. But I'm left with
this @#$% offset.
Has anyone seen this? Anyone care to hazard a guess at what's going on?
Thanks.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
John Larkin
Mar 22, 2013, 2:01:41 PM3/22/13
to
On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
Brush noise trashing an opamp?
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
Jim Thompson
Mar 22, 2013, 2:03:23 PM3/22/13
to
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
How, specifically, are you "inferring" the back EMF from the applied
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
voltage and the current?
...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
passerby
Mar 22, 2013, 2:49:46 PM3/22/13
to
replying to Tim Wescott , passerby wrote:
commutation noise is still affecting the reading (and/or your cables are on
the long side) or there's enough capacitance in the leads / circuit for the
initial jump during commutation to push the BEMF zero crossing time forward
for just the right amount of time?
Wait - are you reading it sooner than anticipated or later? trying to wrap my
head around the description you posted while caffeine hasn't fully kicked in.
If it's sooner, then you're probably reading it too soon and there may
actually be yet another (real) zero crossing in the same period .
Take anything I say on the subject with a huge grain of salt - I've never
actually dealt with anything brushed that did not have an encoder attached to
it. Do you still do it in a way similar to what you would have done for a
sensorless brushless? I would imagine brushed commutation would be *way*
noisier than brushless so would require long[er] ZC hold-off times, perhaps
even too long for high RPMs.
Sorry, not offering a solution here, just trying to think along ...
--
posted from
http://www.polytechforum.com/control/back-emf-speed-detection-in-motors-11832-.htm
using PolytechForum's Web, RSS and Social Media Interface to
sci.engr.control and other engineering groups
> tim wrote:
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
Measuring the zero crossing point too close to the commutation time while
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
commutation noise is still affecting the reading (and/or your cables are on
the long side) or there's enough capacitance in the leads / circuit for the
initial jump during commutation to push the BEMF zero crossing time forward
for just the right amount of time?
Wait - are you reading it sooner than anticipated or later? trying to wrap my
head around the description you posted while caffeine hasn't fully kicked in.
If it's sooner, then you're probably reading it too soon and there may
actually be yet another (real) zero crossing in the same period .
Take anything I say on the subject with a huge grain of salt - I've never
actually dealt with anything brushed that did not have an encoder attached to
it. Do you still do it in a way similar to what you would have done for a
sensorless brushless? I would imagine brushed commutation would be *way*
noisier than brushless so would require long[er] ZC hold-off times, perhaps
even too long for high RPMs.
Sorry, not offering a solution here, just trying to think along ...
--
posted from
http://www.polytechforum.com/control/back-emf-speed-detection-in-motors-11832-.htm
using PolytechForum's Web, RSS and Social Media Interface to
sci.engr.control and other engineering groups
Tim Wescott
Mar 22, 2013, 3:29:56 PM3/22/13
to
On Fri, 22 Mar 2013 11:03:23 -0700, Jim Thompson wrote:
> On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
> wrote:
>
>>I'm working on a project that involves replacing some existing
>>electronics with some that I've designed. It's controlling the speed of
>>DC brushed motors. Since the original equipment uses a knowledge of the
>>applied voltage and the motor current to infer back EMF and therefor
>>motor speed, that's what I've done, too.
>>
>>My problem is that my equipment is consistently sensing the speed as
>>being faster than it really is, by a constant amount -- except when the
>>motor is stalled, when the reading is correctly zero. So I end up
>>servoing the motor speed to a figure that's a 20-30 RPM higher than
>>desired.
>>
>>It's not just a mis-calibration of the motor torque constant or the
>>resistance -- if that were the case, then the motor speed error would
>>depend on the command speed or the applied torque. I can easily
>>calibrate out any dependence on torque (by adjusting the calibrated
>>motor resistance) and I can get a 1:1 correspondence between increments
>>in the commanded speed and increments in the actual speed. But I'm left
>>with this @#$% offset.
>>
>>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>>
>>Thanks.
>
> How, specifically, are you "inferring" the back EMF from the applied
> voltage and the current?
Back EMF = voltage - current * R
> On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
> wrote:
>
>>I'm working on a project that involves replacing some existing
>>electronics with some that I've designed. It's controlling the speed of
>>DC brushed motors. Since the original equipment uses a knowledge of the
>>applied voltage and the motor current to infer back EMF and therefor
>>motor speed, that's what I've done, too.
>>
>>My problem is that my equipment is consistently sensing the speed as
>>being faster than it really is, by a constant amount -- except when the
>>motor is stalled, when the reading is correctly zero. So I end up
>>servoing the motor speed to a figure that's a 20-30 RPM higher than
>>desired.
>>
>>It's not just a mis-calibration of the motor torque constant or the
>>resistance -- if that were the case, then the motor speed error would
>>depend on the command speed or the applied torque. I can easily
>>calibrate out any dependence on torque (by adjusting the calibrated
>>motor resistance) and I can get a 1:1 correspondence between increments
>>in the commanded speed and increments in the actual speed. But I'm left
>>with this @#$% offset.
>>
>>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>>
>>Thanks.
>
> How, specifically, are you "inferring" the back EMF from the applied
> voltage and the current?
where R is the calibrated armature resistance (and yes, it changes
discernibly when the motor heats -- that's not my immediate problem).
Tim Wescott
Mar 22, 2013, 3:32:57 PM3/22/13
to
(if I did, I'd know the motor speed). One measures current and voltage,
then one takes the (theoretically known) resistance, and backs out a
number for the back EMF. Then one uses that to determine motor speed.
Mike Perkins
Mar 22, 2013, 3:36:27 PM3/22/13
to
between brushes and the commutator require a small voltage to produce a
plasma to carry the commutator current.
Have you worked out this "offset" voltage?
--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk
Vladimir Vassilevsky
Mar 22, 2013, 4:12:17 PM3/22/13
to
On 3/22/2013 2:29 PM, Tim Wescott wrote:
> On Fri, 22 Mar 2013 11:03:23 -0700, Jim Thompson wrote:
>
>> On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
>> wrote:
>>
>>> My problem is that my equipment is consistently sensing the speed as
>>> being faster than it really is, by a constant amount -- except when the
>>> motor is stalled, when the reading is correctly zero. So I end up
>>> servoing the motor speed to a figure that's a 20-30 RPM higher than
>>> desired.
> On Fri, 22 Mar 2013 11:03:23 -0700, Jim Thompson wrote:
>
>> On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
>> wrote:
>>
>>> My problem is that my equipment is consistently sensing the speed as
>>> being faster than it really is, by a constant amount -- except when the
>>> motor is stalled, when the reading is correctly zero. So I end up
>>> servoing the motor speed to a figure that's a 20-30 RPM higher than
>>> desired.
>> How, specifically, are you "inferring" the back EMF from the applied
>> voltage and the current?
>
> Back EMF = voltage - current * R
Stray inductance.
>> voltage and the current?
>
> Back EMF = voltage - current * R
Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com
John Larkin
Mar 22, 2013, 4:37:51 PM3/22/13
to
On Fri, 22 Mar 2013 14:29:56 -0500, Tim Wescott <t...@seemywebsite.com>
The idea of computing back EMF, and using that to improve speed
regulation, is pretty much equivalent to driving the armature from a
power supply with a negative output resistance.
That can get unstable, with intertial issues, so it sometimes makes
sense to tweak the dynamics of that negative resistance.
regulation, is pretty much equivalent to driving the armature from a
power supply with a negative output resistance.
That can get unstable, with intertial issues, so it sometimes makes
sense to tweak the dynamics of that negative resistance.
d...@kbrx.com
Mar 22, 2013, 5:22:19 PM3/22/13
to
Tim - is the voltage supplied from a pulse width modulated source? If so,
is it measured or calculated?
Hul
is it measured or calculated?
Hul
Spehro Pefhany
Mar 22, 2013, 5:36:13 PM3/22/13
to
On Fri, 22 Mar 2013 14:29:56 -0500, Tim Wescott <t...@seemywebsite.com>
Hi, Tim:-
To control a brushed PM DC motor using IR compensation, you apply a
voltage proportional to the desired speed, plus a compensation term
equal to the product of the motor (and series wiring) resistance and
the measured armature current.
To get a fixed RPM error implies to me that either your current sensor
or your voltage DAC (or whatever) has a DC offset.
Picking some numbers out of the air:-
If the motor is a 24V motor that goes 5000 RPM at full voltage
Say maximum operating current is 1A, and resistance is 2.4 ohm
(LRA of 10A)
Voltage error for 25 RPM is 120mV
Current error for 25 RPM is 0.12/2.4 = 50mA
--sp
To control a brushed PM DC motor using IR compensation, you apply a
voltage proportional to the desired speed, plus a compensation term
equal to the product of the motor (and series wiring) resistance and
the measured armature current.
To get a fixed RPM error implies to me that either your current sensor
or your voltage DAC (or whatever) has a DC offset.
Picking some numbers out of the air:-
If the motor is a 24V motor that goes 5000 RPM at full voltage
Say maximum operating current is 1A, and resistance is 2.4 ohm
(LRA of 10A)
Voltage error for 25 RPM is 120mV
Current error for 25 RPM is 0.12/2.4 = 50mA
--sp
Frank Miles
Mar 22, 2013, 5:49:55 PM3/22/13
to
On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott wrote:
> I'm working on a project that involves replacing some existing
> electronics with some that I've designed. It's controlling the speed of
> DC brushed motors. Since the original equipment uses a knowledge of the
> applied voltage and the motor current to infer back EMF and therefor
> motor speed, that's what I've done, too.
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
> It's not just a mis-calibration of the motor torque constant or the
> resistance -- if that were the case, then the motor speed error would
> depend on the command speed or the applied torque. I can easily
> calibrate out any dependence on torque (by adjusting the calibrated
> motor resistance) and I can get a 1:1 correspondence between increments
> in the commanded speed and increments in the actual speed. But I'm left
> with this @#$% offset.
>
> Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
> Thanks.
My WAG is that your "armature resistance" is not really a constant.
> I'm working on a project that involves replacing some existing
> electronics with some that I've designed. It's controlling the speed of
> DC brushed motors. Since the original equipment uses a knowledge of the
> applied voltage and the motor current to infer back EMF and therefor
> motor speed, that's what I've done, too.
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
> It's not just a mis-calibration of the motor torque constant or the
> resistance -- if that were the case, then the motor speed error would
> depend on the command speed or the applied torque. I can easily
> calibrate out any dependence on torque (by adjusting the calibrated
> motor resistance) and I can get a 1:1 correspondence between increments
> in the commanded speed and increments in the actual speed. But I'm left
> with this @#$% offset.
>
> Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
> Thanks.
There will be times when (depending on the commutator) the brushes will
likely be connected to two separate windings; other times only one.
Given sufficient rpm you could probably use some time-averaged value; is
that what you've done?
Tim Williams
Mar 22, 2013, 6:29:23 PM3/22/13
to
"Vladimir Vassilevsky" <nos...@nowhere.com> wrote in message
news:XYKdnTPXRM-LJtHM...@giganews.com...
Would that not contribute to an effective R? Perhaps the "offset" (which
isn't a true offset -- it's still zero at zero!) is a polynomial
correction instead (leakage's offset being proportional to RPM)?
Tim
--
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com
news:XYKdnTPXRM-LJtHM...@giganews.com...
>>> How, specifically, are you "inferring" the back EMF from the applied
>>> voltage and the current?
>>
>> Back EMF = voltage - current * R
>
> Stray inductance.
Seconded, although on gut feeling. Not sure I can explain it.
>>> voltage and the current?
>>
>> Back EMF = voltage - current * R
>
> Stray inductance.
Would that not contribute to an effective R? Perhaps the "offset" (which
isn't a true offset -- it's still zero at zero!) is a polynomial
correction instead (leakage's offset being proportional to RPM)?
Tim
--
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com
Tim Williams
Mar 22, 2013, 6:31:15 PM3/22/13
to
"Frank Miles" <f...@u.washington.edu> wrote in message
news:kiijm3$gcn$1...@dont-email.me...
Tim, you say it's zero at zero (locked rotor), but is it always zero?
Does the offset change with position..?
news:kiijm3$gcn$1...@dont-email.me...
> My WAG is that your "armature resistance" is not really a constant.
> There will be times when (depending on the commutator) the brushes will
> likely be connected to two separate windings; other times only one.
> Given sufficient rpm you could probably use some time-averaged value; is
> that what you've done?
Ah, that's a good one too...
> There will be times when (depending on the commutator) the brushes will
> likely be connected to two separate windings; other times only one.
> Given sufficient rpm you could probably use some time-averaged value; is
> that what you've done?
Tim, you say it's zero at zero (locked rotor), but is it always zero?
Does the offset change with position..?
P E Schoen
Mar 22, 2013, 7:30:16 PM3/22/13
to
"Tim Wescott" wrote in message
news:uZSdnSGpFI-pLNHM...@giganews.com...
> Back EMF = voltage - current * R
> where R is the calibrated armature resistance (and yes, it changes
> discernibly when the motor heats -- that's not my immediate problem).
Here is something that might help, although they use a PWM drive and measure
the back EMF during the OFF period:
http://ww1.microchip.com/downloads/en/DeviceDoc/chapter%205.pdf
The following seems to use an encoder, but may have some helpful info:
http://ww1.microchip.com/downloads/en/AppNotes/00532c.pdf
More info:
http://ww1.microchip.com/downloads/en/devicedoc/41233A.pdf
And this:
http://ww1.microchip.com/downloads/en/AppNotes/00905a.pdf
I have heard that it may be possible to sense the change in current and/or
voltage caused by the commutation but it tends to be noisy and dependent on
things like brush and commutator condition.
Paul
news:uZSdnSGpFI-pLNHM...@giganews.com...
> Back EMF = voltage - current * R
> where R is the calibrated armature resistance (and yes, it changes
> discernibly when the motor heats -- that's not my immediate problem).
the back EMF during the OFF period:
http://ww1.microchip.com/downloads/en/DeviceDoc/chapter%205.pdf
The following seems to use an encoder, but may have some helpful info:
http://ww1.microchip.com/downloads/en/AppNotes/00532c.pdf
More info:
http://ww1.microchip.com/downloads/en/devicedoc/41233A.pdf
And this:
http://ww1.microchip.com/downloads/en/AppNotes/00905a.pdf
I have heard that it may be possible to sense the change in current and/or
voltage caused by the commutation but it tends to be noisy and dependent on
things like brush and commutator condition.
Paul
Joerg
Mar 22, 2013, 7:32:34 PM3/22/13
to
Tim Wescott wrote:
> I'm working on a project that involves replacing some existing
> electronics with some that I've designed. It's controlling the speed of
> DC brushed motors. Since the original equipment uses a knowledge of the
> applied voltage and the motor current to infer back EMF and therefor
> motor speed, that's what I've done, too.
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
> It's not just a mis-calibration of the motor torque constant or the
> resistance -- if that were the case, then the motor speed error would
> depend on the command speed or the applied torque. I can easily
> calibrate out any dependence on torque (by adjusting the calibrated motor
> resistance) and I can get a 1:1 correspondence between increments in the
> commanded speed and increments in the actual speed. But I'm left with
> this @#$% offset.
>
> Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
You've received a number of hints already. One more: Could it be that
> I'm working on a project that involves replacing some existing
> electronics with some that I've designed. It's controlling the speed of
> DC brushed motors. Since the original equipment uses a knowledge of the
> applied voltage and the motor current to infer back EMF and therefor
> motor speed, that's what I've done, too.
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
> It's not just a mis-calibration of the motor torque constant or the
> resistance -- if that were the case, then the motor speed error would
> depend on the command speed or the applied torque. I can easily
> calibrate out any dependence on torque (by adjusting the calibrated motor
> resistance) and I can get a 1:1 correspondence between increments in the
> commanded speed and increments in the actual speed. But I'm left with
> this @#$% offset.
>
> Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
this motor is arcing? Then you would not see any effect when at standstill.
--
Regards, Joerg
http://www.analogconsultants.com/
John Larkin
Mar 22, 2013, 7:49:23 PM3/22/13
to
On Fri, 22 Mar 2013 19:30:16 -0400, "P E Schoen" <pa...@peschoen.com> wrote:
>"Tim Wescott" wrote in message
>news:uZSdnSGpFI-pLNHM...@giganews.com...
>
>> Back EMF = voltage - current * R
>
>> where R is the calibrated armature resistance (and yes, it changes
>> discernibly when the motor heats -- that's not my immediate problem).
>
>Here is something that might help, although they use a PWM drive and measure
>the back EMF during the OFF period:
>http://ww1.microchip.com/downloads/en/DeviceDoc/chapter%205.pdf
Tip 7? That only works if there's no current in the shunt diode, which has nasty
>"Tim Wescott" wrote in message
>news:uZSdnSGpFI-pLNHM...@giganews.com...
>
>> Back EMF = voltage - current * R
>
>> where R is the calibrated armature resistance (and yes, it changes
>> discernibly when the motor heats -- that's not my immediate problem).
>
>Here is something that might help, although they use a PWM drive and measure
>the back EMF during the OFF period:
>http://ww1.microchip.com/downloads/en/DeviceDoc/chapter%205.pdf
implications.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Jamie
Mar 22, 2013, 9:14:49 PM3/22/13
to
If that is a shunt/PM style motor, I don't quite understand how that
will work? Maybe I am missing something.
I have a pretty good understanding of DC brushed motors and I just
don't see it happening that way.
Dynamic(R) = Varm / Iarm.
Now since the motor has some DC R in it, this must be treated like a
series R with an ideal motor.
Most drive electronics knows the size of the motor and knows ~ what
the DC R should be, along with the expected dynamic current from the
motor. The drive will advance the arm voltage above the set point when
current is building to calculate for this offset. When monitoring
feedback for an external reference for example, this offset should be
removed. Many high end drives have the ability to adjust this.
So, output arm voltage must be offset (increased) as current increases,
to over come the DC R. much like satisfying a voltage need at a divider
node, the motor being the point of the dropping R and DC R in the motor
being the series R.
I've played around with lots of small motor drive circuits and that is
how I've done it. The feed back circuit uses the current to scale the
voltage reading back so that output voltage will raise above set point
to satisfy the offset requirements. This will make the motor spin a
little faster and match your readings.
That's my blog for the day, and long winded as it is. Most likely
nothing you can use. :)
P.S.
Flux density in the field is going to effect your speed at specific
arm voltages, just incase you didn't think of that.
Have a good day..
Jamie
Jim Thompson
Mar 22, 2013, 8:58:57 PM3/22/13
to
On Fri, 22 Mar 2013 16:32:34 -0700, Joerg <inv...@invalid.invalid>
wrote:
In the past I've done really good with just using an external resistor
equal to the winding resistance, so I'm not quite sure what setup Tim
is using.
wrote:
equal to the winding resistance, so I'm not quite sure what setup Tim
is using.
Jim Thompson
Mar 22, 2013, 9:53:13 PM3/22/13
to
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
Here's the way I've done it in the past...
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
http://www.analog-innovations.com/SED/DC_Motor_Control.pdf
John Larkin
Mar 22, 2013, 10:38:17 PM3/22/13
to
Tim Wescott
Mar 22, 2013, 10:42:14 PM3/22/13
to
On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
> Tim - is the voltage supplied from a pulse width modulated source? If
> so,
> is it measured or calculated?
>
Calculated from PWM. But verified on an O-scope and it looks pretty good.
> Tim - is the voltage supplied from a pulse width modulated source? If
> so,
> is it measured or calculated?
>
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Jim Thompson
Mar 22, 2013, 10:52:54 PM3/22/13
to
On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
<t...@seemywebsite.please> wrote:
>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>
>> Tim - is the voltage supplied from a pulse width modulated source? If
>> so,
>> is it measured or calculated?
>>
>
>Calculated from PWM. But verified on an O-scope and it looks pretty good.
How calculated from PWM?
<t...@seemywebsite.please> wrote:
>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>
>> Tim - is the voltage supplied from a pulse width modulated source? If
>> so,
>> is it measured or calculated?
>>
>
>Calculated from PWM. But verified on an O-scope and it looks pretty good.
Flyback diode? Or full H-bridge?
Jon Elson
Mar 22, 2013, 11:04:14 PM3/22/13
to
Tim Wescott wrote:
> On Fri, 22 Mar 2013 11:03:23 -0700, Jim Thompson wrote:
>>
>> How, specifically, are you "inferring" the back EMF from the applied
>> voltage and the current?
>
> Back EMF = voltage - current * R
>
> where R is the calibrated armature resistance (and yes, it changes
> discernibly when the motor heats -- that's not my immediate problem).
>
I assume you are using a PWM drive scheme? Can you arrange to
> On Fri, 22 Mar 2013 11:03:23 -0700, Jim Thompson wrote:
>>
>> How, specifically, are you "inferring" the back EMF from the applied
>> voltage and the current?
>
> Back EMF = voltage - current * R
>
> where R is the calibrated armature resistance (and yes, it changes
> discernibly when the motor heats -- that's not my immediate problem).
>
sample the back EMF during the PWM off-time? That would get rid of the
R factor to a large extent, depending on filtering.
Jon
Adrian Tuddenham
Mar 23, 2013, 6:12:38 AM3/23/13
to
brush, regardless of current. No explanation was given for the
rule-of-thumb.
--
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk
Fred Bartoli
Mar 23, 2013, 11:37:54 AM3/23/13
to
Le Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott a écrit:
> I'm working on a project that involves replacing some existing
> electronics with some that I've designed. It's controlling the speed of
> DC brushed motors. Since the original equipment uses a knowledge of the
> applied voltage and the motor current to infer back EMF and therefor
> motor speed, that's what I've done, too.
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
> It's not just a mis-calibration of the motor torque constant or the
> resistance -- if that were the case, then the motor speed error would
> depend on the command speed or the applied torque. I can easily
> calibrate out any dependence on torque (by adjusting the calibrated
> motor resistance) and I can get a 1:1 correspondence between increments
> in the commanded speed and increments in the actual speed. But I'm left
> with this @#$% offset.
>
> Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
> Thanks.
How do you supply the motor? Is that a MOSFET bridge or do you have some
> I'm working on a project that involves replacing some existing
> electronics with some that I've designed. It's controlling the speed of
> DC brushed motors. Since the original equipment uses a knowledge of the
> applied voltage and the motor current to infer back EMF and therefor
> motor speed, that's what I've done, too.
>
> My problem is that my equipment is consistently sensing the speed as
> being faster than it really is, by a constant amount -- except when the
> motor is stalled, when the reading is correctly zero. So I end up
> servoing the motor speed to a figure that's a 20-30 RPM higher than
> desired.
>
> It's not just a mis-calibration of the motor torque constant or the
> resistance -- if that were the case, then the motor speed error would
> depend on the command speed or the applied torque. I can easily
> calibrate out any dependence on torque (by adjusting the calibrated
> motor resistance) and I can get a 1:1 correspondence between increments
> in the commanded speed and increments in the actual speed. But I'm left
> with this @#$% offset.
>
> Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
> Thanks.
free wheeling diode somewhere?
With the latter you have
Vavg = D Vs - (1-D) Vd = D(Vs-Vd) - Vd
which indeed has about a 1V offset per diode.
--
Thanks,
Fred.
Fred Bartoli
Mar 23, 2013, 11:40:33 AM3/23/13
to
Le Sat, 23 Mar 2013 15:37:54 +0000, Fred Bartoli a écrit:
<...>
Vavg = D Vs - (1-D) Vd = D(Vs+Vd) - Vd
--
Thanks,
Fred.
<...>
>
> How do you supply the motor? Is that a MOSFET bridge or do you have some
> free wheeling diode somewhere?
>
> With the latter you have Vavg = D Vs - (1-D) Vd = D(Vs-Vd) - Vd which
> indeed has about a 1V offset per diode.
Oops, obviously make that
> How do you supply the motor? Is that a MOSFET bridge or do you have some
> free wheeling diode somewhere?
>
> With the latter you have Vavg = D Vs - (1-D) Vd = D(Vs-Vd) - Vd which
> indeed has about a 1V offset per diode.
Vavg = D Vs - (1-D) Vd = D(Vs+Vd) - Vd
--
Thanks,
Fred.
Jim Thompson
Mar 23, 2013, 4:53:45 PM3/23/13
to
On Fri, 22 Mar 2013 18:53:13 -0700, Jim Thompson
<To-Email-Use-Th...@On-My-Web-Site.com> wrote:
[snip]
<To-Email-Use-Th...@On-My-Web-Site.com> wrote:
>
>Here's the way I've done it in the past...
>
>http://www.analog-innovations.com/SED/DC_Motor_Control.pdf
>
> ...Jim Thompson
Works just as well the other way around...
>Here's the way I've done it in the past...
>
>http://www.analog-innovations.com/SED/DC_Motor_Control.pdf
>
> ...Jim Thompson
http://www.analog-innovations.com/SED/MotorDriver_PWM.pdf
This is based on a half-H-bridge drive, thus no diode forward drop to
confuse the issue.
But I suspect the diode drop could be likewise easily subtracted out.
Jim Thompson
Mar 23, 2013, 5:02:27 PM3/23/13
to
On Sat, 23 Mar 2013 13:53:45 -0700, Jim Thompson
a flyback diode... the average of the voltage at the upper motor
terminal is still equal to Vm + 2*Im*Rm
<To-Email-Use-Th...@On-My-Web-Site.com> wrote:
>On Fri, 22 Mar 2013 18:53:13 -0700, Jim Thompson
><To-Email-Use-Th...@On-My-Web-Site.com> wrote:
>
>[snip]
>>
>>Here's the way I've done it in the past...
>>
>>http://www.analog-innovations.com/SED/DC_Motor_Control.pdf
>>
>> ...Jim Thompson
>
>Works just as well the other way around...
>
>http://www.analog-innovations.com/SED/MotorDriver_PWM.pdf
>
>This is based on a half-H-bridge drive, thus no diode forward drop to
>confuse the issue.
>
>But I suspect the diode drop could be likewise easily subtracted out.
>
> ...Jim Thompson
Pondering my navel, I don't think it matters, half-H-bridge or simply
>On Fri, 22 Mar 2013 18:53:13 -0700, Jim Thompson
><To-Email-Use-Th...@On-My-Web-Site.com> wrote:
>
>[snip]
>>
>>Here's the way I've done it in the past...
>>
>>http://www.analog-innovations.com/SED/DC_Motor_Control.pdf
>>
>> ...Jim Thompson
>
>Works just as well the other way around...
>
>http://www.analog-innovations.com/SED/MotorDriver_PWM.pdf
>
>This is based on a half-H-bridge drive, thus no diode forward drop to
>confuse the issue.
>
>But I suspect the diode drop could be likewise easily subtracted out.
>
> ...Jim Thompson
a flyback diode... the average of the voltage at the upper motor
terminal is still equal to Vm + 2*Im*Rm
Tim Wescott
Mar 23, 2013, 5:37:10 PM3/23/13
to
On Fri, 22 Mar 2013 19:52:54 -0700, Jim Thompson wrote:
> On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
> <t...@seemywebsite.please> wrote:
>
>>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>>
>>> Tim - is the voltage supplied from a pulse width modulated source? If
>>> so,
>>> is it measured or calculated?
>>>
>>>
>>Calculated from PWM. But verified on an O-scope and it looks pretty
>>good.
>
> How calculated from PWM?
>
> Flyback diode? Or full H-bridge?
Full H-bridge. There'd be no way of knowing with flyback diodes -- you'd
> On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
> <t...@seemywebsite.please> wrote:
>
>>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>>
>>> Tim - is the voltage supplied from a pulse width modulated source? If
>>> so,
>>> is it measured or calculated?
>>>
>>>
>>Calculated from PWM. But verified on an O-scope and it looks pretty
>>good.
>
> How calculated from PWM?
>
> Flyback diode? Or full H-bridge?
have to measure.
Tim Wescott
Mar 23, 2013, 5:38:04 PM3/23/13
to
Tim Wescott
Mar 23, 2013, 5:39:14 PM3/23/13
to
Fred Bartoli
Mar 23, 2013, 7:09:20 PM3/23/13
to
Is it MOSFET, or BJT/IGBT, in which case you have to have free wheeling
diodes across the transistors.
Do you have some "clever" low current ripple mode, or just plain diagonal
switching?
You say the offset is circa 20/30RPM. What are your typical figures?
(Vrail, motor constant or nominal speed at Vrail, typical current)
--
Thanks,
Fred.
Jim Thompson
Mar 23, 2013, 7:38:24 PM3/23/13
to
On Sat, 23 Mar 2013 16:37:10 -0500, Tim Wescott
See my other posts, I'm no longer certain that a flyback diode hurts
you calculation in the slightest.
<t...@seemywebsite.please> wrote:
>On Fri, 22 Mar 2013 19:52:54 -0700, Jim Thompson wrote:
>
>> On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
>> <t...@seemywebsite.please> wrote:
>>
>>>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>>>
>>>> Tim - is the voltage supplied from a pulse width modulated source? If
>>>> so,
>>>> is it measured or calculated?
>>>>
>>>>
>>>Calculated from PWM. But verified on an O-scope and it looks pretty
>>>good.
>>
>> How calculated from PWM?
>>
>> Flyback diode? Or full H-bridge?
>
>Full H-bridge. There'd be no way of knowing with flyback diodes -- you'd
>have to measure.
The motor needs to reverse?
>On Fri, 22 Mar 2013 19:52:54 -0700, Jim Thompson wrote:
>
>> On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
>> <t...@seemywebsite.please> wrote:
>>
>>>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>>>
>>>> Tim - is the voltage supplied from a pulse width modulated source? If
>>>> so,
>>>> is it measured or calculated?
>>>>
>>>>
>>>Calculated from PWM. But verified on an O-scope and it looks pretty
>>>good.
>>
>> How calculated from PWM?
>>
>> Flyback diode? Or full H-bridge?
>
>Full H-bridge. There'd be no way of knowing with flyback diodes -- you'd
>have to measure.
See my other posts, I'm no longer certain that a flyback diode hurts
you calculation in the slightest.
Jim Thompson
Mar 23, 2013, 7:38:56 PM3/23/13
to
Jim Thompson
Mar 24, 2013, 11:25:30 AM3/24/13
to
On 23 Mar 2013 23:09:20 GMT, Fred Bartoli
<mynamewithA...@free.fr> wrote:
>Le Sat, 23 Mar 2013 16:39:14 -0500, Tim Wescott a �crit:
Ignoring my added compensating R for the moment, what does the average
terminal voltage (at the motor) have to be?
Take Vm = speed voltage, Im = motor current, Rm = winding resistance
The _average_ voltage has to be Vavg = Vm + Im*Rm
Irrespective of how it's driven, flyback diode or not.
Why is that? Return to fundamentals to see how easy the solution is
>:-}
<mynamewithA...@free.fr> wrote:
>Le Sat, 23 Mar 2013 16:39:14 -0500, Tim Wescott a �crit:
>
>> On Sat, 23 Mar 2013 15:37:54 +0000, Fred Bartoli wrote:
>>
>>> Le Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott a �crit:
>> On Sat, 23 Mar 2013 15:37:54 +0000, Fred Bartoli wrote:
>>
terminal voltage (at the motor) have to be?
Take Vm = speed voltage, Im = motor current, Rm = winding resistance
The _average_ voltage has to be Vavg = Vm + Im*Rm
Irrespective of how it's driven, flyback diode or not.
Why is that? Return to fundamentals to see how easy the solution is
>:-}
Message has been deleted
Tim Wescott
Mar 25, 2013, 6:10:58 PM3/25/13
to
On Sat, 23 Mar 2013 16:38:24 -0700, Jim Thompson wrote:
> On Sat, 23 Mar 2013 16:37:10 -0500, Tim Wescott
> <t...@seemywebsite.please> wrote:
>
>>On Fri, 22 Mar 2013 19:52:54 -0700, Jim Thompson wrote:
>>
>>> On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
>>> <t...@seemywebsite.please> wrote:
>>>
>>>>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>>>>
>>>>> Tim - is the voltage supplied from a pulse width modulated source?
>>>>> If so,
>>>>> is it measured or calculated?
>>>>>
>>>>>
>>>>Calculated from PWM. But verified on an O-scope and it looks pretty
>>>>good.
>>>
>>> How calculated from PWM?
>>>
>>> Flyback diode? Or full H-bridge?
>>
>>Full H-bridge. There'd be no way of knowing with flyback diodes --
>>you'd have to measure.
>
> The motor needs to reverse?
>
> See my other posts, I'm no longer certain that a flyback diode hurts you
> calculation in the slightest.
>
Yes, it needs to work in both directions.
> On Sat, 23 Mar 2013 16:37:10 -0500, Tim Wescott
> <t...@seemywebsite.please> wrote:
>
>>On Fri, 22 Mar 2013 19:52:54 -0700, Jim Thompson wrote:
>>
>>> On Fri, 22 Mar 2013 21:42:14 -0500, Tim Wescott
>>> <t...@seemywebsite.please> wrote:
>>>
>>>>On Fri, 22 Mar 2013 21:22:19 +0000, dbr wrote:
>>>>
>>>>> Tim - is the voltage supplied from a pulse width modulated source?
>>>>> If so,
>>>>> is it measured or calculated?
>>>>>
>>>>>
>>>>Calculated from PWM. But verified on an O-scope and it looks pretty
>>>>good.
>>>
>>> How calculated from PWM?
>>>
>>> Flyback diode? Or full H-bridge?
>>
>>Full H-bridge. There'd be no way of knowing with flyback diodes --
>>you'd have to measure.
>
> The motor needs to reverse?
>
> See my other posts, I'm no longer certain that a flyback diode hurts you
> calculation in the slightest.
>
I think a flyback diode could easily be included in the calculations.
Discontinuous mode would pretty much kill off any chance of being able to
figure things out without direct measurement -- fortunately I don't have
to worry about that in the least.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Tim Wescott
Mar 25, 2013, 6:15:01 PM3/25/13
to
means "Tim is outsmarting himself again").
Vrail = 24V
torque constant ~ 0.15 N-m/A
Torque (and hence current) is highly variable in normal operation, as are
speed commands.
John Larkin
Mar 25, 2013, 6:18:39 PM3/25/13
to
On Mon, 25 Mar 2013 17:15:01 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>On Sat, 23 Mar 2013 23:09:20 +0000, Fred Bartoli wrote:
>
>> Le Sat, 23 Mar 2013 16:39:14 -0500, Tim Wescott a �crit:
How do you measure motor current, with all that h-bridge flailing
going on?
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
wrote:
>On Sat, 23 Mar 2013 23:09:20 +0000, Fred Bartoli wrote:
>
>>
>>> On Sat, 23 Mar 2013 15:37:54 +0000, Fred Bartoli wrote:
>>>
>>>> Le Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott a �crit:
>>> On Sat, 23 Mar 2013 15:37:54 +0000, Fred Bartoli wrote:
>>>
going on?
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
Jim Thompson
Mar 25, 2013, 6:47:22 PM3/25/13
to
On Mon, 25 Mar 2013 17:10:58 -0500, Tim Wescott <t...@seemywebsite.com>
The flyback diode does NOT effect the calculations. There's a
subtlety there that _even_I_ overlooked at first ;-)
Could you share your schematic? Privately to me if you prefer.
subtlety there that _even_I_ overlooked at first ;-)
Could you share your schematic? Privately to me if you prefer.
josephkk
Mar 28, 2013, 3:59:37 AM3/28/13
to
On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
Not per se. But this sounds kind of like a two terminal R versus 4
terminal R type problem. Is the wiring resistance between the controller
and the motor enough to account for this?
?-)
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
terminal R type problem. Is the wiring resistance between the controller
and the motor enough to account for this?
?-)
josephkk
Mar 28, 2013, 4:17:30 AM3/28/13
to
On Sun, 24 Mar 2013 13:49:10 -0700, Fred Abse
<excret...@invalid.invalid> wrote:
>On Fri, 22 Mar 2013 21:49:55 +0000, Frank Miles wrote:
>
>> My WAG is that your "armature resistance" is not really a constant. There
>> will be times when (depending on the commutator) the brushes will likely
>> be connected to two separate windings; other times only one. Given
>> sufficient rpm you could probably use some time-averaged value; is that
>> what you've done?
>
>Many (most?) DC motors have brushes that span more than one commutator
>segment.
And my mind went ding. I have seen an awful lot of two brush DC motors
that have an odd number of commutator segments. Thus most of the time one
of the brushes is spanning two segments. It is a thought.
?-)
<excret...@invalid.invalid> wrote:
>On Fri, 22 Mar 2013 21:49:55 +0000, Frank Miles wrote:
>
>> My WAG is that your "armature resistance" is not really a constant. There
>> will be times when (depending on the commutator) the brushes will likely
>> be connected to two separate windings; other times only one. Given
>> sufficient rpm you could probably use some time-averaged value; is that
>> what you've done?
>
>Many (most?) DC motors have brushes that span more than one commutator
>segment.
And my mind went ding. I have seen an awful lot of two brush DC motors
that have an odd number of commutator segments. Thus most of the time one
of the brushes is spanning two segments. It is a thought.
?-)
Tim Wescott
Mar 28, 2013, 11:39:10 AM3/28/13
to
resistance.
Jim Thompson
Mar 28, 2013, 1:06:13 PM3/28/13
to
at stall... "stall" I presume means you're running 100% duty cycle, so
no flyback diode involved?
That's why I keep asking for a schematic, or at least a command
equation... I suspect Vdiode is in your equation, when it doesn't
belong.
Spehro Pefhany
Mar 28, 2013, 2:15:29 PM3/28/13
to
you can read too much into that. Stick-slip friction and such like.
Jim Thompson
Mar 28, 2013, 2:31:23 PM3/28/13
to
Spehro Pefhany
Mar 28, 2013, 2:33:47 PM3/28/13
to
On Thu, 28 Mar 2013 11:31:23 -0700, Jim Thompson
No, but it may explain why there is no offset at zero RPM.
Tim Wescott
Mar 28, 2013, 2:33:54 PM3/28/13
to
power rail --o---
|
|
fet driver --> FET
|
o--------- MOTOR -----> other half bridge
|
fet driver --> FET
|
current sense --o
|
.-.
| | current sense R
'-'
|
current return -o
|
---
GND
Current, Im, is sensed with a Kelvin connection from the current sense
resistor to an op-amp (to reduce ground issues) to a pair of ADC channels
which sample at the center of the lower FET on time. Then the ADC
readings are subtracted to get motor current.
Voltage is sensed at the rail, and computed as
Vm = 2 * (1 - rho) * Vsupply,
where rho is the duty cycle from 0 to 1 (50% being off).
Speed is computed as Wm = (Vm - Ra * Im) / k_t
Speed is regulated with a PID loop that commands motor current, motor
current is regulated with a PI loop that commands duty cycle. That's
lots-o-loops, but it's nicely stable and I have a need to interpose
current and speed limits, which fit very nicely into those loops.
The problem is not with the loops, or at least not something overt with
the loops -- I can look at the computed speed, and its average matches
the commanded speed quite nicely.
Jim Thompson
Mar 28, 2013, 2:41:56 PM3/28/13
to
On Thu, 28 Mar 2013 13:33:54 -0500, Tim Wescott <t...@seemywebsite.com>
Now I'm confused ;-) Where's the offset?
If the "average" speed matches the commanded speed, I don't understand
the problem... that's what is should be. Is the ripple confusing your
computation?
I've used a full-H-bridge to drive motors, but I use one side to set
direction (held low) and PWM the other side... then change direction
by swapping side functions.
If the "average" speed matches the commanded speed, I don't understand
the problem... that's what is should be. Is the ripple confusing your
computation?
I've used a full-H-bridge to drive motors, but I use one side to set
direction (held low) and PWM the other side... then change direction
by swapping side functions.
Tim Wescott
Mar 28, 2013, 3:39:45 PM3/28/13
to
speed reads about 30RPM high of actual. That's the offset.
> I've used a full-H-bridge to drive motors, but I use one side to set
> direction (held low) and PWM the other side... then change direction by
> swapping side functions.
it makes for a hiccup around zero drive. I could do it that way with a
few lines of code, but experience has shown that if you're reversing
voltage a lot it's not smooth.
(I dunno if the "reversing voltage" concern makes a difference here or
not -- I have to admit that banging both half bridges at the same time is
a long-time habit.)
Jim Thompson
Mar 28, 2013, 5:37:24 PM3/28/13
to
On Thu, 28 Mar 2013 14:39:45 -0500, Tim Wescott <t...@seemywebsite.com>
A habit I avoid, at least in my video iris controls ;-)
I often independently control all 4 devices in a full-H-bridge... to
contain body currents to safe levels.
I often independently control all 4 devices in a full-H-bridge... to
contain body currents to safe levels.
Tim Wescott
Mar 28, 2013, 5:50:00 PM3/28/13
to
discretes, or just an integrated-driver sort of things?
Mostly what I'm doing is driving the H-bridge the way that the
microprocessor is set up to do. It's easy enough if you stay within the
confines of what the hardware can handle, hard if you go outside of that.
Jim Thompson
Mar 28, 2013, 6:48:15 PM3/28/13
to
On Thu, 28 Mar 2013 16:50:00 -0500, Tim Wescott <t...@seemywebsite.com>
It's not clear to me how you extract Vbemf that way. Maybe it'll
register... sometimes I tend toward slow ;-)
I'll behavioral model the situation and play it.
register... sometimes I tend toward slow ;-)
I'll behavioral model the situation and play it.
Jim Thompson
Mar 28, 2013, 6:56:57 PM3/28/13
to
On Thu, 28 Mar 2013 13:33:54 -0500, Tim Wescott <t...@seemywebsite.com>
This _is_ a PM motor, right? No field winding, either parallel or in
series?
series?
Spehro Pefhany
Mar 28, 2013, 6:57:29 PM3/28/13
to
On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
<t...@seemywebsite.com> wrote:
>
>
>Mostly what I'm doing is driving the H-bridge the way that the
>microprocessor is set up to do. It's easy enough if you stay within the
>confines of what the hardware can handle, hard if you go outside of that.
Are you sure you're not getting an effective DC offset as a result of
<t...@seemywebsite.com> wrote:
>
>
>Mostly what I'm doing is driving the H-bridge the way that the
>microprocessor is set up to do. It's easy enough if you stay within the
>confines of what the hardware can handle, hard if you go outside of that.
the dead time control of the PWM?
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Glen Walpert
Mar 28, 2013, 7:05:25 PM3/28/13
to
On Thu, 28 Mar 2013 13:33:54 -0500, Tim Wescott wrote:
>>>>>My problem is that my equipment is consistently sensing the speed as
>>>>>being faster than it really is, by a constant amount -- except when
>>>>>the motor is stalled, when the reading is correctly zero. So I end
>>>>>up servoing the motor speed to a figure that's a 20-30 RPM higher
>>>>>than desired.
>
>>>>>My problem is that my equipment is consistently sensing the speed as
>>>>>being faster than it really is, by a constant amount -- except when
>>>>>the motor is stalled, when the reading is correctly zero. So I end
>>>>>up servoing the motor speed to a figure that's a 20-30 RPM higher
>>>>>than desired.
>
> The schematic is two half bridges:
>
> power rail --o---
> |
> |
> fet driver --> FET
> |
> o--------- MOTOR -----> other half bridge |
> fet driver --> FET
> |
> current sense --o
> |
> .-.
> | | current sense R '-'
> |
> current return -o
> |
> ---
> GND
>
> Current, Im, is sensed with a Kelvin connection from the current sense
> resistor to an op-amp (to reduce ground issues) to a pair of ADC
> channels which sample at the center of the lower FET on time. Then the
> ADC readings are subtracted to get motor current.
>
> Voltage is sensed at the rail, and computed as
>
> Vm = 2 * (1 - rho) * Vsupply,
>
> where rho is the duty cycle from 0 to 1 (50% being off).
>
> Speed is computed as Wm = (Vm - Ra * Im) / k_t
As someone else mentioned, computed speed would be lower by a fixed
>
> power rail --o---
> |
> |
> fet driver --> FET
> |
> o--------- MOTOR -----> other half bridge |
> fet driver --> FET
> |
> current sense --o
> |
> .-.
> | | current sense R '-'
> |
> current return -o
> |
> ---
> GND
>
> Current, Im, is sensed with a Kelvin connection from the current sense
> resistor to an op-amp (to reduce ground issues) to a pair of ADC
> channels which sample at the center of the lower FET on time. Then the
> ADC readings are subtracted to get motor current.
>
> Voltage is sensed at the rail, and computed as
>
> Vm = 2 * (1 - rho) * Vsupply,
>
> where rho is the duty cycle from 0 to 1 (50% being off).
>
> Speed is computed as Wm = (Vm - Ra * Im) / k_t
offset if the a constant brush voltage drop is included in your
calculation:
Wm = (Vm - Vbrush - (Ra * Im)) / k_t
Rejected because? (I may have missed some of the discussion on this).
Jim Thompson
Mar 28, 2013, 7:14:33 PM3/28/13
to
On Thu, 28 Mar 2013 18:57:29 -0400, Spehro Pefhany
<spef...@interlogDOTyou.knowwhat> wrote:
>On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
><t...@seemywebsite.com> wrote:
>
>>
>>
>>Mostly what I'm doing is driving the H-bridge the way that the
>>microprocessor is set up to do. It's easy enough if you stay within the
>>confines of what the hardware can handle, hard if you go outside of that.
>
>Are you sure you're not getting an effective DC offset as a result of
>the dead time control of the PWM?
>
>
>Best regards,
>Spehro Pefhany
Yup. That _might_ be adding 2 body diode forwards to the "broth" ;-)
<spef...@interlogDOTyou.knowwhat> wrote:
>On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
><t...@seemywebsite.com> wrote:
>
>>
>>
>>Mostly what I'm doing is driving the H-bridge the way that the
>>microprocessor is set up to do. It's easy enough if you stay within the
>>confines of what the hardware can handle, hard if you go outside of that.
>
>Are you sure you're not getting an effective DC offset as a result of
>the dead time control of the PWM?
>
>
>Best regards,
>Spehro Pefhany
George Herold
Mar 28, 2013, 7:19:49 PM3/28/13
to
>
> - Show quoted text -
Yeah, I know jack about motors, but what about this Tim?
For your static measurement what happens if you hold the motor in
place and run some current through it?
George H.
Tim Wescott
Mar 28, 2013, 7:25:50 PM3/28/13
to
Tim Wescott
Mar 28, 2013, 7:26:27 PM3/28/13
to
On Thu, 28 Mar 2013 16:19:49 -0700, George Herold wrote:
> Yeah, I know jack about motors, but what about this Tim? For your static
> measurement what happens if you hold the motor in place and run some
> current through it?
Oh, it works great in the static case.
> Yeah, I know jack about motors, but what about this Tim? For your static
> measurement what happens if you hold the motor in place and run some
> current through it?
Tim Wescott
Mar 28, 2013, 7:29:38 PM3/28/13
to
On Thu, 28 Mar 2013 18:57:29 -0400, Spehro Pefhany wrote:
> On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
> <t...@seemywebsite.com> wrote:
>
>
>>
>>Mostly what I'm doing is driving the H-bridge the way that the
>>microprocessor is set up to do. It's easy enough if you stay within the
>>confines of what the hardware can handle, hard if you go outside of
>>that.
>
> Are you sure you're not getting an effective DC offset as a result of
> the dead time control of the PWM?
Well, first, the dead time is a minuscule fraction of the PWM cycle time
> On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
> <t...@seemywebsite.com> wrote:
>
>
>>
>>Mostly what I'm doing is driving the H-bridge the way that the
>>microprocessor is set up to do. It's easy enough if you stay within the
>>confines of what the hardware can handle, hard if you go outside of
>>that.
>
> Are you sure you're not getting an effective DC offset as a result of
> the dead time control of the PWM?
-- fast FETs are cheap these days, and motors seem to prefer PWM speeds
in the low 10's of kHz.
And second, just today I made an RC filter so that I could clip a volt
meter onto my motor leads and get a nice filtered DC to the meter. It
reads within 1% of the voltage I calculate from the duty cycle and motor
supply voltage.
(You cannot beat measurements. When all your calculations are going to
hell -- measure).
Tim Wescott
Mar 28, 2013, 7:30:53 PM3/28/13
to
George Herold
Mar 28, 2013, 7:34:51 PM3/28/13
to
George H.
>
> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wescottdesign.com- Hide quoted text -
> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
George Herold
Mar 28, 2013, 7:38:22 PM3/28/13
to
On Mar 28, 7:29 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Thu, 28 Mar 2013 18:57:29 -0400, Spehro Pefhany wrote:
> > On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
> > <t...@seemywebsite.com> wrote:
>
> >>Mostly what I'm doing is driving the H-bridge the way that the
> >>microprocessor is set up to do. It's easy enough if you stay within the
> >>confines of what the hardware can handle, hard if you go outside of
> >>that.
>
> > Are you sure you're not getting an effective DC offset as a result of
> > the dead time control of the PWM?
>
> Well, first, the dead time is a minuscule fraction of the PWM cycle time
> -- fast FETs are cheap these days, and motors seem to prefer PWM speeds
> in the low 10's of kHz.
>
> And second, just today I made an RC filter so that I could clip a volt
> meter onto my motor leads and get a nice filtered DC to the meter. It
> reads within 1% of the voltage I calculate from the duty cycle and motor
> supply voltage.
>
> (You cannot beat measurements. When all your calculations are going to
> hell -- measure).
OK then my final plan of attack is to try and make it worse!
> On Thu, 28 Mar 2013 18:57:29 -0400, Spehro Pefhany wrote:
> > On Thu, 28 Mar 2013 16:50:00 -0500, the renowned Tim Wescott
> > <t...@seemywebsite.com> wrote:
>
> >>Mostly what I'm doing is driving the H-bridge the way that the
> >>microprocessor is set up to do. It's easy enough if you stay within the
> >>confines of what the hardware can handle, hard if you go outside of
> >>that.
>
> > Are you sure you're not getting an effective DC offset as a result of
> > the dead time control of the PWM?
>
> Well, first, the dead time is a minuscule fraction of the PWM cycle time
> -- fast FETs are cheap these days, and motors seem to prefer PWM speeds
> in the low 10's of kHz.
>
> And second, just today I made an RC filter so that I could clip a volt
> meter onto my motor leads and get a nice filtered DC to the meter. It
> reads within 1% of the voltage I calculate from the duty cycle and motor
> supply voltage.
>
> (You cannot beat measurements. When all your calculations are going to
> hell -- measure).
Inductive? Stick more iron around it,
Thermal... heat and cool.
Add some more cable here... resistance there...
George H.
josephkk
Mar 28, 2013, 10:12:59 PM3/28/13
to
On Thu, 28 Mar 2013 13:33:54 -0500, Tim Wescott <t...@seemywebsite.com>
Could i persuade you to post a waveform of the R-sense voltages and the
inputs to the ADCs? Could you also compare the timing of the ADC trigger
commands?
?-)
inputs to the ADCs? Could you also compare the timing of the ADC trigger
commands?
?-)
Tim Wescott
Mar 28, 2013, 11:52:58 PM3/28/13
to
and verified correct.
Bill Sloman
Mar 29, 2013, 4:58:20 AM3/29/13
to
Bill Sloman
Mar 29, 2013, 5:03:01 AM3/29/13
to
current you drive through the motor winding acts to reduce the
magnetic field that the permanent magnets are creating at the motor
windings. Not much, but maybe enough to mess up your calculations.
--
Bill Sloman, Sydney
Glen Walpert
Mar 29, 2013, 4:11:08 PM3/29/13
to
the voltage drop across the brushes can only dissipate energy not create
it then including brush drop always results in a lower calculated (and
real) rotor winding voltage and therefore speed, regardless of direction,
as long as you do not regenerate (use the motor as a generator), although
sign consistency should get you the correct answer there too. Adjust
brush voltage drop factor in your calculation for minimum calculated to
real speed error. Tweak it on the fly based on measured error, and have
the controller request motor brush service when the calculated brush
voltage drop factor goes above 3 volts or so :-).
Jamie
Mar 29, 2013, 7:19:54 PM3/29/13
to
that no one is touching on is the field of the motor?
I see in early post it was stated that it has no field(stator) coil,
this means it is a PM motor. (Most likely)
In case some one needs a refresher in the effects of variable field
densities, it will vary the speed of the motor with a fixed armature
voltage applied.
Being it is a PM motor, weaker field will cause more RPMs and of
course stronger fields more foot lbs but less RPMS at the same
armature voltage.
Motor temperature is going to make the PMs change their density. As
they heat up, they'll attempt to spin faster at the same arm voltage but
also increase the current slightly.
Then you start putting loads on the shaft, the motor is going to drop
back and exert additional current from the drive which will increase the
magnetic field in the armature to only increase speed in the hopes of
bringing it back to speed per armature voltage, which it never makes it
to the speed of unloaded conditions.
There is the function of auto field control to help maintain the motor
RPM at vary loads, which reflect back to the drive electronics as
armature current. But since we have a PM motor, that just isn't going to
work here.
How many of those remember the DC motors used in tape drive systems
that had the centrifugal speed control electronics integrated in them?
There was a good reason for that of course, mostly due to the facts
that similar attempts were made to maintain a controlled speed with DC
brushed motors with no feed back..
Simply put, a good many DC drives do have current compensation controls
on them when feed back is not in use. They scale the output verse A(i)
and must be set at installation time.
That's my rant for this holiday weekend.
Jamie
Jim Thompson
Mar 29, 2013, 7:08:48 PM3/29/13
to
On Thu, 28 Mar 2013 16:50:00 -0500, Tim Wescott <t...@seemywebsite.com>
Is the current sense resistor common to both halves of the H-bridge?
What is its value relative to the motor winding resistance?
What is its value relative to the motor winding resistance?
MarkK
Mar 29, 2013, 9:34:41 PM3/29/13
to
>
> The average _computed_ speed matches the commanded speed. The computed
> speed reads about 30RPM high of actual. That's the offset.
>
>
I don't understand.
> The average _computed_ speed matches the commanded speed. The computed
> speed reads about 30RPM high of actual. That's the offset.
>
>
At 0 RPM, there is no error?
At all other RPMs , the error = 30 RPM?
so at 1 PRM it read 31?
Is it an offset error or a gain error?
Again, I suggest as a troubleshooting aid, you program the error out by
whatever fudge factor it takes. Then analyze the fudge factor.
Mark
josephkk
Mar 30, 2013, 8:37:23 AM3/30/13
to
On Thu, 28 Mar 2013 22:52:58 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>
at least make the measurements asked.
?-)
wrote:
>
>>>Speed is regulated with a PID loop that commands motor current, motor
>>>current is regulated with a PI loop that commands duty cycle. That's
>>>lots-o-loops, but it's nicely stable and I have a need to interpose
>>>current and speed limits, which fit very nicely into those loops.
>>>
>>>The problem is not with the loops, or at least not something overt with
>>>the loops -- I can look at the computed speed, and its average matches
>>>the commanded speed quite nicely.
>>
>> Could i persuade you to post a waveform of the R-sense voltages and the
>> inputs to the ADCs? Could you also compare the timing of the ADC
>> trigger commands?
>
>Motor current readings have also been double-checked with a multimeter
>and verified correct.
That is not what i asked. I do not so much care if you post, but that you
>>>current is regulated with a PI loop that commands duty cycle. That's
>>>lots-o-loops, but it's nicely stable and I have a need to interpose
>>>current and speed limits, which fit very nicely into those loops.
>>>
>>>The problem is not with the loops, or at least not something overt with
>>>the loops -- I can look at the computed speed, and its average matches
>>>the commanded speed quite nicely.
>>
>> Could i persuade you to post a waveform of the R-sense voltages and the
>> inputs to the ADCs? Could you also compare the timing of the ADC
>> trigger commands?
>
>Motor current readings have also been double-checked with a multimeter
>and verified correct.
at least make the measurements asked.
?-)
Jim Thompson
Mar 30, 2013, 4:11:26 PM3/30/13
to
On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
Another test, switching, varying both duty-cycle and VM...
http://www.analog-innovations.com/SED/MotorDriver_PWM_Steps.pdf
So my latest suspicion is that the voltage across the sense resistor,
due to the full-H drive, flips sign and is not accounted for in the
math.
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
http://www.analog-innovations.com/SED/MotorDriver_PWM_Steps.pdf
So my latest suspicion is that the voltage across the sense resistor,
due to the full-H drive, flips sign and is not accounted for in the
math.
Jim Thompson
Mar 30, 2013, 4:51:08 PM3/30/13
to
Vspeed = (2*Duty - 1)*Vcc - Imotor*(Rmotor + Rsense)
Tim Wescott
Mar 30, 2013, 11:14:03 PM3/30/13
to
wouldn't be able to prevent myself -- but thanks anyway).
The current is measured in the middle of the on-time of the lower FETs of
the bridge. Because of the way that the processor wants to drive the FETs
this happens to be at the same time, but that's probably immaterial (if
anything it should help).
To the extent that the current thusly measured is representative (and it
certainly double-checks against meter readings pretty well) it does not
need to get flipped -- the current read at the - terminal of the motor is
subtracted from the current read at the + terminal of the motor, and
that's that.
(In theory I could just use one -- with two I get a bit of improved SNR).
>
> I think this is the proper equation...
>
> Vspeed = (2*Duty - 1)*Vcc - Imotor*(Rmotor + Rsense)
should take Rsense into account (Rmotor also visibly changes with
temperature, by much more than Rsense).
In operation there is a "drive" variable that ranges from -1 to 1, from
which the duty cycle is computed such that -1 drive generates a duty
cycle of 100% in the minus direction and +1 drive generates a duty cycle
of 100% in the plus direction. Then the drive absolute value is limited
to a bit less than 1 so that the charge pumps work correctly and so that
the current reading settles before the ADC reads it.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Jim Thompson
Mar 31, 2013, 12:12:37 PM3/31/13
to
the wife was attending her annual Easter brunch with a bunch of
retired Girl Scout Leaders she's worked with for 40 years, so I was
"home alone" ;-)
I've never encountered this sort of problem... my motors haven't had
to turn around on the fly, so I was trying to find how a fixed offset
could get in there _before_ it happens to me on an actual project.
>
>The current is measured in the middle of the on-time of the lower FETs of
>the bridge. Because of the way that the processor wants to drive the FETs
>this happens to be at the same time, but that's probably immaterial (if
>anything it should help).
by digital ;-)
>
>To the extent that the current thusly measured is representative (and it
>certainly double-checks against meter readings pretty well) it does not
>need to get flipped -- the current read at the - terminal of the motor is
>subtracted from the current read at the + terminal of the motor, and
>that's that.
in essence, add?
>
>(In theory I could just use one -- with two I get a bit of improved SNR).
>
>>
>> I think this is the proper equation...
>>
>> Vspeed = (2*Duty - 1)*Vcc - Imotor*(Rmotor + Rsense)
>
>It looks like it. Rmotor is calibrated for what works in practice, which
>should take Rsense into account (Rmotor also visibly changes with
>temperature, by much more than Rsense).
>
>In operation there is a "drive" variable that ranges from -1 to 1, from
>which the duty cycle is computed such that -1 drive generates a duty
>cycle of 100% in the minus direction and +1 drive generates a duty cycle
>of 100% in the plus direction. Then the drive absolute value is limited
>to a bit less than 1 so that the charge pumps work correctly and so that
>the current reading settles before the ADC reads it.
Nico Coesel
Mar 31, 2013, 3:16:04 PM3/31/13
to
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Jim Thompson
Mar 31, 2013, 6:41:46 PM3/31/13
to
On Sun, 31 Mar 2013 09:12:37 -0700, Jim Thompson
I have verified my Algebraic rendition via simulation, so we're left
with two scenarios, (1) Your implementation has a flaw, or (2) We're
both missing something in the modeling of the motor, perhaps the
brush/commutator overlap??
Time for some lab work >:-}
with two scenarios, (1) Your implementation has a flaw, or (2) We're
both missing something in the modeling of the motor, perhaps the
brush/commutator overlap??
Time for some lab work >:-}
Jim Thompson
Apr 1, 2013, 12:41:03 PM4/1/13
to
On Fri, 22 Mar 2013 12:51:29 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
I don't have access to IEEE, but this paper may point you in the right
wrote:
>I'm working on a project that involves replacing some existing
>electronics with some that I've designed. It's controlling the speed of
>DC brushed motors. Since the original equipment uses a knowledge of the
>applied voltage and the motor current to infer back EMF and therefor
>motor speed, that's what I've done, too.
>
>My problem is that my equipment is consistently sensing the speed as
>being faster than it really is, by a constant amount -- except when the
>motor is stalled, when the reading is correctly zero. So I end up
>servoing the motor speed to a figure that's a 20-30 RPM higher than
>desired.
>
>It's not just a mis-calibration of the motor torque constant or the
>resistance -- if that were the case, then the motor speed error would
>depend on the command speed or the applied torque. I can easily
>calibrate out any dependence on torque (by adjusting the calibrated motor
>resistance) and I can get a 1:1 correspondence between increments in the
>commanded speed and increments in the actual speed. But I'm left with
>this @#$% offset.
>
>Has anyone seen this? Anyone care to hazard a guess at what's going on?
>
>Thanks.
direction....
Xplore
IEEE
Modeling of universal motor performance and brush commutation using
finite element computed inductance and resistance matrices
http://tinyurl.com/d77rqpe
Tim Wescott
Apr 1, 2013, 1:49:43 PM4/1/13
to
On Sun, 31 Mar 2013 19:16:04 +0000, Nico Coesel wrote:
> Tim Wescott <t...@seemywebsite.com> wrote:
>
>>On Thu, 28 Mar 2013 19:12:59 -0700, josephkk wrote:
>>
>>> On Thu, 28 Mar 2013 13:33:54 -0500, Tim Wescott <t...@seemywebsite.com>
>>> wrote:
>>>
>>> Could i persuade you to post a waveform of the R-sense voltages and
>>> the inputs to the ADCs? Could you also compare the timing of the ADC
>>> trigger commands?
>>
>>Motor current readings have also been double-checked with a multimeter
>>and verified correct.
>
> But are they the same the ADC in the microcontroller is measuring?
The motor current readings _from the microcontroller_ have been double-
> Tim Wescott <t...@seemywebsite.com> wrote:
>
>>On Thu, 28 Mar 2013 19:12:59 -0700, josephkk wrote:
>>
>>> On Thu, 28 Mar 2013 13:33:54 -0500, Tim Wescott <t...@seemywebsite.com>
>>> wrote:
>>>
>>> Could i persuade you to post a waveform of the R-sense voltages and
>>> the inputs to the ADCs? Could you also compare the timing of the ADC
>>> trigger commands?
>>
>>Motor current readings have also been double-checked with a multimeter
>>and verified correct.
>
> But are they the same the ADC in the microcontroller is measuring?
checked with a multimeter. So yes, by definition they're the same.
Tim Wescott
Apr 1, 2013, 1:58:25 PM4/1/13
to
outsmarting myself.
The point of the sampling is to pick the time where the current reading
represents the average current in the motor. The current in the motor
coils is a sawtooth + DC; sampling in the center of the bottom FET on-
time gets you right in the center of the rising segment of the sawtooth,
which gets you the average motor current that cycle. (Again, assuming
I'm not outsmarting myself).
>>To the extent that the current thusly measured is representative (and it
>>certainly double-checks against meter readings pretty well) it does not
>>need to get flipped -- the current read at the - terminal of the motor
>>is subtracted from the current read at the + terminal of the motor, and
>>that's that.
>
> How is that done??? Do you mean that one sample is negative, so they,
> in essence, add?
on the "+" bottom FET is negative and the current on the "-" bottom FET
is positive. So the "subtraction" is really an add.
>>(In theory I could just use one -- with two I get a bit of improved
>>SNR).
>>
>>
>>> I think this is the proper equation...
>>>
>>> Vspeed = (2*Duty - 1)*Vcc - Imotor*(Rmotor + Rsense)
>>
>>It looks like it. Rmotor is calibrated for what works in practice,
>>which should take Rsense into account (Rmotor also visibly changes with
>>temperature, by much more than Rsense).
>>
>>In operation there is a "drive" variable that ranges from -1 to 1, from
>>which the duty cycle is computed such that -1 drive generates a duty
>>cycle of 100% in the minus direction and +1 drive generates a duty cycle
>>of 100% in the plus direction. Then the drive absolute value is limited
>>to a bit less than 1 so that the charge pumps work correctly and so that
>>the current reading settles before the ADC reads it.
>
> Charge pumps? Schematic?
most of the H-bridge gate driver chips out there have a charge pump for
the high-side gate, to allow you to use N-channel high-side transistors.
When the bottom FET turns on it charges up the boost cap for the high
side through a diode; when the driver turns on the top FET it uses that
boost cap to supply the gate voltage for the top FET.
It's all very clever, and on a bazzilion different gate driver chips. If
there's someone out there doing something different I can't call it to
mind.
Jasen Betts
Apr 1, 2013, 2:29:08 PM4/1/13
to
On 2013-04-01, Tim Wescott <t...@seemywebsite.com> wrote:
> Clever sampling can save you a lot of grief. 'course, I may be
> outsmarting myself.
>
> The point of the sampling is to pick the time where the current reading
> represents the average current in the motor. The current in the motor
> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
> time gets you right in the center of the rising segment of the sawtooth,
> which gets you the average motor current that cycle. (Again, assuming
> I'm not outsmarting myself).
That'll be an logarythmic curve, right? what's the time constant?
> Clever sampling can save you a lot of grief. 'course, I may be
> outsmarting myself.
>
> The point of the sampling is to pick the time where the current reading
> represents the average current in the motor. The current in the motor
> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
> time gets you right in the center of the rising segment of the sawtooth,
> which gets you the average motor current that cycle. (Again, assuming
> I'm not outsmarting myself).
--
⚂⚃ 100% natural
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Jim Thompson
Apr 1, 2013, 2:38:33 PM4/1/13
to
On 1 Apr 2013 18:29:08 GMT, Jasen Betts <ja...@xnet.co.nz> wrote:
>On 2013-04-01, Tim Wescott <t...@seemywebsite.com> wrote:
>
>> Clever sampling can save you a lot of grief. 'course, I may be
>> outsmarting myself.
>>
>> The point of the sampling is to pick the time where the current reading
>> represents the average current in the motor. The current in the motor
>> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
>> time gets you right in the center of the rising segment of the sawtooth,
>> which gets you the average motor current that cycle. (Again, assuming
>> I'm not outsmarting myself).
>
>That'll be an logarythmic curve, right? what's the time constant?
Unless it's a very crappy motor the time constant will be long enough
>On 2013-04-01, Tim Wescott <t...@seemywebsite.com> wrote:
>
>> Clever sampling can save you a lot of grief. 'course, I may be
>> outsmarting myself.
>>
>> The point of the sampling is to pick the time where the current reading
>> represents the average current in the motor. The current in the motor
>> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
>> time gets you right in the center of the rising segment of the sawtooth,
>> which gets you the average motor current that cycle. (Again, assuming
>> I'm not outsmarting myself).
>
>That'll be an logarythmic curve, right? what's the time constant?
to consider the segment linear.
Tim Williams
Apr 1, 2013, 4:02:09 PM4/1/13
to
"Tim Wescott" <t...@seemywebsite.com> wrote in message
news:dpmdnYKGTZNcV8TM...@giganews.com...
current going on a ramp or some other curve, it all goes out the window.
Eddy current losses cause an "instant" jump in current, proportional to
the change in voltage, while DCR introduces an L/R time constant, shifting
the average-crossing point a little earlier than half. Think of the
transformer equivalent model:
. Rdc Lleak
. o---RRR----LLL---+--------+
. | |
. L Lp R Reddy
. L R
. | |
. o----------------+--------+
Plus (in the case of a transformer proper) whatever secondary load
connects across Lp. (Note that Lleak and Lp are divided proportionally,
strictly speaking; an L-equivalent circuit like this is only reasonably
true for k ~= 1.) In a motor, this might amount to harmonics induced from
the finite number of rotor poles and how their exact magnetic profile
differs from an ideal circle, but that's all slow-rotatey-stuff that gets
averaged and lumped in with DC current (which does most of the real work).
If you sliding-average a pair of "middle" samples (one up, one down), it
automatically accounts for the DCR sample error.
I would just as well sample frequently and filter down (takes lots of
sampling + DSP), or slow it down analog (a couple analog poles isn't all
that fast in response) and sample it at my leisure. Trying to do tricky
sample-in-the-middle business is going to get awkward around variable
slopes and timing (how do you know you've sampled in the middle of both
halves of a 2% or 98% duty cycle waveform, and how is that affected by the
sample-and-hold aperture?).
I doubt this is the problem you're having, just... nuts and bolts, eh?
Tim
--
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com
news:dpmdnYKGTZNcV8TM...@giganews.com...
> Clever sampling can save you a lot of grief. 'course, I may be
> outsmarting myself.
>
> The point of the sampling is to pick the time where the current reading
> represents the average current in the motor. The current in the motor
> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
> time gets you right in the center of the rising segment of the sawtooth,
> which gets you the average motor current that cycle. (Again, assuming
> I'm not outsmarting myself).
Not true in the presence of losses, and of course, any time you've got
> outsmarting myself.
>
> The point of the sampling is to pick the time where the current reading
> represents the average current in the motor. The current in the motor
> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
> time gets you right in the center of the rising segment of the sawtooth,
> which gets you the average motor current that cycle. (Again, assuming
> I'm not outsmarting myself).
current going on a ramp or some other curve, it all goes out the window.
Eddy current losses cause an "instant" jump in current, proportional to
the change in voltage, while DCR introduces an L/R time constant, shifting
the average-crossing point a little earlier than half. Think of the
transformer equivalent model:
. Rdc Lleak
. o---RRR----LLL---+--------+
. | |
. L Lp R Reddy
. L R
. | |
. o----------------+--------+
Plus (in the case of a transformer proper) whatever secondary load
connects across Lp. (Note that Lleak and Lp are divided proportionally,
strictly speaking; an L-equivalent circuit like this is only reasonably
true for k ~= 1.) In a motor, this might amount to harmonics induced from
the finite number of rotor poles and how their exact magnetic profile
differs from an ideal circle, but that's all slow-rotatey-stuff that gets
averaged and lumped in with DC current (which does most of the real work).
If you sliding-average a pair of "middle" samples (one up, one down), it
automatically accounts for the DCR sample error.
I would just as well sample frequently and filter down (takes lots of
sampling + DSP), or slow it down analog (a couple analog poles isn't all
that fast in response) and sample it at my leisure. Trying to do tricky
sample-in-the-middle business is going to get awkward around variable
slopes and timing (how do you know you've sampled in the middle of both
halves of a 2% or 98% duty cycle waveform, and how is that affected by the
sample-and-hold aperture?).
I doubt this is the problem you're having, just... nuts and bolts, eh?
Tim
--
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com
Tim Wescott
Apr 1, 2013, 4:30:11 PM4/1/13
to
On Mon, 01 Apr 2013 11:38:33 -0700, Jim Thompson wrote:
> On 1 Apr 2013 18:29:08 GMT, Jasen Betts <ja...@xnet.co.nz> wrote:
>
>>On 2013-04-01, Tim Wescott <t...@seemywebsite.com> wrote:
>>
>>> Clever sampling can save you a lot of grief. 'course, I may be
>>> outsmarting myself.
>>>
>>> The point of the sampling is to pick the time where the current
>>> reading represents the average current in the motor. The current in
>>> the motor coils is a sawtooth + DC; sampling in the center of the
>>> bottom FET on- time gets you right in the center of the rising segment
>>> of the sawtooth, which gets you the average motor current that cycle.
>>> (Again, assuming I'm not outsmarting myself).
>>
>>That'll be an logarythmic curve, right? what's the time constant?
>
> Unless it's a very crappy motor the time constant will be long enough to
> consider the segment linear.
Took the words out of my mouth. My answer was going to be "very large
> On 1 Apr 2013 18:29:08 GMT, Jasen Betts <ja...@xnet.co.nz> wrote:
>
>>On 2013-04-01, Tim Wescott <t...@seemywebsite.com> wrote:
>>
>>> Clever sampling can save you a lot of grief. 'course, I may be
>>> outsmarting myself.
>>>
>>> The point of the sampling is to pick the time where the current
>>> reading represents the average current in the motor. The current in
>>> the motor coils is a sawtooth + DC; sampling in the center of the
>>> bottom FET on- time gets you right in the center of the rising segment
>>> of the sawtooth, which gets you the average motor current that cycle.
>>> (Again, assuming I'm not outsmarting myself).
>>
>>That'll be an logarythmic curve, right? what's the time constant?
>
> Unless it's a very crappy motor the time constant will be long enough to
> consider the segment linear.
compared to the PWM frequency".
If there's curve there it's undetectable on an O-scope.
Tim Wescott
Apr 1, 2013, 4:33:25 PM4/1/13
to
though, the current sense line (A) looks nice and flat on the O-scope,
except for the wingwazzle right at the bottom FET turn-on, and (B), the
microprocessor's current measure matches the multimeter.
Point (B) trumps a lot of other arguments for me.
John Larkin
Apr 1, 2013, 5:18:50 PM4/1/13
to
On Mon, 01 Apr 2013 15:33:25 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
There are chips specifically for sensing motor currents in situations
like this. Avago has some.
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
wrote:
like this. Avago has some.
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro acquisition and simulation
Fred Bartoli
Apr 1, 2013, 5:38:52 PM4/1/13
to
Le Mon, 01 Apr 2013 12:58:25 -0500, Tim Wescott a écrit:
> Clever sampling can save you a lot of grief. 'course, I may be
> outsmarting myself.
>
> The point of the sampling is to pick the time where the current reading
> represents the average current in the motor. The current in the motor
> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
> time gets you right in the center of the rising segment of the sawtooth,
> which gets you the average motor current that cycle. (Again, assuming
> I'm not outsmarting myself).
Hmmm...
> Clever sampling can save you a lot of grief. 'course, I may be
> outsmarting myself.
>
> The point of the sampling is to pick the time where the current reading
> represents the average current in the motor. The current in the motor
> coils is a sawtooth + DC; sampling in the center of the bottom FET on-
> time gets you right in the center of the rising segment of the sawtooth,
> which gets you the average motor current that cycle. (Again, assuming
> I'm not outsmarting myself).
I suppose you have some (1st order?) LPF between the current sampling
shunt and the ADC input. With a ramp input that amounts to some delay
which translates into a fixed offset at sampling time.
Did you check the order of magnitude?
--
Thanks,
Fred.
Tim Wescott
Apr 1, 2013, 5:53:49 PM4/1/13
to
George Herold
Apr 1, 2013, 11:24:55 PM4/1/13
to
>
> - Show quoted text -
Seems you should have solved this issue. Have you tried other motors,
changed this and that. What's the effect of a bigger external
magnetic field? What happens if you hit it with a heat gun, cool
spray... (something else)?
George H.
Tim Wescott
Apr 2, 2013, 2:26:45 PM4/2/13
to
at the end of the project when the customer is more interested in
shipping product than having everything being theoretically perfect, and
we had something that would work well enough (this sort of speed control
doesn't work well unless your expectations are low at any rate).
I was mostly asking to find out if my customer and I were being insanely
picky, if this was one of those "oh yea, that happens all the time" sorts
of things, or if I'd invented some new and unique problem that I just
wasn't able to find.
It sounds like the last one, unfortunately.
Jim Thompson
Apr 2, 2013, 2:34:29 PM4/2/13
to
On Tue, 02 Apr 2013 13:26:45 -0500, Tim Wescott <t...@seemywebsite.com>
Probably just because you're trying to "code" an Analog solution ;-)
I've figured out, at least in my head, how to model brushes straddling
commutator bars. When I get time to go back to it, I'll simulate that
and see if it matters. Two arguers in my head, one says nay, one says
yea ;-)
I've figured out, at least in my head, how to model brushes straddling
commutator bars. When I get time to go back to it, I'll simulate that
and see if it matters. Two arguers in my head, one says nay, one says
yea ;-)
George Herold
Apr 2, 2013, 3:15:33 PM4/2/13
to
On Apr 2, 2:26 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Mon, 01 Apr 2013 20:24:55 -0700, George Herold wrote:
> > On Apr 1, 5:53 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> >> On Mon, 01 Apr 2013 21:38:52 +0000, Fred Bartoli wrote:
> >> > Le Mon, 01 Apr 2013 12:58:25 -0500, Tim Wescott a écrit:
>
> >> >> Clever sampling can save you a lot of grief. 'course, I may be
> >> >> outsmarting myself.
>
> >> >> The point of the sampling is to pick the time where the current
> >> >> reading represents the average current in the motor. The current in
> >> >> the motor coils is a sawtooth + DC; sampling in the center of the
> >> >> bottom FET on- time gets you right in the center of the rising
> >> >> segment of the sawtooth, which gets you the average motor current
> >> >> that cycle. (Again, assuming I'm not outsmarting myself).
>
> >> > Hmmm...
> >> > I suppose you have some (1st order?) LPF between the current sampling
> >> > shunt and the ADC input. With a ramp input that amounts to some delay
> >> > which translates into a fixed offset at sampling time.
>
> >> > Did you check the order of magnitude?
>
> >> Yes. All such filtering is parasitic and minimized as much as I can.
>
> >> --
> >> My liberal friends think I'm a conservative kook. My conservative
> >> friends think I'm a liberal kook. Why am I not happy that they have
> >> found common ground?
>
> >> Tim Wescott, Communications, Control, Circuits &
> >> Softwarehttp://www.wescottdesign.com-Hide quoted text -
> On Mon, 01 Apr 2013 20:24:55 -0700, George Herold wrote:
> > On Apr 1, 5:53 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> >> On Mon, 01 Apr 2013 21:38:52 +0000, Fred Bartoli wrote:
> >> > Le Mon, 01 Apr 2013 12:58:25 -0500, Tim Wescott a écrit:
>
> >> >> Clever sampling can save you a lot of grief. 'course, I may be
> >> >> outsmarting myself.
>
> >> >> The point of the sampling is to pick the time where the current
> >> >> reading represents the average current in the motor. The current in
> >> >> the motor coils is a sawtooth + DC; sampling in the center of the
> >> >> bottom FET on- time gets you right in the center of the rising
> >> >> segment of the sawtooth, which gets you the average motor current
> >> >> that cycle. (Again, assuming I'm not outsmarting myself).
>
> >> > Hmmm...
> >> > I suppose you have some (1st order?) LPF between the current sampling
> >> > shunt and the ADC input. With a ramp input that amounts to some delay
> >> > which translates into a fixed offset at sampling time.
>
> >> > Did you check the order of magnitude?
>
> >> Yes. All such filtering is parasitic and minimized as much as I can.
>
> >> --
> >> My liberal friends think I'm a conservative kook. My conservative
> >> friends think I'm a liberal kook. Why am I not happy that they have
> >> found common ground?
>
> >> Tim Wescott, Communications, Control, Circuits &
>
> >> - Show quoted text -
>
> > Seems you should have solved this issue. Have you tried other motors,
> > changed this and that. What's the effect of a bigger external magnetic
> > field? What happens if you hit it with a heat gun, cool spray...
> > (something else)?
>
> We've kludged in a solution that's satisfactory -- the problem cropped up
> at the end of the project when the customer is more interested in
> shipping product than having everything being theoretically perfect, and
> we had something that would work well enough (this sort of speed control
> doesn't work well unless your expectations are low at any rate).
>
> I was mostly asking to find out if my customer and I were being insanely
> picky, if this was one of those "oh yea, that happens all the time" sorts
> of things, or if I'd invented some new and unique problem that I just
> wasn't able to find.
>
> It sounds like the last one, unfortunately.
That's too bad. I've been hoping you'd chime in one day and tell us
> >> - Show quoted text -
>
> > Seems you should have solved this issue. Have you tried other motors,
> > changed this and that. What's the effect of a bigger external magnetic
> > field? What happens if you hit it with a heat gun, cool spray...
> > (something else)?
>
> We've kludged in a solution that's satisfactory -- the problem cropped up
> at the end of the project when the customer is more interested in
> shipping product than having everything being theoretically perfect, and
> we had something that would work well enough (this sort of speed control
> doesn't work well unless your expectations are low at any rate).
>
> I was mostly asking to find out if my customer and I were being insanely
> picky, if this was one of those "oh yea, that happens all the time" sorts
> of things, or if I'd invented some new and unique problem that I just
> wasn't able to find.
>
> It sounds like the last one, unfortunately.
you'd solved it. In my limited experience if you don't chase down
that last unexplained bump or wiggle, then the law of Murphy
guarantees that the wiggle will come back and bite you in the
future.
(Knock on wood, I don't want to jinx you :^)
George H.
Jim Thompson
Apr 2, 2013, 3:24:35 PM4/2/13
to
On Tue, 2 Apr 2013 12:15:33 -0700 (PDT), George Herold
<ghe...@teachspin.com> wrote:
>On Apr 2, 2:26�pm, Tim Wescott <t...@seemywebsite.com> wrote:
[snip]
<ghe...@teachspin.com> wrote:
>On Apr 2, 2:26�pm, Tim Wescott <t...@seemywebsite.com> wrote:
>>
>> I was mostly asking to find out if my customer and I were being insanely
>> picky, if this was one of those "oh yea, that happens all the time" sorts
>> of things, or if I'd invented some new and unique problem that I just
>> wasn't able to find.
>>
>> It sounds like the last one, unfortunately.
>
>That's too bad. I've been hoping you'd chime in one day and tell us
>you'd solved it. In my limited experience if you don't chase down
>that last unexplained bump or wiggle, then the law of Murphy
>guarantees that the wiggle will come back and bite you in the
>future.
>
>(Knock on wood, I don't want to jinx you :^)
>
>George H.
>>
That's why I was hanging in here so intently... so far ;-) my motor
>> I was mostly asking to find out if my customer and I were being insanely
>> picky, if this was one of those "oh yea, that happens all the time" sorts
>> of things, or if I'd invented some new and unique problem that I just
>> wasn't able to find.
>>
>> It sounds like the last one, unfortunately.
>
>That's too bad. I've been hoping you'd chime in one day and tell us
>you'd solved it. In my limited experience if you don't chase down
>that last unexplained bump or wiggle, then the law of Murphy
>guarantees that the wiggle will come back and bite you in the
>future.
>
>(Knock on wood, I don't want to jinx you :^)
>
>George H.
>>
drivers were essentially one-sided with a "reverse" switch. So this
full-H problem intrigued me... I was hoping for a solution before I'm
facing it all by myself ;-)
josephkk
Apr 2, 2013, 11:23:25 PM4/2/13
to
On Mon, 01 Apr 2013 12:58:25 -0500, Tim Wescott <t...@seemywebsite.com>
wrote:
>
hitting near the peak. 'Nuff said.
?-)
wrote:
>
>>>The current is measured in the middle of the on-time of the lower FETs
>>>of the bridge. Because of the way that the processor wants to drive the
>>>FETs this happens to be at the same time, but that's probably immaterial
>>>(if anything it should help).
>>
>> "Sampling" always bothers me. How much ripple? (Live by digital, die
>> by digital ;-)
>
>Clever sampling can save you a lot of grief. 'course, I may be
>outsmarting myself.
>
>The point of the sampling is to pick the time where the current reading
>represents the average current in the motor. The current in the motor
>coils is a sawtooth + DC; sampling in the center of the bottom FET on-
>time gets you right in the center of the rising segment of the sawtooth,
>which gets you the average motor current that cycle. (Again, assuming
>I'm not outsmarting myself).
Now if i only believed that is where you are sampling. I think you are
>>>of the bridge. Because of the way that the processor wants to drive the
>>>FETs this happens to be at the same time, but that's probably immaterial
>>>(if anything it should help).
>>
>> "Sampling" always bothers me. How much ripple? (Live by digital, die
>> by digital ;-)
>
>Clever sampling can save you a lot of grief. 'course, I may be
>outsmarting myself.
>
>The point of the sampling is to pick the time where the current reading
>represents the average current in the motor. The current in the motor
>coils is a sawtooth + DC; sampling in the center of the bottom FET on-
>time gets you right in the center of the rising segment of the sawtooth,
>which gets you the average motor current that cycle. (Again, assuming
>I'm not outsmarting myself).
hitting near the peak. 'Nuff said.
?-)
0 new messages