need suggestion for PID in DC motor controlling

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 )

Thanks in advance, Kishore.

Reply to
kishor
Loading thread data ...

formatting link
Look around the CTM PID website because there is more info. You will be pushing your 8051 to the limits. I would look at a TI starter kit. I recently bought one for $400 that included a TI Piccolo DSP and two small motors. It has Code Composer and source code so it will run out of the box. The TI kit is using PWM outputs.

Peter Nachtwey

Reply to
pnachtwey

The one by Åström and Hagglund is supposed to be good. For general control theory in an embedded system you may be interested in mine; see

formatting link

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.

So I'd recommend that you look to that Cortex part instead...

--
www.wescottdesign.com
Reply to
Tim Wescott

It is. If you are talking about "PID Controllers: Theory, Design, and Tuning," 2nd ed., which I have here and have read and enjoyed.

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.

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

Reply to
Jon Kirwan

he

or

m3

st

d

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 to
pnachtwey

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 to
Tim Wescott

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.

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.

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 to
Jon Kirwan

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 to
Jon Kirwan

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 to
pnachtwey

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 to
Jon Kirwan

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 to
Tim Wescott

ng

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.

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'.

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 to
pnachtwey

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.

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.

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.

hehe! May depend upon budget. Do hobbyists do 3 DC motors, or not? ;)

This is an excellent point/question. I think I'll let things stand there.

Jon

Reply to
Jon Kirwan

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.