On Thu, 2013-06-27 at 11:13 -0400, Dave wrote: > I do a fair amount of industrial PID related software work. > > The output of a digital Temp control PID is usually a 0-100% "signal". > Then that signal is used to vary the heat input to whatever you are > trying to control. > For instance, with band and cartridge heaters, the duty cycle of a Solid > State relay that controls the heater element is controlled is altered to > control the heat input. > > >>Does pushing gain around between the PID component and the output > driver change how easy/hard it is to tune the PID loop?<< > > In a way it can. Depending on what you consider to be "gain". If the > heater element has a very large output (gain) compared to the > steady state heat requirements, then the loop will be very difficult to > control as very little output will result in large Process Value (PV) changes. > > Your PID loop is likely running a lot faster than what is required. The PID > loop should run 10x to 50x the time constant of the control system. Any > faster and you will end up with very small changes in tuning values that make > a huge difference in loop performance and the loop will be difficult to tune. > > http://en.wikipedia.org/wiki/Time_constant -- this is more info than you > need.. > > Chances are that if you run your PID loop at 10hz or so (maybe slower > depending on the time constant) you will be fine ( a guess ). > > I have never used a LinuxCNC PID loop for a heating application, but they may > not be suitable. Certainly a bipolar output is not needed unless you have an > integral cooling system built into your temp control system. ;-) > > It would not be difficult to find some temp PID code and put it into a custom > component. > > You definitely want Integral windup limiting so the integral term is frozen > when the output hits 100% or 0% and you probably also want Integral gain > limiting as well such that the > integral term can only contribute X percentage to the output value. You also > need decent filtering on your Process value otherwise you will drive a fast > loop crazy with noise. > > Here is a reference that looks useful. There is some code at the end that > boils the BS down to a reasonable level. > > http://www.cds.caltech.edu/~murray/courses/cds101/fa02/caltech/astrom-ch6.pdf > > Dave Cole > Indeed, their is a lot of information in that link. Control might be easier if you reduce the heater gain so you get to use the whole span of your dac. Since you have plenty time available, do some filtering, even if it is just summing the input for one update period and scaling. 2nd order butterworth would be nice. If you have significant input noise then, usually 60 Hz then IIRC sampling always at the same place in the cycle at least give you a given offset. I've also seen asynchronous sampling done; 93 Hz was used on a micro-voltmeter. This sounds like an interesting project and I hope it works just the way you want it to. :-)
Dave > > > > On 6/27/2013 9:56 AM, Charles Steinkuehler 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 ------------------------------------------------------------------------------ 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
