Home |
Search |
Today's Posts |
|
Metalworking (rec.crafts.metalworking) Discuss various aspects of working with metal, such as machining, welding, metal joining, screwing, casting, hardening/tempering, blacksmithing/forging, spinning and hammer work, sheet metal work. |
Reply |
|
LinkBack | Thread Tools | Display Modes |
#1
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN |
#2
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On 23-Sep-14 10:23 AM, RogerN wrote:
I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN You need to ping Tim Wescott who sometimes posts here - he's the guru. |
#3
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 13:41:18 +0800, Stoob wrote:
On 23-Sep-14 10:23 AM, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN You need to ping Tim Wescott who sometimes posts here - he's the guru. Derivative is concerned with the error's rate of change, which given a time base your calculation does. Its primary use is to reduce overshoot in systems with a lot of lag, like an oven temperature control. It's also the last thing to fool with if you're tuning the controller. For any fast acting loop, like flow or mass control, turn that damned derivative off. And if you see an oven approach setpoint then dip before it gets there, then oscillate gradually toward setpoint, cut it in half. As a matter of fact, the best thing that ever happened to me for temperature loops, extruder barrels, that kind of thing, were auto-tuning controllers. I used discreet auto-tuning controllers, either Eurotherm or Omega, for barrel zones, just sent them setpoints. Auto tuning algorithms for use in the RSLogix type control software was coming out about the time I retired, but didn't work that well yet. Fast, low lag loops were easy to tune. A little p, lots of i, and adjust either by factor of 2. Small changes are a waste of time. When you drive it to oscillation, cut that parameter in half. Or if you really don't want to oscillate the loop (really large motors, etc.), sneak up on it a little slower. Pete Keillor |
#4
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On 9/22/2014 9:23 PM, RogerN wrote:
I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN Three is an excellent Wiki page on the subject. http://en.wikipedia.org/wiki/PID_controller |
#5
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 13:41:18 +0800, Stoob wrote:
On 23-Sep-14 10:23 AM, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN You need to ping Tim Wescott who sometimes posts here - he's the guru. What? Who? Huh? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com |
#6
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Mon, 22 Sep 2014 21:23:51 -0500, RogerN wrote:
I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. That depends on a number of factors, including but not limited to sampling rate, the amount of noise in the system, your desired settling time, and the settling time that you can actually achieve. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. That's a BAD way to do it. It's what's known in the more esoteric corners of the trade as a non-minimum phase filter, which basically means that the filter has more delay than necessary for the amount of amplitude shaping vs. frequency. Delay is a Bad Thing in a control loop, and is to be avoided. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. It would be perfectly meaningful if the system noise were low enough, and if there weren't any unexpected, fast paths from heater to thermostat. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. You want a band-limited derivative term. The best way to do this is pretty simple, too (calculate this as one hunk-of-code each sample time): derivative = (current_error - average_error); average_error = average_error + k * (current_error - average_error); Here "derivative" is the answer you want, "average_error" is a number that you carry from sample to sample (a so-called "state", like your integrator state), and k is a gain from 0 to 1 that determines the dynamics of the differentiator. The bigger k is the faster the derivative action, so the more noise it passes through and the more it helps fast settling. The smaller k, the less noise, and the less helpful the derivative action is when you're trying for high speeds. If you need to mess with band-limited derivative terms then you really should be doing frequency-domain design at least, but you can sometimes make things work with seat of the pants tuning. As a rule of thumb, set k to (10) * (sampling interval) / (settling time), where you know the sampling interval and, the settling time is what you're trying to achieve. If you end up computing a k greater than 1, then you need to re- think your sampling interval or your desired settling time. The link on my website to the article you want to read is currently broken: send me an email and I'll reply with a pdf. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com |
#7
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 14:45:33 -0500, Tim Wescott wrote:
On Mon, 22 Sep 2014 21:23:51 -0500, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. That depends on a number of factors, including but not limited to sampling rate, the amount of noise in the system, your desired settling time, and the settling time that you can actually achieve. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. That's a BAD way to do it. It's what's known in the more esoteric corners of the trade as a non-minimum phase filter, which basically means that the filter has more delay than necessary for the amount of amplitude shaping vs. frequency. Delay is a Bad Thing in a control loop, and is to be avoided. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. It would be perfectly meaningful if the system noise were low enough, and if there weren't any unexpected, fast paths from heater to thermostat. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. You want a band-limited derivative term. The best way to do this is pretty simple, too (calculate this as one hunk-of-code each sample time): derivative = (current_error - average_error); average_error = average_error + k * (current_error - average_error); Here "derivative" is the answer you want, "average_error" is a number that you carry from sample to sample (a so-called "state", like your integrator state), and k is a gain from 0 to 1 that determines the dynamics of the differentiator. The bigger k is the faster the derivative action, so the more noise it passes through and the more it helps fast settling. The smaller k, the less noise, and the less helpful the derivative action is when you're trying for high speeds. If you need to mess with band-limited derivative terms then you really should be doing frequency-domain design at least, but you can sometimes make things work with seat of the pants tuning. As a rule of thumb, set k to (10) * (sampling interval) / (settling time), where you know the sampling interval and, the settling time is what you're trying to achieve. If you end up computing a k greater than 1, then you need to re- think your sampling interval or your desired settling time. The link on my website to the article you want to read is currently broken: send me an email and I'll reply with a pdf. Or, try this: http://igor.chudov.com/manuals/Servo...PID-without-a- PhD.pdf -- Tim Wescott Wescott Design Services http://www.wescottdesign.com |
#8
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 07:37:36 -0500, Richard wrote:
On 9/22/2014 9:23 PM, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN Three is an excellent Wiki page on the subject. http://en.wikipedia.org/wiki/PID_controller It gets a bit sketchy in parts -- entire books could be (and have been!) written about PID controllers alone. But as Wikipedia articles go, I guess it's about average. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com |
#9
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
You need to ping Tim Wescott who sometimes posts here - he's the guru. What? Who? Huh? Maybe I've been sleeping under a rock, didn't know this. I've been fighting a buzzing at stop in my Galilmc.com controlled AMC servo amps and DC servos. 9 out of 10 times the servo will stop smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Adding the low pass filter to PID helped (see below for manual description) but i ended up reducing P,I and D by huge amounts to stop it. Now the system is sluggish. FWIW, Galil has servo tuning software to automatically tune your system. that worked for many years till this issue popped up. Comments? Karl PL FUNCTION: Pole DESCRIPTION: The PL command adds a low-pass filter in series with the PID compensation. The digital transfer function of the filter is (1 - n) / (Z - n) and the equivalent continuous filter is A/(S+A) where A is the filter cutoff frequency: A=(1/T) ln (1 / n) rad/sec and T is the sample time. To convert from the desired crossover (-3 dB) frequency in Hertz to the value given to PL, use the following formula: whe n is the argument given to PL T is the controller’s servo loop sample time in seconds (TM divided by 1,000,000) fc is the crossover frequency in Hertz n 0 0.2 0.4 0.6 0.8 0.999 Fc(HZ) ?‡ (off) 256 145 81 36 0 |
#10
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 19:20:17 -0500, Karl Townsend
wrote: You need to ping Tim Wescott who sometimes posts here - he's the guru. What? Who? Huh? Maybe I've been sleeping under a rock, didn't know this. I've been fighting a buzzing at stop in my Galilmc.com controlled AMC servo amps and DC servos. 9 out of 10 times the servo will stop smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Rate gain is turned up too high. Adding the low pass filter to PID helped (see below for manual description) but i ended up reducing P,I and D by huge amounts to stop it. Now the system is sluggish. FWIW, Galil has servo tuning software to automatically tune your system. that worked for many years till this issue popped up. Comments? Karl PL FUNCTION: Pole DESCRIPTION: The PL command adds a low-pass filter in series with the PID compensation. The digital transfer function of the filter is (1 - n) / (Z - n) and the equivalent continuous filter is A/(S+A) where A is the filter cutoff frequency: A=(1/T) ln (1 / n) rad/sec and T is the sample time. To convert from the desired crossover (-3 dB) frequency in Hertz to the value given to PL, use the following formula: whe n is the argument given to PL T is the controller’s servo loop sample time in seconds (TM divided by 1,000,000) fc is the crossover frequency in Hertz n 0 0.2 0.4 0.6 0.8 0.999 Fc(HZ) ?‡ (off) 256 145 81 36 0 "At the core of liberalism is the spoiled child, miserable, as all spoiled children are, unsatisfied, demanding, ill-disciplined, despotic and useless. Liberalism is a philosophy of sniveling brats." PJ O'Rourke |
#11
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 19:20:17 -0500, Karl Townsend
wrote: You need to ping Tim Wescott who sometimes posts here - he's the guru. What? Who? Huh? Maybe I've been sleeping under a rock, didn't know this. I've been fighting a buzzing at stop in my Galilmc.com controlled AMC servo amps and DC servos. 9 out of 10 times the servo will stop smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Correction..its probably Loop gain on your amp This might..might give you some ideas of where to start and how to do it. Maybe. http://www.omni-turn.com/Pages/Techn...djustment.html "At the core of liberalism is the spoiled child, miserable, as all spoiled children are, unsatisfied, demanding, ill-disciplined, despotic and useless. Liberalism is a philosophy of sniveling brats." PJ O'Rourke |
#12
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
"Tim Wescott" wrote in message
... On Mon, 22 Sep 2014 21:23:51 -0500, RogerN wrote: One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. That's a BAD way to do it. It's what's known in the more esoteric corners of the trade as a non-minimum phase filter, which basically means that the filter has more delay than necessary for the amount of amplitude shaping vs. frequency. Delay is a Bad Thing in a control loop, and is to be avoided. I don't necessarily agree that it's a bad way because you can look up how much time since the last change, for example using slow 100ms loop times and a 1 degree change in temperature, at the instant of the change, rate was 1 degree per 100ms, this would trigger a strong response, next loop, one deg per 200ms, next would be 1 degree in 300ms... and so on, decaying every loop until further change. I think this would be similar to difference in average error. I like the average error calculation you showed me because it does (nearly?) the same thing without the array of previous error data. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. You want a band-limited derivative term. The best way to do this is pretty simple, too (calculate this as one hunk-of-code each sample time): derivative = (current_error - average_error); average_error = average_error + k * (current_error - average_error); Here "derivative" is the answer you want, "average_error" is a number that you carry from sample to sample (a so-called "state", like your integrator state), and k is a gain from 0 to 1 that determines the dynamics of the differentiator. The bigger k is the faster the derivative action, so the more noise it passes through and the more it helps fast settling. The smaller k, the less noise, and the less helpful the derivative action is when you're trying for high speeds. If you need to mess with band-limited derivative terms then you really should be doing frequency-domain design at least, but you can sometimes make things work with seat of the pants tuning. As a rule of thumb, set k to (10) * (sampling interval) / (settling time), where you know the sampling interval and, the settling time is what you're trying to achieve. If you end up computing a k greater than 1, then you need to re- think your sampling interval or your desired settling time. The link on my website to the article you want to read is currently broken: send me an email and I'll reply with a pdf. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Thanks Tim, I figured you'd have a better way of doing what I'm wanting to do. There is a huge relative speed difference in applications, for example changing a room temperature at 1 degree per minute is fast but a motor moving at 1 encoder count per minute would be very slow for a 500 line encoder. The calculations I have seen before is amount of changer per time period and what I thought would be more useful is amount of time per change, or low rates of change. Interesting demonstration on YouTube: Raffaello D'Andrea_ The astounding athletic power of quadcopters Thanks! RogerN |
#13
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 20:22:38 -0500, RogerN wrote:
"Tim Wescott" wrote in message ... On Mon, 22 Sep 2014 21:23:51 -0500, RogerN wrote: One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. That's a BAD way to do it. It's what's known in the more esoteric corners of the trade as a non-minimum phase filter, which basically means that the filter has more delay than necessary for the amount of amplitude shaping vs. frequency. Delay is a Bad Thing in a control loop, and is to be avoided. I don't necessarily agree that it's a bad way because you can look up how much time since the last change, for example using slow 100ms loop times and a 1 degree change in temperature, at the instant of the change, rate was 1 degree per 100ms, this would trigger a strong response, next loop, one deg per 200ms, next would be 1 degree in 300ms... and so on, decaying every loop until further change. I think this would be similar to difference in average error. I like the average error calculation you showed me because it does (nearly?) the same thing without the array of previous error data. Well, if what you want to do is find a fascinating array of subtle and not- so-subtle pitfalls, then by all means give it a whirl. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. You want a band-limited derivative term. The best way to do this is pretty simple, too (calculate this as one hunk-of-code each sample time): derivative = (current_error - average_error); average_error = average_error + k * (current_error - average_error); snip Thanks Tim, I figured you'd have a better way of doing what I'm wanting to do. There is a huge relative speed difference in applications, for example changing a room temperature at 1 degree per minute is fast but a motor moving at 1 encoder count per minute would be very slow for a 500 line encoder. The calculations I have seen before is amount of changer per time period and what I thought would be more useful is amount of time per change, or low rates of change. I forgot to mention that if you're really going to sample at 1kHz and close a loop with a settling time of a minute, then your 'k' value is going to be damned small -- like on the order of 1/6000. This, in turn, means that you are exposed to your "average_error" term not having enough precision to keep track of changes. If your current_error is good to 12 bits, then your current_error * k must be good to 25 bits or so. That's barely within the ability of a single-precision floating point number to keep track. Even if you're only measuring temperatures with 8- bit ADCs, you're beyond the ability to keep track with 16-bit integers. With modern processors, at a 1kHz sampling rate, you can take care of this by using double-precision floating point numbers (with something like a 53- bit mantissa). If you're using an older processor, using 32-bit numbers and playing lots of scaling games will work. Speaking of subtle pitfalls. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com |
#14
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On 9/23/2014 6:51 PM, Tim Wescott wrote:
On Tue, 23 Sep 2014 07:37:36 -0500, Richard wrote: On 9/22/2014 9:23 PM, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN Three is an excellent Wiki page on the subject. http://en.wikipedia.org/wiki/PID_controller It gets a bit sketchy in parts -- entire books could be (and have been!) written about PID controllers alone. But as Wikipedia articles go, I guess it's about average. I thought it was very helpful. At least I learnt what PID was for. |
#15
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 22:43:50 -0500, Richard
wrote: On 9/23/2014 6:51 PM, Tim Wescott wrote: On Tue, 23 Sep 2014 07:37:36 -0500, Richard wrote: On 9/22/2014 9:23 PM, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN Three is an excellent Wiki page on the subject. http://en.wikipedia.org/wiki/PID_controller It gets a bit sketchy in parts -- entire books could be (and have been!) written about PID controllers alone. But as Wikipedia articles go, I guess it's about average. I thought it was very helpful. At least I learnt what PID was for. Btw...I have (2) Arduino books in ebook format if anyone needs them give me an email address and Ill send them to you. Gunner "At the core of liberalism is the spoiled child, miserable, as all spoiled children are, unsatisfied, demanding, ill-disciplined, despotic and useless. Liberalism is a philosophy of sniveling brats." PJ O'Rourke |
#16
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 19:20:17 -0500, Karl Townsend wrote:
You need to ping Tim Wescott who sometimes posts here - he's the guru. What? Who? Huh? Maybe I've been sleeping under a rock, didn't know this. I've been fighting a buzzing at stop in my Galilmc.com controlled AMC servo amps and DC servos. 9 out of 10 times the servo will stop smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Adding the low pass filter to PID helped (see below for manual description) but i ended up reducing P,I and D by huge amounts to stop it. Now the system is sluggish. FWIW, Galil has servo tuning software to automatically tune your system. that worked for many years till this issue popped up. Comments? user's manual excerpt snipped The low-pass filter and reduced gains sound an awful lot like a bandaid, not a solution. If it worked for years and now it doesn't, then something has worn or broken, or something got "upgraded", or it's been doing it all along and you only just now noticed. Control systems only work as well as the plants that they're driving -- they can't do magic if something is worn or broken. What's attached to the servo motors? If it's a ballscrew or some bolted- up assembly, my first guess would be that over time slop has developed in the system that allows the motor to wiggle a bit before it comes on to the load. I base this both on the fact that it used to work and doesn't now, and the fact that backlash and slop can be a position-dependent thing. It could also be something electrical -- a broken ground connection between the Galil board and a motor, or a power supply whose capacitors have dried out and allow motor current to couple in to the supply voltage, or worn-out brushes on a motor. Either that or you've added something with a bit of spring, or you've taken off some bracing that lets the motors or their loads "twang" a bit. Resonances like that can be death to a stable control system. So as tedious and pointless as it sounds, you may want to go over whatever backlash adjustment you have, loosen and re-tighten all mounting bolts, check for loose bearings, reverse any "improvements" you made about the time the singing started, check operation with a different power supply (or hang an oscilloscope off the power supply and see what happens to the power rail when it's "singing"), and all that due diligence stuff. For a while I was viewed as a sorcerer by the FLIR Systems service department, because nine times out of ten I could fix a control system problem just by having them replace one magic bearing. Then I confessed that you had to disassemble most of the bolted joints in the assembly to get to the bearing, and in the process of reassembly you tightened them all to spec, with Loctite. After that I got summoned to service a lot less often, but the problems they presented me with were a lot more challenging. (You couldn't just say "tighten all the bolts", because that made no sense to them. So they'd tighten what they could reach and claim to have done them all. But replacing a bearing -- that's real.) (Soon after, the jerks upstairs decided that engineers shouldn't be allowed to talk to service, and visa-versa. I hate big companies.) Keep in mind that I'm shooting in the dark here, because I know almost nothing about your setup. But you know that something has changed; now you just need to figure out what it is, and change it back. -- www.wescottdesign.com |
#17
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Correction..its probably Loop gain on your amp This might..might give you some ideas of where to start and how to do it. Maybe. http://www.omni-turn.com/Pages/Techn...djustment.html BINGO! I'M SURE THIS IS IT. Only ran this machine ten years now with this problem. Never adjusted this pot. Karl |
#18
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Wed, 24 Sep 2014 06:22:25 -0500, Karl Townsend
wrote: smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Correction..its probably Loop gain on your amp This might..might give you some ideas of where to start and how to do it. Maybe. http://www.omni-turn.com/Pages/Techn...djustment.html BINGO! I'M SURE THIS IS IT. Only ran this machine ten years now with this problem. Never adjusted this pot. Karl (Grin) Gunner "At the core of liberalism is the spoiled child, miserable, as all spoiled children are, unsatisfied, demanding, ill-disciplined, despotic and useless. Liberalism is a philosophy of sniveling brats." PJ O'Rourke |
#19
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Wed, 24 Sep 2014 01:51:42 -0500, tim wrote:
On Tue, 23 Sep 2014 19:20:17 -0500, Karl Townsend wrote: You need to ping Tim Wescott who sometimes posts here - he's the guru. What? Who? Huh? Maybe I've been sleeping under a rock, didn't know this. I've been fighting a buzzing at stop in my Galilmc.com controlled AMC servo amps and DC servos. 9 out of 10 times the servo will stop smoothly, the tenth it will oscilate about 1 or 2 encoder counts so rapidly it makes a buzzing noise. Adding the low pass filter to PID helped (see below for manual description) but i ended up reducing P,I and D by huge amounts to stop it. Now the system is sluggish. FWIW, Galil has servo tuning software to automatically tune your system. that worked for many years till this issue popped up. Comments? user's manual excerpt snipped The low-pass filter and reduced gains sound an awful lot like a bandaid, not a solution. If it worked for years and now it doesn't, then something has worn or broken, or something got "upgraded", or it's been doing it all along and you only just now noticed. Control systems only work as well as the plants that they're driving -- they can't do magic if something is worn or broken. What's attached to the servo motors? If it's a ballscrew or some bolted- up assembly, my first guess would be that over time slop has developed in the system that allows the motor to wiggle a bit before it comes on to the load. I base this both on the fact that it used to work and doesn't now, and the fact that backlash and slop can be a position-dependent thing. It could also be something electrical -- a broken ground connection between the Galil board and a motor, or a power supply whose capacitors have dried out and allow motor current to couple in to the supply voltage, or worn-out brushes on a motor. Either that or you've added something with a bit of spring, or you've taken off some bracing that lets the motors or their loads "twang" a bit. Resonances like that can be death to a stable control system. So as tedious and pointless as it sounds, you may want to go over whatever backlash adjustment you have, loosen and re-tighten all mounting bolts, check for loose bearings, reverse any "improvements" you made about the time the singing started, check operation with a different power supply (or hang an oscilloscope off the power supply and see what happens to the power rail when it's "singing"), and all that due diligence stuff. For a while I was viewed as a sorcerer by the FLIR Systems service department, because nine times out of ten I could fix a control system problem just by having them replace one magic bearing. Then I confessed that you had to disassemble most of the bolted joints in the assembly to get to the bearing, and in the process of reassembly you tightened them all to spec, with Loctite. After that I got summoned to service a lot less often, but the problems they presented me with were a lot more challenging. (You couldn't just say "tighten all the bolts", because that made no sense to them. So they'd tighten what they could reach and claim to have done them all. But replacing a bearing -- that's real.) (Soon after, the jerks upstairs decided that engineers shouldn't be allowed to talk to service, and visa-versa. I hate big companies.) Keep in mind that I'm shooting in the dark here, because I know almost nothing about your setup. But you know that something has changed; now you just need to figure out what it is, and change it back. Electronics...age. As they grow older...their component values change and over time.....they simply will drift so far out..in one direction or another..that they start acting wonky. And connectors oxidize. Ive found the #1 fix to any CNC machine that is doing random and strange things...pull the cards, clean the edge connectors with a a light ..light quick scrub with a ultrafine Scotchebright pad..some GOOD spray cleaner on plugs and sockets...press in /rock in.....any/all socketed chips..and by golly..the machine starts working again. That being said..the #2 fix..is replacing a board that has gone out of spec. Ballscrews wear. So do the thrust bearings. Generally thrust bearings will go first and create backlash/endplay...simply because they have a tiny contact area where wear shows up first. Tightening a thrust bearing will give you some ..some relief..but the moment they start to wear..their end is near and should be replaced as soon as possible. And based on the economy of the whole thing..if there are (2) thrust bearings..replace them both..not just (1). If one has worn to the point of showing backlash..the other is not far behind. That is IF your issue is mechanical..and on an older machine..thats the #1 place to start looking...right after making sure your servo tuning is correct. If its not mechanical..your servo motor is going bad. Bearings or encoders..with a strong hint its an encoder issue. Amps generally work..or not work. Seldom will they misbehave in one direction and not the other. Gunner, machine tool service tech "At the core of liberalism is the spoiled child, miserable, as all spoiled children are, unsatisfied, demanding, ill-disciplined, despotic and useless. Liberalism is a philosophy of sniveling brats." PJ O'Rourke |
#20
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Tue, 23 Sep 2014 22:43:50 -0500, Richard wrote:
On 9/23/2014 6:51 PM, Tim Wescott wrote: On Tue, 23 Sep 2014 07:37:36 -0500, Richard wrote: On 9/22/2014 9:23 PM, RogerN wrote: I've seen calculations for PID in a microcontroller but I'm thinking something is missing.. or perhaps I'm misunderstanding something. So if Derivative = current_error - previous_error then it's just effective for one cycle. It seems like it should be the change over a period of time, not necessarily one pass through the loop. One way would be to have an array of error[xx] and take the difference in change over a period of time involving several of times through the loop. Also, I've seen some PID that the I adjustment is in units of time. This might not be a big deal if there is a real high resolution, but if you have a temperature control that is heating for a 5 degree error, chances are the derivative term isn't going to have much effect if it's calculated every millisecond. If it's calculated over a longer period, for example how much change in the last 10 minutes, it would be more meaningful. I know a way to do this but I'm just looking for better ideas, perhaps more efficient memory usage. RogerN Three is an excellent Wiki page on the subject. http://en.wikipedia.org/wiki/PID_controller It gets a bit sketchy in parts -- entire books could be (and have been!) written about PID controllers alone. But as Wikipedia articles go, I guess it's about average. I thought it was very helpful. At least I learnt what PID was for. I get to be overly picky, because it's in my field. I'm sure that quantum mechanics scoff at Wikipedia's quantum mechanics articles. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com |
#21
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
"Tim Wescott" wrote in message
... On Tue, 23 Sep 2014 20:22:38 -0500, RogerN wrote: "Tim Wescott" wrote in message ... snip I don't necessarily agree that it's a bad way because you can look up how much time since the last change, for example using slow 100ms loop times and a 1 degree change in temperature, at the instant of the change, rate was 1 degree per 100ms, this would trigger a strong response, next loop, one deg per 200ms, next would be 1 degree in 300ms... and so on, decaying every loop until further change. I think this would be similar to difference in average error. I like the average error calculation you showed me because it does (nearly?) the same thing without the array of previous error data. Well, if what you want to do is find a fascinating array of subtle and not- so-subtle pitfalls, then by all means give it a whirl. I didn't like my idea because of the memory usage and processing of the array on every loop, but I don't think it would necessarily be bad due to responsiveness because you can respond strongly to the results of the last loop, I like your way with the average error much better though, less processing and less memory usage. But here's some reasoning that I feel is valid, though it wouldn't necessarily demand a large array. Lets say the application was a room temperature control and the maximum rate of change was no more than 1 degree per minute. So if it used the change for the last minute or so, it could give the strongest response needed for the rate of change, any faster rates of change would just be from noisy readings. Another weird thought I had was using the reading array data to calculate mean and standard deviation to have weak response to ~ +/- 3 sigma and stronger response to readings representing real change. If I used something like that in a R/C helicopter gyroscope, the noise level could also be an indication of out of balance blades, vibration levels that would be more harmful the the model and the controls. Of course not responding to noise would also reduce battery drain and wear on the servos. snip Thanks Tim, I figured you'd have a better way of doing what I'm wanting to do. There is a huge relative speed difference in applications, for example changing a room temperature at 1 degree per minute is fast but a motor moving at 1 encoder count per minute would be very slow for a 500 line encoder. The calculations I have seen before is amount of changer per time period and what I thought would be more useful is amount of time per change, or low rates of change. I forgot to mention that if you're really going to sample at 1kHz and close a loop with a settling time of a minute, then your 'k' value is going to be damned small -- like on the order of 1/6000. This, in turn, means that you are exposed to your "average_error" term not having enough precision to keep track of changes. If your current_error is good to 12 bits, then your current_error * k must be good to 25 bits or so. That's barely within the ability of a single-precision floating point number to keep track. Even if you're only measuring temperatures with 8- bit ADCs, you're beyond the ability to keep track with 16-bit integers. With modern processors, at a 1kHz sampling rate, you can take care of this by using double-precision floating point numbers (with something like a 53- bit mantissa). If you're using an older processor, using 32-bit numbers and playing lots of scaling games will work. Speaking of subtle pitfalls. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com What got me thinking about this was Allen Bradley's PID control, I believe the motion control cards close the loop in the card itself, but the PID in the processor uses an I time and a D time instead of Ki and Kd. On a temperature controller or other slower systems, measurements would be more like a little change over a longer period of time instead of quite a bit of change in a short period of time. I'm hoping to use the info in some temperature control applications as well as some R/C model stabilization applications. I bought some 3 axis gyro + 3 axis accelerometer modules from HobbyPartz for a reasonable price. I had the Arduino reading the data but I haven't done anything interesting with it yet. Thought I might start out by trying to get my boe-bot to operate on 2 wheels. Thanks, RogerN |
#22
Posted to rec.crafts.metalworking
|
|||
|
|||
PID calculations
On Thu, 25 Sep 2014 18:08:34 -0500, RogerN wrote:
"Tim Wescott" wrote in message ... On Tue, 23 Sep 2014 20:22:38 -0500, RogerN wrote: "Tim Wescott" wrote in message ... snip I don't necessarily agree that it's a bad way because you can look up how much time since the last change, for example using slow 100ms loop times and a 1 degree change in temperature, at the instant of the change, rate was 1 degree per 100ms, this would trigger a strong response, next loop, one deg per 200ms, next would be 1 degree in 300ms... and so on, decaying every loop until further change. I think this would be similar to difference in average error. I like the average error calculation you showed me because it does (nearly?) the same thing without the array of previous error data. Well, if what you want to do is find a fascinating array of subtle and not- so-subtle pitfalls, then by all means give it a whirl. I didn't like my idea because of the memory usage and processing of the array on every loop, but I don't think it would necessarily be bad due to responsiveness because you can respond strongly to the results of the last loop, I like your way with the average error much better though, less processing and less memory usage. But here's some reasoning that I feel is valid, though it wouldn't necessarily demand a large array. Lets say the application was a room temperature control and the maximum rate of change was no more than 1 degree per minute. So if it used the change for the last minute or so, it could give the strongest response needed for the rate of change, any faster rates of change would just be from noisy readings. I'm going to have to slide into discussing this in the frequency domain -- sorry about that, but I don't know a different way to express it that doesn't boil down to BS and hand-waving. The thing that you're trying to avoid here is a control loop that, when a signal starts at any one point in the loop and goes all the way around, it comes back to the same point looking the same. If that happens, then your system will oscillate. Doing stability analysis in the frequency domain is basically an exercise in making sure that for sine-wave signals, the condition holds that when the signal goes around the loop and back to the same point, it is either phase shifted, or smaller, or under some limited circumstances (and this is hard to get intuitively, but it's true) bigger. The basic problem you struggle with in a derivative element in a PID filter is that the positive phase shift you get from differentiation is good, but gain at high frequencies is bad. You've got the "reduce gain at high frequencies" part covered with your scheme, but you're ignoring the effects of phase shift. See he https://drive.google.com/file/d/0B5l...ZYXZwN0E/edit? usp=sharing This is a type of plot called a Bode plot. It shows the gain and phase shift of two different differentiators as a function of frequency. Your proposed differentiator is in black, mine is in blue. To keep the math from getting awkward, I chose to average over one second at a sampling rate of 1kHz, rather than one minute -- this doesn't change the basic results, it just makes the plot easier to look at. As a rule of thumb, figure that the differentiator is doing good as long as its phase is above +45 degrees. This is hard to pin down (it depends on what you're trying to control), but it'll serve to illustrate what I'm talking about. I jiggered the numbers on my differentiator so that it has the same gain and +45 degree crossing point as yours. Now notice two differences between these differentiators: phase shift and maximum gain. My differentiator never has a phase shift less than 0 degrees. This means in the worst case, at high frequencies my differentiator acts like a pure gain, nothing more. Your differentiator, on the other hand, has phase shift going all the way to -180 degrees. If your plant has enough gain at a frequency where your phase shift is high, your system will oscillate. Your differentiator has about the same high frequency gain as mine on average, but it has about twice as much gain in the peaks. This extra gain, even in the absence of the excessive phase shift, could cause oscillation in certain cases. Add in the excess phase shift, and the potential for oscillation just gets worse. The sum total of these two differences is that you just can't crank your differentiator up to the same gain that I can crank up mine, and maintain robust system stability. The fact that my differentiator is simpler to implement is just a bonus. Here's an old and somewhat terse paper on using the frequency domain in control systems design, written with a software guy in mind: http://wescottdesign.com/articles/zT...ransforms.html Another weird thought I had was using the reading array data to calculate mean and standard deviation to have weak response to ~ +/- 3 sigma and stronger response to readings representing real change. If I used something like that in a R/C helicopter gyroscope, the noise level could also be an indication of out of balance blades, vibration levels that would be more harmful the the model and the controls. Of course not responding to noise would also reduce battery drain and wear on the servos. You're describing a nonlinear controller. It turns out that doing this sort of thing makes formal design and performance analysis much more difficult. And, if your performance criterion is to reduce the root-mean-squared response to noise, it's not the best approach. Given a heavy-duty enough math background, you can prove that for a linear plant and Gaussian noise, that the best controller to achieve minimum RMS noise response is linear. Your scheme will reduce the response to _sensor_ noise, but it'll make the craft less responsive to small wind gusts and other environmental upsets. If your plant isn't very linear (no real-world plants are wholly linear), or if your performance criteria aren't to minimize RMS error, then the "best control is linear" proof is so many horse turds -- but the system will still be a pain to design for and analyze with the nonlinearities. snip Thanks Tim, I figured you'd have a better way of doing what I'm wanting to do. There is a huge relative speed difference in applications, for example changing a room temperature at 1 degree per minute is fast but a motor moving at 1 encoder count per minute would be very slow for a 500 line encoder. The calculations I have seen before is amount of changer per time period and what I thought would be more useful is amount of time per change, or low rates of change. snip What got me thinking about this was Allen Bradley's PID control, I believe the motion control cards close the loop in the card itself, but the PID in the processor uses an I time and a D time instead of Ki and Kd. On a temperature controller or other slower systems, measurements would be more like a little change over a longer period of time instead of quite a bit of change in a short period of time. A lot of industrial control applications like to describe the PID controller in terms of the time constants of the PD and the PI portions of the controller. This isn't an inherently bad way to do it, but it's different from how I usually approach things. I'm hoping to use the info in some temperature control applications as well as some R/C model stabilization applications. I bought some 3 axis gyro + 3 axis accelerometer modules from HobbyPartz for a reasonable price. I had the Arduino reading the data but I haven't done anything interesting with it yet. Thought I might start out by trying to get my boe-bot to operate on 2 wheels. The RC model stabilization stuff should be fun. If you start with quad copters, you can tether them to minimize crash damage while you're tuning. -- www.wescottdesign.com |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
OT - Please check my calculations | UK diy | |||
SAP calculations | UK diy | |||
Calculations pls! | UK diy | |||
So you need to make some calculations.... | Home Repair | |||
Gas consumption calculations | UK diy |