On 4/14/2016 9:57 PM, rickman wrote:> On 4/14/2016 9:50 PM, rickman wrote: >> On 4/14/2016 7:41 PM, Tim Wescott wrote: >>> On Thu, 14 Apr 2016 19:11:38 -0400, rickman wrote: >>> >>>> Page 4, equation 1, you might explain the basis of this equation. I >>>> assume the voltage actually controls the torque. Friction force is a >>>> result of velocity and the acceleration is from the excess force until >>>> the motor speeds up. Contrasted to the equation for the frictionless >>>> platform. >>> >>> Hmm. I'm trying to keep the math stuff short -- people write entire >>> white papers on the behavior of motors alone. Maybe put all the math >>> into a several-page appendix? >> >> I don't think tucking away the math into an appendix is the answer. >> Maybe derivations or something not essential to understanding the >> problem. All I would need is an understanding of the meaning of the >> terms of the equation. Typically each term of the equation comes from >> some specific "thing" in the problem. I don't get what those "things" >> are in these equations. >> >> >>> To unpack a bit, the difference between the applied voltage and the >>> motor's back-emf, divided by the armature resistance, determine the >>> motor's armature current. Torque is armature current times the motor's >>> torque constant, and acceleration is torque divided by the motor's >>> moment >>> of inertia. All of that is rolled into the kv and the time constant, in >>> this case. >> >> I'm not sure I understand this. I'd need to write out the equations. >> The back-emf is proportional to what, the rate of change of the current? >> Or the speed of the motor? It's been a long time and I forget. I >> think saying it "is rolled into the kv and the time constant" is a bit >> simplified. Again, I'd like to know the meaning of each term in the >> equation. d theta/dt is the speed of the motor, but why is that in this >> spot of the equation? Does this represent the friction? Then I would >> get that the friction force balances with the motor torque and the >> acceleration would become zero. >> >> >>>> Page 8, equation 3, you define Th twice but don't say what units. I >>>> assume it needs to be absolute temperature, Kelvin? Two time constants >>>> are given, but no explanation for why two or what is different about >>>> them. I don't know about others, but I have a hard time considering an >>>> equation I don't understand. It keeps me from getting an understanding >>>> of how the controller would work. >>> >>> Well, I pulled the time constants out of my ear. Or my donkey (I _do >>> not_ get that cliche :P ). Or something. >> >> Then where did this equation come from? I find it very hard to follow >> the rest of the approach if I can't understand the equation. I guess >> I'm not the target audience. >> >> >>> Te temperature of the load (Th) is determined by both the driving input >>> (Vd) and the ambient temperature (Ta). Again, I need to think about >>> making that more clear without making the math-averse reader run away >>> screaming. >> >> Seems to me the equation would be >> >> dTh/dt = ka * (Ta - Th) + kh * Vd >> >> kh * Vd is the heat applied by the heater with kh the constant for the >> heater watts vs the thermal mass of the container. ka * (Ta -Th) is the >> heat entering (or leaving) the container with ka accounting for the >> thermal mass and the amount of surface area, etc. The heat moving >> into/out of the container is proportional to the temperature rate of >> change, no? > > I just spotted an error. If the heater is controlled by volts, it would > have to be voltage squared to get power. Unless the volts is out of the > ADC and the heater is controlled by a voltage to watts control, lol.Need to give this up tonight... make that DAC, not ADC. -- Rick
PID Without a PhD, Finally
Started by ●April 14, 2016
Reply by ●April 14, 20162016-04-14
Reply by ●April 15, 20162016-04-15
On Thu, 14 Apr 2016 20:10:23 -0500, quiasmox wrote:> On Thu, 14 Apr 2016 17:03:53 -0500, Tim Wescott > <seemywebsite@myfooter.really> wrote: > >>Embedded Systems Design (or whatever they call themselves) kept moving >>this around -- so I've revamped it, updated it, and posted it on the >>web. >> >>Take a gander. Please comment on anything you like/don't like. I'm not >>sure if the way that I'm setting off the math is a Really Good Idea or a >>Really Bad Idea -- I'm trying to make it easy for the math-averse to >>skip over it, without breaking up the flow too much for folks who can >>read math without breaking stride. >> >>http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf > > The boxed equations don't have any equals signs. I imagine that's stuff > that's understood, but maybe not for everyone.Do too. I've gotten this report before, and I think it's something about the way that LaTeX renders pdf files, and then the way that Adobe renders those pdf files on some screens. I would really appreciate it if you could email me a screen shot so that I can file a bug report with the LaTeX folks, or ask for a work-around. tim AT wescottdesign DOT com. Thanks in advance. -- www.wescottdesign.com
Reply by ●April 15, 20162016-04-15
On Thu, 14 Apr 2016 23:06:27 -0500, Tim Wescott <tim@seemywebsite.com> wrote:>On Thu, 14 Apr 2016 20:10:23 -0500, quiasmox wrote: > >> On Thu, 14 Apr 2016 17:03:53 -0500, Tim Wescott{message trimmed}>>>http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf >> >> The boxed equations don't have any equals signs. I imagine that's stuff >> that's understood, but maybe not for everyone. > >Do too. > >I've gotten this report before, and I think it's something about the way >that LaTeX renders pdf files, and then the way that Adobe renders those >pdf files on some screens. I would really appreciate it if you could >email me a screen shot so that I can file a bug report with the LaTeX >folks, or ask for a work-around. > >tim AT wescottdesign DOT com. > >Thanks in advance.Ok, I downloaded the file instead of looking at it in the browser, and the equals signs are fine. I've sent you an email with the screenshots from within the browser. -- John
Reply by ●April 15, 20162016-04-15
On 14 Apr 2016, DJ Delorie wrote (in article <xnr3e7lrdl.fsf@delorie.com>):> I'm reminded of a YouTube video about how NOT to weldCan you remember the guy--and find the link to that video series?
Reply by ●April 15, 20162016-04-15
Tim Wescott <seemywebsite@myfooter.really> wrote:> On Fri, 15 Apr 2016 03:37:58 +1000, Clifford Heath wrote: > >> On 15/04/16 08:03, Tim Wescott wrote: >>> Embedded Systems Design (or whatever they call themselves) kept moving >>> this around -- so I've revamped it, updated it, and posted it on the >>> web. >>> >>> Take a gander. Please comment on anything you like/don't like. I'm >>> not sure if the way that I'm setting off the math is a Really Good Idea >>> or a Really Bad Idea -- I'm trying to make it easy for the math-averse >>> to skip over it, without breaking up the flow too much for folks who >>> can read math without breaking stride. >>> >>> http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf >> >> Thanks - passed on to folk who might benefit. >> >> One thing - in the text for Figure 5, you say "magnet is attached to the >> stage, which moves with an acceleration proportional to the coil >> current." >> >> I've done exactly this with a large voice coil (4" diameter, 4" throw) >> with a constant *voltage*, and you get a *speed* proportional to the >> voltage, although the current quickly settles to a constant (-ish). I'm >> sure I don't need to explain why - but it might be worth mentioning back >> EMF at some point. It was a surprise to me, initially. >> >> Clifford Heath. > > I think maybe I should write a white paper on how motors work. The > principle of voice-coil motor behavior is pretty much the same as motors > that turn in circles.Thanks Tim. That last sentence rang a bell in my head and turned on a light. I guess I officially "learned something" today.
Reply by ●April 15, 20162016-04-15
On 15/04/16 00:03, Tim Wescott wrote:> Embedded Systems Design (or whatever they call themselves) kept moving > this around -- so I've revamped it, updated it, and posted it on the web. > > Take a gander. Please comment on anything you like/don't like. I'm not > sure if the way that I'm setting off the math is a Really Good Idea or a > Really Bad Idea -- I'm trying to make it easy for the math-averse to skip > over it, without breaking up the flow too much for folks who can read > math without breaking stride. > > http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf >A very nice work. I seem to remember that you already had a previous version of it, didn't you? It was a surprise to see that the D box input (and pehaps P) is taken from the feedback and not the error signal, as os usual in most textbooks. For constant or slow varying commands, it makes no difference. Is this arrangement an empirical result? Pere
Reply by ●April 15, 20162016-04-15
On 15.4.16 02:11, rickman wrote:> > Page 4, equation 1, you might explain the basis of this equation. I > assume the voltage actually controls the torque. Friction force is a > result of velocity and the acceleration is from the excess force until > the motor speeds up. Contrasted to the equation for the frictionless > platform.Rick: Every motor is also a generator. For a motor with constant magnetization, the back EMF is proportional to the speed and the motor torque is proportional to the current. You can model such a motor with a series connection of the supply voltage, the motor (and line) resistance and the back EMF. The motor settles to a speed near such speed that the difference between supply voltage and back EMF runs just enough current in the circuit to compensate for torque needed to keep the speed. If you feed a constant-magnetized motor with a constant current supply, the torque stays constant until the compliance limit of the feed supply. -- -TV
Reply by ●April 15, 20162016-04-15
On page 14 in the code, it should be pid->iState instead of iState right? On 2016-04-14 15:03, Tim Wescott wrote:> Embedded Systems Design (or whatever they call themselves) kept moving > this around -- so I've revamped it, updated it, and posted it on the web. > > Take a gander. Please comment on anything you like/don't like. I'm not > sure if the way that I'm setting off the math is a Really Good Idea or a > Really Bad Idea -- I'm trying to make it easy for the math-averse to skip > over it, without breaking up the flow too much for folks who can read > math without breaking stride. > > http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdf >
Reply by ●April 15, 20162016-04-15
In article <wpydnbi9wr9Ujo3KnZ2dnUU7-WXNnZ2d@giganews.com>, seemywebsite@myfooter.really says...> > Embedded Systems Design (or whatever they call themselves) kept moving > this around -- so I've revamped it, updated it, and posted it on the web. > > Take a gander. Please comment on anything you like/don't like. I'm not > sure if the way that I'm setting off the math is a Really Good Idea or a > Really Bad Idea -- I'm trying to make it easy for the math-averse to skip > over it, without breaking up the flow too much for folks who can read > math without breaking stride. > > http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdfWell in general good other comments people have stated I would add these points - 1/ Code layout on page 14 of the integral state is UGLY, belongs in obfuscated C better laid out out that is easier to read at a glance is better for those trying to understand. 2/ Sampling time and loop delay, the closed loop problem that many people overlook is not mentioned in any manner until into the maths. Most people forget that digital control systems have a time lag and time between calculations, sampling and worst of all ALL systems have a delay between command -> error -> drive -> feedback Each part has its own intrinsic delays/inertia and other effects that most people never MEASURE. Increasing sampling rate or precision does NOT guarantee being able to get to target faster. A classic problem I saw was a remotely operated vehicle, with a video link and command back to vehicle. Everybody was annoyed that it could not be driven faster than 30 mph so were looking at using 3D cameras to make it faster. No one had obviously measured delays in system Camera frame integration time Camera frame transmission time Camera frame acquisition time frame compression encryption time frame radio link transmission time frame receive time (missed/corrupt data) frame decryption time frame network transfer time (multi-computer setup) Frame ROTATION by 90 degrees time Frame mixing with other graphics Frame buffer switching Then Operator response time Controls delay to data time Controls network transfer Controls radio link transmission Controls receive time (what about missed/corrupt data) Controls entered as new commands into drive control loops Controls being applied Vehicle lag to changes in drive So how was 2 video feeds going to speed this up 3/ Limits (especially integrator) Limits, limits, limits how often overlooked and bear NO relation to reality. Examples If you have a motor with NO direction control, under what circumstances do you need a NEGATIVE limit ? If you have a maximum drive (output level) under what circumstances do you need a larger limit ? Real world as in your heater example if you measure ambient unless you have some cooling system your minimum IS AMBIENT. Light drives can you really have negative light without use of mirrors or other light sources. Ambient light or black is your minimum. Case I saw was some control software 30 years ago where a PI example program had Oven Heater constant heat drive Door that could be open or closed 2 temperature readings Oven Ambient If you left the door closed the integrator would easily reach 50,000 degrees C If you opened the door it would 'cool' to -500 degrees C and beyond Just some random ramblings from a nutter to bear in mind -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.badweb.org.uk/> For those web sites you hate
Reply by ●April 15, 20162016-04-15
In article <wpydnbi9wr9Ujo3KnZ2dnUU7-WXNnZ2d@giganews.com>, seemywebsite@myfooter.really says...> > Embedded Systems Design (or whatever they call themselves) kept moving > this around -- so I've revamped it, updated it, and posted it on the web. > > Take a gander. Please comment on anything you like/don't like. I'm not > sure if the way that I'm setting off the math is a Really Good Idea or a > Really Bad Idea -- I'm trying to make it easy for the math-averse to skip > over it, without breaking up the flow too much for folks who can read > math without breaking stride. > > http://wescottdesign.com/articles/pid/pidWithoutAPhd.pdfOOps just spotted a terminology blunder Page 2 The "PID" in "PID Control" stands for "Proportional, Integral, Derivative". Page 19 Section Title is "Differential" Should be "Derivative" From there on you interchange differential and derivavtive all over the place. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.badweb.org.uk/> For those web sites you hate
