On Sat, 5 Dec 2009 22:12:06 -0800 (PST), pnachtwey
<pnachtwey@gmail.com> wrote:
>On Dec 5, 4:58�pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>> On Sat, 5 Dec 2009 16:39:07 -0800 (PST), pnachtwey
>>
>> <pnacht...@gmail.com> wrote:
>> >On Dec 5, 10:34�am, Jon Kirwan <j...@infinitefactors.org> wrote:
>> >> Can you talk about specifically why no SiLabs parts are adequate for
>> >> controlling a DC motor? �You brought up the issue here of 'integer
>> >> only', so I might assume that broad brush is why. �But it may not be
>> >> your reason, which is why I'm asking. �I'm interested in your thinking
>> >> here.
>> >I am not picking on Silab parts. �I wouldn't even use most 32 bit
>> >processors. �I know you can make software 32 or 48 bit accumulators
>> >but it can't be done quickly either in programming time or execution
>> >time. �The PID is such a small part of what a motion controller must
>> >do. �What about the motion profile generator? �That is the hard part
>> >if you need to process commands on-the-fly. �The calculations get to
>> >be intensive. �A lot depends on your definition of control. �A PID
>> >holding a motor at a position is very limited.
>>
>> >I say AMEN to Tim's statement about getting a microprocessor that has
>> >10 times the estimated required processing power.
>>
>> >Peter Nachtwey
>>
>> Okay. �Thanks for taking a moment to clarify. �I agree with both of
>> you about getting something grossly overpowered, as well. �If the
>> application space permits, tools are appropriate, etc.
>>
>This brings up a another excellent point. Tools are very important.
>The engineers time/cost needs to be weighed against extra costs of
>available tools or the extra cost of using a CPU with floating point.
>
>> My experience is in cost-sensitive environments, not feature-
>> sensitive, with significant pressure on what can be afforded for cpu
>> speed. �Such factors must be balanced _better_ than your competition
>> to provide a wedge to improve odds at success. �And it is better still
>> if you can 'do the impossible.' �:)
>>
>> Jon
>
>Our products are feature rich. When doing industrial motion control
>you want to have all the diagnostic/debug tools you can because
>industrial applications are rarely high volume. When in the field you
>want to get the job done and get back to the hotel, relax, and have a
>beer instead of guessing and working 14 hours days. I have had a
>customer call our product a 'get out of jail free card'.
Got it. Different worlds, in many regards. However, I've done the
customer visits on long plane flights and spending time studying their
equipment when solving difficult problems, as well. Sometimes, the
recommendations I've made have been to completely reconsider the
approach and it's caused the customer to buy a $3000 system instead of
the $100k system they were thinking of buying from my employer.. with
some ... personal difficulties when I returned to explain why. I
always try and do what is _better_ for the customer. Long term, that
is better for all. But not every company takes the long view.
>> P.S. �
>> I'm broadly competent in numerical methods, transcendental and float
>> implementations, and so on. �So, where for others it is daunting it
>> may be less so for me when implementing such custom routines. �As I
>> earlier pointed out, it took me a little over a day to start from zero
>> to fully test an ln() function written in assembly, which was a
>> central brick for the app. �Others would find that a longer process,
>> especially if unfamiliar. �Available skill sets help determine what's
>> a reasonable option and what isn't, as always.
>
>I,my company, makes motion controllers. These are feature rich motion
>controllers that can easily do the inverse kinematics for a 6DOF
>motion platform and communicate with many devices over Ethernet.
Great stuff. I have _never_ attempted inverse kinematics, but have
hoped to someday be given a chance at it. In some ways, I envy you
that.
>I've been doing this over 25 years. Functions that you find on a
>calculator are well documented. You know what you are up against and
>it isn't hard to find code for these functions. Then one compiles
>with a C compiler and then one hand optimizes the code by hand.
Yes. Though in the case I cited, I took a different implementation I
had made for an ADSP21xx processor (a completely different animal) and
used that as a template for coding up the new routine, while keeping
my frame of mind in the context of the '51 mindset.
>Kishor didn't make it clear what he is trying to do. Unless Kishor is
>doing something extremely simple he will spend more of his time than
>what he will save reinventing the wheel. He should buy a motion
>controller. I see this all the time.
hehe! May depend upon budget. Do hobbyists do 3 DC motors, or not?
;)
>Finally, has anybody done the math for a third order motion profile?
>The motion profile requires much more CPU time than the PID. This is
>why I recommend more CPU power and floating point. Surprises are
>waiting. Even a third order motion profile can be very demanding.
>Peter Nachtwey
This is an excellent point/question. I think I'll let things stand
there.
Jon
Reply by pnachtwey●December 6, 20092009-12-06
On Dec 5, 4:58=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> On Sat, 5 Dec 2009 16:39:07 -0800 (PST), pnachtwey
>
>
>
>
>
> <pnacht...@gmail.com> wrote:
> >On Dec 5, 10:34=A0am, Jon Kirwan <j...@infinitefactors.org> wrote:
> >> Can you talk about specifically why no SiLabs parts are adequate for
> >> controlling a DC motor? =A0You brought up the issue here of 'integer
> >> only', so I might assume that broad brush is why. =A0But it may not be
> >> your reason, which is why I'm asking. =A0I'm interested in your thinki=
ng
> >> here.
> >I am not picking on Silab parts. =A0I wouldn't even use most 32 bit
> >processors. =A0I know you can make software 32 or 48 bit accumulators
> >but it can't be done quickly either in programming time or execution
> >time. =A0The PID is such a small part of what a motion controller must
> >do. =A0What about the motion profile generator? =A0That is the hard part
> >if you need to process commands on-the-fly. =A0The calculations get to
> >be intensive. =A0A lot depends on your definition of control. =A0A PID
> >holding a motor at a position is very limited.
>
> >I say AMEN to Tim's statement about getting a microprocessor that has
> >10 times the estimated required processing power.
>
> >Peter Nachtwey
>
> Okay. =A0Thanks for taking a moment to clarify. =A0I agree with both of
> you about getting something grossly overpowered, as well. =A0If the
> application space permits, tools are appropriate, etc.
>
This brings up a another excellent point. Tools are very important.
The engineers time/cost needs to be weighed against extra costs of
available tools or the extra cost of using a CPU with floating point.
> My experience is in cost-sensitive environments, not feature-
> sensitive, with significant pressure on what can be afforded for cpu
> speed. =A0Such factors must be balanced _better_ than your competition
> to provide a wedge to improve odds at success. =A0And it is better still
> if you can 'do the impossible.' =A0:)
>
> Jon
Our products are feature rich. When doing industrial motion control
you want to have all the diagnostic/debug tools you can because
industrial applications are rarely high volume. When in the field you
want to get the job done and get back to the hotel, relax, and have a
beer instead of guessing and working 14 hours days. I have had a
customer call our product a 'get out of jail free card'.
>
> P.S. =A0
> I'm broadly competent in numerical methods, transcendental and float
> implementations, and so on. =A0So, where for others it is daunting it
> may be less so for me when implementing such custom routines. =A0As I
> earlier pointed out, it took me a little over a day to start from zero
> to fully test an ln() function written in assembly, which was a
> central brick for the app. =A0Others would find that a longer process,
> especially if unfamiliar. =A0Available skill sets help determine what's
> a reasonable option and what isn't, as always.
I,my company, makes motion controllers. These are feature rich motion
controllers that can easily do the inverse kinematics for a 6DOF
motion platform and communicate with many devices over Ethernet.
I've been doing this over 25 years. Functions that you find on a
calculator are well documented. You know what you are up against and
it isn't hard to find code for these functions. Then one compiles
with a C compiler and then one hand optimizes the code by hand.
Kishor didn't make it clear what he is trying to do. Unless Kishor is
doing something extremely simple he will spend more of his time than
what he will save reinventing the wheel. He should buy a motion
controller. I see this all the time.
Finally, has anybody done the math for a third order motion profile?
The motion profile requires much more CPU time than the PID. This is
why I recommend more CPU power and floating point. Surprises are
waiting. Even a third order motion profile can be very demanding.
Peter Nachtwey
Reply by Tim Wescott●December 6, 20092009-12-06
On Sat, 05 Dec 2009 16:39:07 -0800, pnachtwey wrote:
> On Dec 5, 10:34 am, Jon Kirwan <j...@infinitefactors.org> wrote:
>> Can you talk about specifically why no SiLabs parts are adequate for
>> controlling a DC motor? You brought up the issue here of 'integer
>> only', so I might assume that broad brush is why. But it may not be
>> your reason, which is why I'm asking. I'm interested in your thinking
>> here.
> I am not picking on Silab parts. I wouldn't even use most 32 bit
> processors. I know you can make software 32 or 48 bit accumulators but
> it can't be done quickly either in programming time or execution time.
> The PID is such a small part of what a motion controller must do. What
> about the motion profile generator? That is the hard part if you need
> to process commands on-the-fly. The calculations get to be intensive.
> A lot depends on your definition of control. A PID holding a motor at a
> position is very limited.
>
> I say AMEN to Tim's statement about getting a microprocessor that has 10
> times the estimated required processing power.
Do you actually generate a motion profile? For trapezoidal profiles I
use a controller that's inspired by sliding mode control but falls into
linear operation when velocity and/or position is close to target. So
there's none of this "I need to go from point A to point B, how do I get
there" stuff -- you just say "here's point B"; the thing's already going,
so it goes. It works _very_ well, and only requires a look-up table for
a square-rootish thing. In theory the computations are as bad as making
a velocity profile, but in practice you can do them once ahead of time
and fill in the blanks with the look-up table and interpolation.
I haven't tried it for profiles that limit jerk, but I suspect that it
could be extended just fine.
--
www.wescottdesign.com
Reply by Jon Kirwan●December 5, 20092009-12-05
On Sat, 5 Dec 2009 16:39:07 -0800 (PST), pnachtwey
<pnachtwey@gmail.com> wrote:
>On Dec 5, 10:34�am, Jon Kirwan <j...@infinitefactors.org> wrote:
>> Can you talk about specifically why no SiLabs parts are adequate for
>> controlling a DC motor? �You brought up the issue here of 'integer
>> only', so I might assume that broad brush is why. �But it may not be
>> your reason, which is why I'm asking. �I'm interested in your thinking
>> here.
>I am not picking on Silab parts. I wouldn't even use most 32 bit
>processors. I know you can make software 32 or 48 bit accumulators
>but it can't be done quickly either in programming time or execution
>time. The PID is such a small part of what a motion controller must
>do. What about the motion profile generator? That is the hard part
>if you need to process commands on-the-fly. The calculations get to
>be intensive. A lot depends on your definition of control. A PID
>holding a motor at a position is very limited.
>
>I say AMEN to Tim's statement about getting a microprocessor that has
>10 times the estimated required processing power.
>
>Peter Nachtwey
Okay. Thanks for taking a moment to clarify. I agree with both of
you about getting something grossly overpowered, as well. If the
application space permits, tools are appropriate, etc.
My experience is in cost-sensitive environments, not feature-
sensitive, with significant pressure on what can be afforded for cpu
speed. Such factors must be balanced _better_ than your competition
to provide a wedge to improve odds at success. And it is better still
if you can 'do the impossible.' :)
Jon
P.S.
I'm broadly competent in numerical methods, transcendental and float
implementations, and so on. So, where for others it is daunting it
may be less so for me when implementing such custom routines. As I
earlier pointed out, it took me a little over a day to start from zero
to fully test an ln() function written in assembly, which was a
central brick for the app. Others would find that a longer process,
especially if unfamiliar. Available skill sets help determine what's
a reasonable option and what isn't, as always.
Reply by pnachtwey●December 5, 20092009-12-05
On Dec 5, 10:34=A0am, Jon Kirwan <j...@infinitefactors.org> wrote:
> Can you talk about specifically why no SiLabs parts are adequate for
> controlling a DC motor? =A0You brought up the issue here of 'integer
> only', so I might assume that broad brush is why. =A0But it may not be
> your reason, which is why I'm asking. =A0I'm interested in your thinking
> here.
I am not picking on Silab parts. I wouldn't even use most 32 bit
processors. I know you can make software 32 or 48 bit accumulators
but it can't be done quickly either in programming time or execution
time. The PID is such a small part of what a motion controller must
do. What about the motion profile generator? That is the hard part
if you need to process commands on-the-fly. The calculations get to
be intensive. A lot depends on your definition of control. A PID
holding a motor at a position is very limited.
I say AMEN to Tim's statement about getting a microprocessor that has
10 times the estimated required processing power.
Peter Nachtwey
Reply by Jon Kirwan●December 5, 20092009-12-05
On Sat, 05 Dec 2009 11:57:30 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:
>On Sat, 05 Dec 2009 09:02:23 -0800, pnachtwey wrote:
>
>> On Dec 4, 9:37�pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>>> On Fri, 04 Dec 2009 17:21:11 -0600, Tim Wescott <t...@seemywebsite.com>
>>> wrote:
>>>
>>> >On Fri, 04 Dec 2009 03:56:15 -0800, kishor wrote:
>>>
>>> >> Hi friends,
>>> >> I am working on new pharmaceutical project in that I need to control
>>> >> the three DC motor at constant speed. I have worked in motion
>>> >> control project on Silab 8051 based processor.
>>>
>>> >> Please suggest me for,
>>> >> 1) good "PID" book, tutorials, example etc.. 2) micro-controller &
>>> >> motor driver ckt or dev / evl kit. (processor I prefer Silab 8051 or
>>> >> cortex-m3 )
>>>
>>> >The one by �str�m and Hagglund is supposed to be good.
>>>
>>> It is. �If you are talking about "PID Controllers: Theory, Design, and
>>> Tuning," 2nd ed., which I have here and have read and enjoyed.
>>>
>>> >For general
>>> >control theory in an embedded system you may be interested in mine;
>>> >see http://www.wescottdesign.com/actfes/actfes.html.
>>>
>>> >An 8051 isn't much processor for this sort of thing -- you'll probably
>>> >end up with the sampling rate limited by the chip, and the control
>>> >quality limited by the sampling rate. �You'd really rather be up
>>> >against the limits of performance of the plant, instead.
>>>
>>> The SiLabs 8051 may actually be the only family sporting a 16-bit 1MHz
>>> SAR ADC with DMA (necessary) controller to transfer to memory. �I'm
>>> using it, now. �Works fine, though their DMA docs leave something to be
>>> desired. �(I can fill in details.) �I require about 600kHz rate and am
>>> getting excellent results. �Processing power is pretty good, but I
>>> admit having written much in assembly just to make absolutely sure. The
>>> fast data rate is sparsely used for the two PID loops I'm running,
>>> which are in c. �But their rates are much slower, so it's no problem.
>>> And it's not motor control.
>>>
>>> >So I'd recommend that you look to that Cortex part instead...
>>>
>>> Perhaps. �But I wouldn't abruptly set aside the SiLabs parts, either.
>>> They perform pretty well. �(You know more about motor control apps than
>>> I do, though.)
>>>
>>> Jon
>> Everyone makes such a big deal about the PID routine when it is really a
>> minor part of any motion controller. It is possible to execute PIDs
>> very quickly but that alone isn't very useful. Running a PID with fast
>> updates introduces problems that can't be easily solved with integer
>> only CPUs. The reason for this is that the integrator coefficient are
>> often too small to fit in a 16 bit integer. Likewise the derivative
>> coefficients is often very big, so big that overflow becomes a problem.
>> In short, the faster you want to run the PID the greater the dynamic
>> range must be. This usually requires 32 bit math.
>>
>> I question the 600kHz rate on a 8051. We use SiLabs 8051s in some of our
>> products but not for motion control. We have made a SIMPLE 8051 PID
>> controller. It worked well but I wouldn't use one for controlling DC
>> motors.
>>
>> Peter Nachtwey
>
>I rarely get away with 16-bit math for motor control -- I've had some
>geared axes where the important thing was to reliably run into a stop
>'fast enough but not too fast'; for that I could get away with it. Just
>about everything else I do ends up using 32 bits.
>
>I suppose I was being a bit hasty rejecting the Scilabs part. The 'real'
>answer is to estimate the processing power you need for your application
>then evaluate the processors you like -- but often on a small production
>run the better answer is to get a Really Capable microprocessor that
>exceeds all your performance specifications by an order of magnitude --
>this lets you concentrate on the problem to be solved, instead of
>spending effort (hence engineering money) to shoehorn the solution into a
>place where it barely fits.
Good points. In my case, the cost of the SiLabs part was the same as
a 16-bit SAR ADC and cost and size is _very_ important. Trade-offs to
consider. What has surprised me here is that I had anticipated far
more 'shoehorn'ing than I've actually had to do. So getting the
application from zero (no code) to 100% of prototype target code was
one month's time. A lot better than I'd hoped. And the remaining
processor power is far more than I'd planned on. Which opens up some
interesting possibilities regarding 'features' I would have opposed,
prior to this experience.
The processor runs (in my case) at 25MHz. The instructions, roughly
speaking, require a clock count equal to their encoded byte count. A
custom-written (by me, over the span of about 1 day though testing
added some on the second day), 24-bit integer input (ADC accumulator
results), 32-bit FP output ln() takes 420 clocks (memory serving) to
execute (about 17 microseconds.) Output precision is monotonic to 21
bits... slightly less than the 23+1 that exists in the FP format. I
had expected much worse performance.
Jon
Reply by Jon Kirwan●December 5, 20092009-12-05
On Sat, 5 Dec 2009 09:02:23 -0800 (PST), pnachtwey
<pnachtwey@gmail.com> wrote:
>On Dec 4, 9:37�pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>> On Fri, 04 Dec 2009 17:21:11 -0600, Tim Wescott <t...@seemywebsite.com>
>> wrote:
>>
>> >On Fri, 04 Dec 2009 03:56:15 -0800, kishor wrote:
>>
>> >> Hi friends,
>> >> I am working on new pharmaceutical project in that I need to control the
>> >> three DC motor at constant speed. I have worked in motion control
>> >> project on Silab 8051 based processor.
>>
>> >> Please suggest me for,
>> >> 1) good "PID" book, tutorials, example etc.. 2) micro-controller & motor
>> >> driver ckt or dev / evl kit. (processor I prefer Silab 8051 or cortex-m3
>> >> )
>>
>> >The one by �str�m and Hagglund is supposed to be good.
>>
>> It is. �If you are talking about "PID Controllers: Theory, Design, and
>> Tuning," 2nd ed., which I have here and have read and enjoyed.
>>
>> >For general
>> >control theory in an embedded system you may be interested in mine; see
>> >http://www.wescottdesign.com/actfes/actfes.html.
>>
>> >An 8051 isn't much processor for this sort of thing -- you'll probably
>> >end up with the sampling rate limited by the chip, and the control
>> >quality limited by the sampling rate. �You'd really rather be up against
>> >the limits of performance of the plant, instead.
>>
>> The SiLabs 8051 may actually be the only family sporting a 16-bit 1MHz
>> SAR ADC with DMA (necessary) controller to transfer to memory. �I'm
>> using it, now. �Works fine, though their DMA docs leave something to
>> be desired. �(I can fill in details.) �I require about 600kHz rate and
>> am getting excellent results. �Processing power is pretty good, but I
>> admit having written much in assembly just to make absolutely sure.
>> The fast data rate is sparsely used for the two PID loops I'm running,
>> which are in c. �But their rates are much slower, so it's no problem.
>> And it's not motor control.
>>
>> >So I'd recommend that you look to that Cortex part instead...
>>
>> Perhaps. �But I wouldn't abruptly set aside the SiLabs parts, either.
>> They perform pretty well. �(You know more about motor control apps
>> than I do, though.)
>>
>> Jon
>Everyone makes such a big deal about the PID routine when it is really
>a minor part of any motion controller. It is possible to execute PIDs
>very quickly but that alone isn't very useful. Running a PID with
>fast updates introduces problems that can't be easily solved with
>integer only CPUs.
Many integer-only CPUs are quite capable of wide dynamic range
computations at fast update rates. For example, I use hand coded
24-bit and 48-bit accumulations on the 8051. You don't explicitly say
it, but floating point hardware (if that's your meaning) isn't the
dividing line here. It just makes it easier for some.
>The reason for this is that the integrator
>coefficient are often too small to fit in a 16 bit integer. Likewise
>the derivative coefficients is often very big, so big that overflow
>becomes a problem. In short, the faster you want to run the PID the
>greater the dynamic range must be. This usually requires 32 bit math.
>
>I question the 600kHz rate on a 8051.
That's not the PID rate, just the raw ADC operational rate. And the
results are excellent for the purpose intended. The two PIDs I have
are driven at the rate of 10Hz, which is nothing like 600kHz. I
explicitly said that before, along with the fact that they aren't used
for driving DC motors, and I sense you may have been confused when
reading my words. But maybe you mean something quite directed, here,
that I've missed in reading you.
>We use SiLabs 8051s in some of
>our products but not for motion control. We have made a SIMPLE 8051
>PID controller. It worked well but I wouldn't use one for controlling
>DC motors.
Can you talk about specifically why no SiLabs parts are adequate for
controlling a DC motor? You brought up the issue here of 'integer
only', so I might assume that broad brush is why. But it may not be
your reason, which is why I'm asking. I'm interested in your thinking
here.
Jon
Reply by Tim Wescott●December 5, 20092009-12-05
On Sat, 05 Dec 2009 09:02:23 -0800, pnachtwey wrote:
> On Dec 4, 9:37 pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>> On Fri, 04 Dec 2009 17:21:11 -0600, Tim Wescott <t...@seemywebsite.com>
>> wrote:
>>
>> >On Fri, 04 Dec 2009 03:56:15 -0800, kishor wrote:
>>
>> >> Hi friends,
>> >> I am working on new pharmaceutical project in that I need to control
>> >> the three DC motor at constant speed. I have worked in motion
>> >> control project on Silab 8051 based processor.
>>
>> >> Please suggest me for,
>> >> 1) good "PID" book, tutorials, example etc.. 2) micro-controller &
>> >> motor driver ckt or dev / evl kit. (processor I prefer Silab 8051 or
>> >> cortex-m3 )
>>
>> >The one by Åström and Hagglund is supposed to be good.
>>
>> It is. If you are talking about "PID Controllers: Theory, Design, and
>> Tuning," 2nd ed., which I have here and have read and enjoyed.
>>
>> >For general
>> >control theory in an embedded system you may be interested in mine;
>> >see http://www.wescottdesign.com/actfes/actfes.html.
>>
>> >An 8051 isn't much processor for this sort of thing -- you'll probably
>> >end up with the sampling rate limited by the chip, and the control
>> >quality limited by the sampling rate. You'd really rather be up
>> >against the limits of performance of the plant, instead.
>>
>> The SiLabs 8051 may actually be the only family sporting a 16-bit 1MHz
>> SAR ADC with DMA (necessary) controller to transfer to memory. I'm
>> using it, now. Works fine, though their DMA docs leave something to be
>> desired. (I can fill in details.) I require about 600kHz rate and am
>> getting excellent results. Processing power is pretty good, but I
>> admit having written much in assembly just to make absolutely sure. The
>> fast data rate is sparsely used for the two PID loops I'm running,
>> which are in c. But their rates are much slower, so it's no problem.
>> And it's not motor control.
>>
>> >So I'd recommend that you look to that Cortex part instead...
>>
>> Perhaps. But I wouldn't abruptly set aside the SiLabs parts, either.
>> They perform pretty well. (You know more about motor control apps than
>> I do, though.)
>>
>> Jon
> Everyone makes such a big deal about the PID routine when it is really a
> minor part of any motion controller. It is possible to execute PIDs
> very quickly but that alone isn't very useful. Running a PID with fast
> updates introduces problems that can't be easily solved with integer
> only CPUs. The reason for this is that the integrator coefficient are
> often too small to fit in a 16 bit integer. Likewise the derivative
> coefficients is often very big, so big that overflow becomes a problem.
> In short, the faster you want to run the PID the greater the dynamic
> range must be. This usually requires 32 bit math.
>
> I question the 600kHz rate on a 8051. We use SiLabs 8051s in some of our
> products but not for motion control. We have made a SIMPLE 8051 PID
> controller. It worked well but I wouldn't use one for controlling DC
> motors.
>
> Peter Nachtwey
I rarely get away with 16-bit math for motor control -- I've had some
geared axes where the important thing was to reliably run into a stop
'fast enough but not too fast'; for that I could get away with it. Just
about everything else I do ends up using 32 bits.
I suppose I was being a bit hasty rejecting the Scilabs part. The 'real'
answer is to estimate the processing power you need for your application
then evaluate the processors you like -- but often on a small production
run the better answer is to get a Really Capable microprocessor that
exceeds all your performance specifications by an order of magnitude --
this lets you concentrate on the problem to be solved, instead of
spending effort (hence engineering money) to shoehorn the solution into a
place where it barely fits.
--
www.wescottdesign.com
Reply by pnachtwey●December 5, 20092009-12-05
On Dec 4, 9:37=A0pm, Jon Kirwan <j...@infinitefactors.org> wrote:
> On Fri, 04 Dec 2009 17:21:11 -0600, Tim Wescott <t...@seemywebsite.com>
> wrote:
>
> >On Fri, 04 Dec 2009 03:56:15 -0800, kishor wrote:
>
> >> Hi friends,
> >> I am working on new pharmaceutical project in that I need to control t=
he
> >> three DC motor at constant speed. I have worked in motion control
> >> project on Silab 8051 based processor.
>
> >> Please suggest me for,
> >> 1) good "PID" book, tutorials, example etc.. 2) micro-controller & mot=
or
> >> driver ckt or dev / evl kit. (processor I prefer Silab 8051 or cortex-=
m3
> >> )
>
> >The one by =C5str=F6m and Hagglund is supposed to be good.
>
> It is. =A0If you are talking about "PID Controllers: Theory, Design, and
> Tuning," 2nd ed., which I have here and have read and enjoyed.
>
> >For general
> >control theory in an embedded system you may be interested in mine; see
> >http://www.wescottdesign.com/actfes/actfes.html.
>
> >An 8051 isn't much processor for this sort of thing -- you'll probably
> >end up with the sampling rate limited by the chip, and the control
> >quality limited by the sampling rate. =A0You'd really rather be up again=
st
> >the limits of performance of the plant, instead.
>
> The SiLabs 8051 may actually be the only family sporting a 16-bit 1MHz
> SAR ADC with DMA (necessary) controller to transfer to memory. =A0I'm
> using it, now. =A0Works fine, though their DMA docs leave something to
> be desired. =A0(I can fill in details.) =A0I require about 600kHz rate an=
d
> am getting excellent results. =A0Processing power is pretty good, but I
> admit having written much in assembly just to make absolutely sure.
> The fast data rate is sparsely used for the two PID loops I'm running,
> which are in c. =A0But their rates are much slower, so it's no problem.
> And it's not motor control.
>
> >So I'd recommend that you look to that Cortex part instead...
>
> Perhaps. =A0But I wouldn't abruptly set aside the SiLabs parts, either.
> They perform pretty well. =A0(You know more about motor control apps
> than I do, though.)
>
> Jon
Everyone makes such a big deal about the PID routine when it is really
a minor part of any motion controller. It is possible to execute PIDs
very quickly but that alone isn't very useful. Running a PID with
fast updates introduces problems that can't be easily solved with
integer only CPUs. The reason for this is that the integrator
coefficient are often too small to fit in a 16 bit integer. Likewise
the derivative coefficients is often very big, so big that overflow
becomes a problem. In short, the faster you want to run the PID the
greater the dynamic range must be. This usually requires 32 bit math.
I question the 600kHz rate on a 8051. We use SiLabs 8051s in some of
our products but not for motion control. We have made a SIMPLE 8051
PID controller. It worked well but I wouldn't use one for controlling
DC motors.
Peter Nachtwey
Reply by Jon Kirwan●December 5, 20092009-12-05
On Fri, 04 Dec 2009 17:21:11 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:
>On Fri, 04 Dec 2009 03:56:15 -0800, kishor wrote:
>
>> Hi friends,
>> I am working on new pharmaceutical project in that I need to control the
>> three DC motor at constant speed. I have worked in motion control
>> project on Silab 8051 based processor.
>>
>> Please suggest me for,
>> 1) good "PID" book, tutorials, example etc.. 2) micro-controller & motor
>> driver ckt or dev / evl kit. (processor I prefer Silab 8051 or cortex-m3
>> )
>>
>The one by �str�m and Hagglund is supposed to be good.
It is. If you are talking about "PID Controllers: Theory, Design, and
Tuning," 2nd ed., which I have here and have read and enjoyed.
>For general
>control theory in an embedded system you may be interested in mine; see
>http://www.wescottdesign.com/actfes/actfes.html.
>
>An 8051 isn't much processor for this sort of thing -- you'll probably
>end up with the sampling rate limited by the chip, and the control
>quality limited by the sampling rate. You'd really rather be up against
>the limits of performance of the plant, instead.
The SiLabs 8051 may actually be the only family sporting a 16-bit 1MHz
SAR ADC with DMA (necessary) controller to transfer to memory. I'm
using it, now. Works fine, though their DMA docs leave something to
be desired. (I can fill in details.) I require about 600kHz rate and
am getting excellent results. Processing power is pretty good, but I
admit having written much in assembly just to make absolutely sure.
The fast data rate is sparsely used for the two PID loops I'm running,
which are in c. But their rates are much slower, so it's no problem.
And it's not motor control.
>So I'd recommend that you look to that Cortex part instead...
Perhaps. But I wouldn't abruptly set aside the SiLabs parts, either.
They perform pretty well. (You know more about motor control apps
than I do, though.)
Jon