need suggestion for PID in DC motor controlling

On Sat, 05 Dec 2009 16:39:07 -0800, pnachtwey wrote:

> On Dec 5, 10:34&nbsp;am, Jon Kirwan <j...@infinitefactors.org> wrote:
>> Can you talk about specifically why no SiLabs parts are adequate for
>> controlling a DC motor? &nbsp;You brought up the issue here of 'integer
>> only', so I might assume that broad brush is why. &nbsp;But it may not be
>> your reason, which is why I'm asking. &nbsp;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

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

On Sat, 5 Dec 2009 22:12:06 -0800 (PST), pnachtwey
<pnachtwey@gmail.com> wrote:

>On Dec 5, 4:58&#4294967295;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&#4294967295;am, Jon Kirwan <j...@infinitefactors.org> wrote:
>> >> Can you talk about specifically why no SiLabs parts are adequate for
>> >> controlling a DC motor? &#4294967295;You brought up the issue here of 'integer
>> >> only', so I might assume that broad brush is why. &#4294967295;But it may not be
>> >> your reason, which is why I'm asking. &#4294967295;I'm interested in your thinking
>> >> here.
>> >I am not picking on Silab parts. &#4294967295;I wouldn't even use most 32 bit
>> >processors. &#4294967295;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. &#4294967295;The PID is such a small part of what a motion controller must
>> >do. &#4294967295;What about the motion profile generator? &#4294967295;That is the hard part
>> >if you need to process commands on-the-fly. &#4294967295;The calculations get to
>> >be intensive. &#4294967295;A lot depends on your definition of control. &#4294967295;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. &#4294967295;Thanks for taking a moment to clarify. &#4294967295;I agree with both of
>> you about getting something grossly overpowered, as well. &#4294967295;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. &#4294967295;Such factors must be balanced _better_ than your competition
>> to provide a wedge to improve odds at success. &#4294967295;And it is better still
>> if you can 'do the impossible.' &#4294967295;:)
>>
>> 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. &#4294967295;
>> I'm broadly competent in numerical methods, transcendental and float
>> implementations, and so on. &#4294967295;So, where for others it is daunting it
>> may be less so for me when implementing such custom routines. &#4294967295;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. &#4294967295;Others would find that a longer process,
>> especially if unfamiliar. &#4294967295;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