The scaling is in the units of the input and output. You don't need to scale the output 100x as you could just use 100x smaller PID values.
Integral gain should be in the form of output per second given one unit of input (though I don't know if LCNC normalizes the summing rate or you have to divide by the 1kHz loop rate.) So if your temperature readings are in degC, then a 1 C error with a gain of 1, will give you an additional 1 unit of output PER SECOND. Thermal time constants are typically quite slow. So, say you have a 10C error that you'd like to correct in 30s by adding 20% additional output. So your I gain would be 0.2/30s/10C= 0.00066 s^-1 C^-1 (though output scaling 0-1 is unitless so it doesn't contribute.) If LCNC doesn't normalize the loop rate, you need to divide by an additional 1000. Are you trying I gains that small? See, it depends on the input/output scaling and time constants. Some sytems end up w/ HUGE gains, others can be TINY. Just depends on the controlled system and any scalings it might have. Stephen On Thu, Jun 27, 2013 at 9:56 AM, Charles Steinkuehler < [email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am having some issues tuning the PID loop for temperature control on > my LinuxCNC controlled 3D printer, so I thought I'd ask about some > best practices for PID setup. > > QUESTION: > How are gains typically arranged in a PID control loop? Is the PID > output generally scaled to represent something real (like the 0-300 > degree range of my temperature readings), something arbitrary (like > +/- 100 or 1000), or just left at whatever random value seemed like a > good idea when the HAL file was first created? > > Does pushing gain around between the PID component and the output > driver change how easy/hard it is to tune the PID loop? > > BACKGROUND: > I have a temperature reading updated 20 times a second by user code > feeding into a standard HAL PID component that runs at the default 1 > mS rate. > > Driving the heater is a PWM output that is generated by my PRU code, > but mimics the behavior of the hm2 pwmgen (including generating output > for negative input values, which IMHO is just wrong, but I know why it > was done that way). > > Anyway, the PWM output has it's default scale, so 0.0 to 1.0 is no > output to full scale. I have a limit component between the PID and > the PWM to clip the negative PID output values, and a bias setting of > 0.5 on the PID. > > ...but this is turning out to be very hard to tune. I get good > results playing with P gain and adding in some D, but if I ever try > adding any I term it just goes crazy and oscillates (or just runs > away). I think my basic issue is integrator wind-up, and given my > very small 0.0-1.0 output range the integrator term can easily swamp > the output even with very small gains. By way of example, as my HAL > file stands now, a P gain setting of 0.5 is approximately my critical > gain, and P=0.3, D=0.93, I=0 was a pretty stable control loop. > > So I'm looking at clipping the I term with maxerrorI, but I am also > wondering about the overall gain setup. I have scale available on the > PWM, and obviously all the gain settings to play with on the PID > component, I'm just wondering if there's a somewhat standard way to > dial some of the knobs. > > Thanks! > > - -- > Charles Steinkuehler > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHMRJEACgkQLywbqEHdNFyrHgCgsyuk4DSU6LvRNFl3MjvrOzVr > 7sIAoKIqOrqqPdZzUXp0W2uy4jmHPc9A > =KzET > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
