What "P", "D" and "I" are depends on what you measure. Do you have a position sensor or a velocity sensor or for that matter a temperature sensor?
A quadrature encoders can be used as either a position or as a velocity sensor for velocity sensing you need to combine it with a clock or counter. "P" is always the error signal. That is the difference between what you want and what you got P's using can be either error in position, error in velocity or error in temperature, or heading (if reading a compass) It depends on the sensor. D is the rate of change in P over the period of one control cycle, I is the sum of all past P. So the first question is "What are you measuring?" If using quadrature sensor the simples way to use it by just counting, this measures position. So P is the error is position. If using the encoders as a velocity sensor then P is the error in velocity. The sensor is just a spinning disk and if it measures position of velocity depends on what you software does when a pulse comes. If your software costs it is measuring position if your software samples a clock if is measuring velocity. A really common way is to do to conversion from position to velocity inside the PID loop while commuting P. The loop first subtracts the current position from the previous position and assumes a constant loop period and then has velocity in units of "position counts per loop period" (which is position over time) It then compares this with the set point which is kept in units of courts per period and then you have P. There are lots of ways to do this but a common error is mixing up units. It is a lilt confusing becait "counts" is position" but "counts per period" is velocity and surprisingly we can convert position to velocity with a subtraction. It is easy to miss that. So two easy errors (1) you've crossed up your units or (2) quantization error from the sensor (not enough encoder ticks per period) You fix #1 by being careful and #2 by either making the period much longer (like 100X longer) or buying a better encoder or using the ticks to sample a high resolution clock. (but if you do this, now you are directly measuring speed so see #1 above) On Tue, Oct 31, 2017 at 7:59 AM, Gene Heskett <[email protected]> wrote: > On Tuesday 31 October 2017 06:21:35 andy pugh wrote: > > > On 31 October 2017 at 01:22, Chris Albertson > <[email protected]> wrote: > > > I think the difference between position and velocity is how the > > > error signal is computed. After you have that. I don't think a > > > PID algorithm cares if it is controlling temperature, heading, > > > airspeed or position. Originally the algorithm was invented for > > > steering ships at sea on a constant heading. > > > > It makes a big difference. > > > > PID is basically three different orders of differentiation of the > > error signal with respect to time. > > We have the first order differential (D), the zeroth order > > differential (P) and the -1th order (Integral, I). > > > > The output of the PID controller affects the process variable on a > > similar spectrum. For example a torque-mode position controller is > > actually controlling the _second_ order derivative of the process > > variable. > > > > So, a Torque mode drive will tend to use a fair bit of D. A velocity > > mode drive will tend to mainly use P. A position-mode drive with > > feedback would tend to mainly use I. > > > > The velocity-mode servo controlling to velocity is close to the > > position-position mode above, and will be mainly I (and FF0). > > > Would it not also used some Dgain to speedup the response to a directed > reversal? I can't experiment ATM, I've no spindle power, I think I've a > bad bob. I can see the signals on the halscope at the gpio outputs, but > its not getting thru the bob to pump the spindle power soft start. > > This is using a charge pump to enable that, first 5 seconds it has a 51 > ohm 200 watt R in series with the toroids, then 5 seconds later bypasses > the resistor after the caps have had time to get charged. > > I just woke up, so still a quart low on coffee, after I get the missus > fed etc, I'll go scope the end of the cable to see if its getting that > far. I've had trouble with these IDC connectors before, the 25 pinners > in particular, the center area is NOT well clamped and can open up. > Cable I have, probably 70 feet yet on a spool, but I may have to order > another big bag of connectors. These projects tend to use them all up. > Amphenol's blue plastic with tin surrounds for 25 pin dsubs. Is there a > better connector than Amphenol? Something with a thicker backstrap so > its clamped better in the middle? This is pin 8 and 9, almost smack in > the middle and can easily work back from contact. > > > Look at this another way, consider a velocity-mode drive controlling > > spindle speed with only a P-term. The PID output is > > P x (commanded_speed - measured_speed). If the spindle is exactly at > > the setpoint the output of such a P-only controller is zero. ie, a > > zero-velocity request > > Such a system will _always_ stabilise at a level below the setpoint > > that is a simple factor of the P-gain. > > Yes. With FF0 at or near 1.0, so there is a 1/1 transfer, then modified > by P. Keeping in mind that gains after that point must assure that the > PDM never saturates in order to keep Jon's servo pumping correctly. I've > a .98 limit of SPINDLE_9_SCALE set for that so it tracks. > > > In such a system the P-term is > > the equivalent of the D-term in a velocity-position loop. > > So Dgain itself would be miss-used in a velocity<->velocity loop. Okay... > > And by what Chris says, the spindle stuff should be running in a slower > thread just to get more edges into the system at slower spindle speeds. > > Now that I've some experience with slower threads on the pi, putting the > spindle stuff in a 100hz thread wouldn't be that difficult, it works > really well on the sheldon, never ever missing a click of a dial unless > timed out. I zero the dials when its timed out. > > So using 2 pid's and switching back and forth between them depending on > head gear, the major diff in the two pid setups would be a higher FF0 in > the back gear case in order to spin the motor faster in low gear. This > is something I need to incorporate into TLM also. I have something > cobbled up in the pyvcp panel, but its not based on this. > > Explanations like this belong in our wiki. Too much is implied in the > math, but its calculus loses me, needs more practical examples, putting > each "mode" in its own category. > > Cheers, Gene Heskett > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
