Re: [Emc-users] ilowpass filter
Jon Elson el...@... writes: - I just kind of feel my way and eventually get a response I can live with, but I know it would be better with a bit more damping. But, if I turn D up any higher, it becomes unstable. There obviously is a phase shift somewhere in the system, I have a good idea it is from electrical through the motor to mechanical, and then back from the encoder. But, I don't really have a tool to quantify it. So an electro-mechanical resonant loop... Have you tried any sort of mechanical damping directly on the encoder shaft- kind of like a stepper motor damper? I tried pressing my finger on the shaft, etc. but didn't get any change. Tom -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Sebastian Kuzminsky wrote: If the encoder counter provides only the number of edges seen since startup (or since some reset event), then it's really hard to estimate velocity well - it'll be quantised and crunchy (though as you say, maybe filtering could help). Yup, that is what my boards do right now. They do have a fast clock (1 MHz for digital filtering) but the FPGAs run at 10 MHz (old boards) and 40 MHz (newest ones). But, I hate to make a major modification if there is a decent way to do what we need in the PC. Maybe we can't, though. Once the information is lost, it can't be reconstructed. It just seems like 1000 samples/second OUGHT to be fast enough. My Allen-Bradley 7320 control had a 100 Hz servo cycle, and it worked fine, although clearly not as high a bandwidth as EMC can now provide. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
On Wed, 8 Apr 2009, Jon Elson wrote: Date: Wed, 08 Apr 2009 01:12:46 -0500 From: Jon Elson el...@pico-systems.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] ilowpass filter Sebastian Kuzminsky wrote: If the encoder counter provides only the number of edges seen since startup (or since some reset event), then it's really hard to estimate velocity well - it'll be quantised and crunchy (though as you say, maybe filtering could help). Yup, that is what my boards do right now. They do have a fast clock (1 MHz for digital filtering) but the FPGAs run at 10 MHz (old boards) and 40 MHz (newest ones). But, I hate to make a major modification if there is a decent way to do what we need in the PC. Maybe we can't, though. Once the information is lost, it can't be reconstructed. It just seems like 1000 samples/second OUGHT to be fast enough. My Allen-Bradley 7320 control had a 100 Hz servo cycle, and it worked fine, although clearly not as high a bandwidth as EMC can now provide. Jon As you mentioned before, raising the sample rate alleviates some of these problems. Especially for torque or voltage mode amps. 100 Hz might be OK for a velocity mode amplifier where most or all of the D term is handled in the motor drive, but would create to much phase shift in the D term (where you can least afford it) with voltage or current mode amplifiers. I rank motor drive systems like this. simplest to most complex: 1. Voltage mode, bare HBridges. Our Hbridges are like this. Voltage mode requires high sample rates, probably greater then 1 KHz Voltage more also _requires_ FF1 to compensate for BEMF. The lower output impedance of votage mode amplifiers means less D term is needed than current mode amplifiers. The PID output controls acceleration, but acceleration is not a linear function of PID output. 2. Current (torque) mode. Our 8I20 is like this. Like Voltage mode, a high sample rate is needed. The PID output controls acceleration. 3. Velocity mode. These amplifiers have a built in velocity loop, so normally very little D term is required. Properly tuned, a quite slow sample rate will work. PID output controls Velocity. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson wrote: John Kasunich wrote: The software encoder counter generates its velocity output by looking at not only how many counts arrived, but _when_ they arrived (with base period time resolution). I'm pretty sure the latest hostmot2 driver does the same - in that case it knows when pulses arrived with sub-microsecond resolution, and the velocity output can be very smooth. This image ( http://jmkasunich.com/pics/new-encoder.png ) shows the software encoder's velocity output (blue) compared to the actual velocity (green) and velocity calculated by differentiating the position (red). The improvement from red to blue is dramatic. The only time the blue trace shows any significant error is when the velocity is near zero, when many milliseconds go by with no counts at all. Certainly does look nice, but you can't do this with a standard encoder counter. Define standard counter. The whole idea behind FPGA based hardware is that you can do creative things that make your product better than the next one. Count+Timestamp counting of encoders isn't new - a former employer of mine was doing it in the early 1980's, and maybe before that. IMO, count+timestamp is (or should be) the standard for hardware encoder counting. Wait a minute, your scope trace is 100 ms/div, or 100 default servo cycles per div. So, I'm not sure this really does much different than a hardware encoder counter. That image isn't about hardware counting. Hardware counting enables high count rates, which in turn lets you use high PPR encoders to reduce quantization noise. That scope trace shows a dramatic reduction in noise with a LOW PPR encoder. If it does, I can't see it at this time scale. You can't see the difference between the red and blue traces?! Anyway, due to the limitations of communication rates to external devices, I don't see a real easy way to improve upon such hardware as I sell. Agreed - that is why I much prefer PCI attaached devices to EPP attached devices. My encoder counter as it is really doesn't record more information to work with. One COULD put in a velocity counter, but if it is only sampled once per servo cycle, there's no more info in it. I don't know what a velocity counter is. A timestamp register DOES provide more info, regardless of how often you read it. I think (hope) something useful can be done without increasing the sampling rate. It may well be that adding a smoothed velocity estimator to the encoder counter circuit would be beneficial, and by running that process at a higher clock rate in external hardware it could provide less delay than a filter limited by the servo sample rate. I'm not sure how much resources I can add to my FPGAs, but I know the register address space is pretty maxed out already. Also, the time to read the registers is already too long, I don't want to add any more data to read. My approach to the ideal encoder counter is to allocate the register space between counts and timestamp. Unfortunately there is no single split that is ideal for all systems. The timestamp needs to be big enough that it doesn't roll over twice between reads - a slower servo period requires a bigger timestamp register or a slower timestamp clock. The counter also needs to be big enough that it doesn't roll over twice between reads - a slower servo period needs either a bigger count register or a lower maximum count rate. If you are expecting very high count rates, you make the counter portion of the register wider, and slow down the timestamp clock. At high count rates, you can get decent velocity data using only the counts, so the timestamp resolution is less critical. On the other hand, if you have low count rates, you need all the help you can get to smooth the velocity, so you shrink the count register and use a faster timestamp clock for better resolution. In a PCI system, the overall register size would naturally be 32 bits. Assume a maximum servo period of 10mS (1/10 as fast as EMC's default, but lets give the user some flexibility). Assume a maximum count rate of 1MHz. That means a maximum of 10,000 counts between reads. In theory a 14 bit (16384 count) counter would do, but in practice rollover detection and handling is MUCH simpler if you add one more bit. So use 15 bits for the count. That leaves 17 bits for the timestamp. You could use a 10MHz timestamp counter, since the 17 bit timestamp would roll over every 12.8uS. Rollover detection in the timestamp register is much simpler, since it only counts up. In practice, I'd probaby do a 16/16 bit split. Having 100nS resolution on the timestamp is overkill, while adding a bit to the counter would allow either a higher max count rate or a longer sample interval. If you are limited to 24 bits, you need to make a slightly more difficult compromize, but it still works well. If you use a 1MHz timestamp clock, and
Re: [Emc-users] ilowpass filter
Peter C. Wallace wrote: As you mentioned before, raising the sample rate alleviates some of these problems. Especially for torque or voltage mode amps. 100 Hz might be OK for a velocity mode amplifier where most or all of the D term is handled in the motor drive, but would create to much phase shift in the D term (where you can least afford it) with voltage or current mode amplifiers. I rank motor drive systems like this. simplest to most complex: 1. Voltage mode, bare HBridges. Our Hbridges are like this. Voltage mode requires high sample rates, probably greater then 1 KHz Voltage more also _requires_ FF1 to compensate for BEMF. The lower output impedance of votage mode amplifiers means less D term is needed than current mode amplifiers. The PID output controls acceleration, but acceleration is not a linear function of PID output. Yes, that is what I'm doing. And, yes, FF1 helps a lot. And, yes, very little D is needed, too much makes it unstable. 2. Current (torque) mode. Our 8I20 is like this. Like Voltage mode, a high sample rate is needed. The PID output controls acceleration. 3. Velocity mode. These amplifiers have a built in velocity loop, so normally very little D term is required. Properly tuned, a quite slow sample rate will work. PID output controls Velocity. Assuming steady-state ONLY, that is true. But, CNC programs are not steady-state, they change velocity all the time. So, you can't sample too slowly or there will be big excursions of following error on the discontinuities. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
John Kasunich wrote: Jon Elson wrote: Certainly does look nice, but you can't do this with a standard encoder counter. Define standard counter. A position counter for a quadrature encoder. When asked, it reports position, and that is IT. No velocity of any sort. The whole idea behind FPGA based hardware is that you can do creative things that make your product better than the next one. Count+Timestamp counting of encoders isn't new - a former employer of mine was doing it in the early 1980's, and maybe before that. IMO, count+timestamp is (or should be) the standard for hardware encoder counting. OK, I see the advantages. But, it requires changing things in the field. (Maybe not having downloadable firmware was a mistake, but these products started life in 2000.) Also, the communication overhead is already pretty high, I don't want to slow things down any more with additional registers to read. Wait a minute, your scope trace is 100 ms/div, or 100 default servo cycles per div. So, I'm not sure this really does much different than a hardware encoder counter. That image isn't about hardware counting. Hardware counting enables high count rates, which in turn lets you use high PPR encoders to reduce quantization noise. That scope trace shows a dramatic reduction in noise with a LOW PPR encoder. OK, I think I did see the coarseness of the counts, there. If it does, I can't see it at this time scale. You can't see the difference between the red and blue traces?! I'm used to seeing something that looks like the red trace, so maybe I failed to look at the difference in information content there. Yes, there IS a difference in the traces. Anyway, due to the limitations of communication rates to external devices, I don't see a real easy way to improve upon such hardware as I sell. Agreed - that is why I much prefer PCI attaached devices to EPP attached devices. And, apparently others do, too. I am mostly out of business here, maybe that is the reason. Perhaps an ethernet interface would revive things. I don't know what a velocity counter is. A timestamp register DOES provide more info, regardless of how often you read it. So, this just records the time of the LAST count, not ALL counts since you read the encoder status last? My approach to the ideal encoder counter is to allocate the register space between counts and timestamp. Unfortunately there is no single split that is ideal for all systems. Hmm, an interesting way to do things. I'm not sure I'd do it this way, although that would keep from increasing the I/O traffic. But, just adding 4 more 16-bit reads to the traffic might not be such a big deal. Then, with a little bit of code, old boards could work with the new driver, and new boards could work with an old driver. In either cross-version, the new timestamp would not be operative, but wouldn't interfere with other functionality. I don't know if I have enough time before the fest to try to implement the timestamp in the FPGA, but it doesn't sound real tough. Add a global counter for all 4 axes, and a register that latches the counter at every transition. Is that all that's required, catching the timestamp at the last encoder count? Lets see, at 1 KHz, and 10 MHz timestamp clock, that's 10,000 counts per sampling interval, so 16 bits should be fine. It will roll over every 6.5 samples. Using a PCI parallel port card can speed up the I/O to my boards a good deal, so these additional bytes might be no slower than using the on-mobo par port with the original encoder function. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson wrote: So, this just records the time of the LAST count, not ALL counts since you read the encoder status last? Yes. My approach to the ideal encoder counter is to allocate the register space between counts and timestamp. Unfortunately there is no single split that is ideal for all systems. Hmm, an interesting way to do things. I'm not sure I'd do it this way, although that would keep from increasing the I/O traffic. But, just adding 4 more 16-bit reads to the traffic might not be such a big deal. Then, with a little bit of code, old boards could work with the new driver, and new boards could work with an old driver. In either cross-version, the new timestamp would not be operative, but wouldn't interfere with other functionality. I don't know if I have enough time before the fest to try to implement the timestamp in the FPGA, but it doesn't sound real tough. Be careful here. You must ensure that the count and the timestamp are from the SAME encoder edge. That's why I like stuffing both values into the same wide register. There are certainly other ways to ensure the same result. You already deal with that problem when reading your 24 bit count registers over the 8 bit EPP bus, now you have 40 bits to deal with. Add a global counter for all 4 axes, and a register that latches the counter at every transition. Is that all that's required, catching the timestamp at the last encoder count? Yes. Regards, John Kasunich -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Stephen Wille Padnos wrote: Jon Elson wrote: John Kasunich wrote: Be careful here. You must ensure that the count and the timestamp are from the SAME encoder edge. That's why I like stuffing both values into the same wide register. There are certainly other ways to ensure the same result. You already deal with that problem when reading your 24 bit count registers over the 8 bit EPP bus, now you have 40 bits to deal with. Ah, good point! So, not only is there the timestamp storage register, but it needs a holding register (per axis) that is clocked when the encoder latch register is clocked. Tha doesn't sound real hard to do. You've already got 24 bits per counter, you might be able to get by with just splitting that into a 12-bit counter and a 12-bit timestamp. Use a 1MHz or even 250 or 500 kHz timer (though 1 MHz would still take 2 or 4 ms to overflow). The input would have to be getting a 2MHz+ edge rate to overflow in the default 1 kHz servo cycle. I saw that the top 16 read registers are unused also, so you could just add 8 bytes there with 16-bit timestamps. Another option is to use the top 16 bytes as four, 4-byte registers with 16+16 bit count+timestamp data. If there's a version check, the read region can be set up to read from 0x0C through 0x1F instead of 0x00 - 0x0F. This keeps the read contiguous, and only adds 4 bytes to the data size. I'm thinking of adding a new set of 4 16-bit registers to give the timestamps. This would leave the rest of the encoder hardware unchanged, and the driver could check for a certain rev level to enable reading the extra registers. That provides the greatest forward/backward compatibility. I want to preserve the 24-bit counter, as somebody, someday, may need an insane count rate. There may also be some people running this board with their own software, so I don't want to make changes that would foul them up. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson el...@... writes: snip... Oh, one big feature I added, with the expert help of Jeff Eppler at the Fest, was to put an integer lowpass filter on the jog dial to get rid of the nasty buzzing that the coarse jog dial counts caused. I have used this on both the Bridgeport and minimill, and it is a great improvement. The ilowpass component should be on all EMC2 distros since about July 2008. Oh oh... Apart from the jog pendant, you just touched on the one aspect of my Kasuga EMC2 conversion that still bugs me. All the axes buzz and moan while holding position, and if I try to adjust the D term or deadband to eliminate this, then my following error causes faults during rapids. Is there a way to use the ilowpass filter to eliminate all the noise my mill makes while at rest? Thanks, Tom -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Tom wrote: Oh oh... Apart from the jog pendant, you just touched on the one aspect of my Kasuga EMC2 conversion that still bugs me. All the axes buzz and moan while holding position, and if I try to adjust the D term or deadband to eliminate this, then my following error causes faults during rapids. Is there a way to use the ilowpass filter to eliminate all the noise my mill makes while at rest? No, for two reasons: 1) A lowpass filter will not solve PID of instability - if anything it will make it worse since it introduces a lag. 2) ilowpass is an _integer_ filter, it can't be used for floating point signals (which include the command, feedback, and output of PID loops). The correct solution is to tune your PID loops (using D and deadband as needed) until they are stable. You must use halscope to view the resulting waveforms and decide what to adjust. Once you have the axes tuned as well as possible, halscope will tell you the maximum error you have during a rapid. Assuming that is acceptable, you set the following error a bit higher so it doesn't trip. Regards, John Kasunich -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Tom wrote: Jon Elson el...@... writes: snip... Oh, one big feature I added, with the expert help of Jeff Eppler at the Fest, was to put an integer lowpass filter on the jog dial to get rid of the nasty buzzing that the coarse jog dial counts caused. I have used this on both the Bridgeport and minimill, and it is a great improvement. The ilowpass component should be on all EMC2 distros since about July 2008. Oh oh... Apart from the jog pendant, you just touched on the one aspect of my Kasuga EMC2 conversion that still bugs me. All the axes buzz and moan while holding position, and if I try to adjust the D term or deadband to eliminate this, then my following error causes faults during rapids. Is there a way to use the ilowpass filter to eliminate all the noise my mill makes while at rest? What servo drives are you using? A problem with EMC2 using the PID hal component is that the D term has no filtering on it. Due to the double quantized nature of encoders, there is a real spike in the frequency spectrum of the velocity at 1/2 the sampling rate. I call it double quantized because position is measured in discrete counts, and then the count is sampled at regular intervals. So, it is guaranteed that at certain velocities you will get a +1 / -1 jitter in the number of encoder counts per sampling interval. If the encoder resolution is very high (I have 128,000 counts/inch on my minimill) it somewhat masks this. At lower encoder resolutions, the problem grows. Imagine a system where you are moving at 500 counts/second. With a sample rate of 1000/second, then the samples come up like this : 0, 1, 0, 1, 0 etc. That is a 100 % jump from sample to sample at 500 Hz. If you have much D turned on, it is going to buzz badly, as the D just miltiplies this effect. Try turning the D as low as you possibly can go. Another scheme that seems to help is to turn up the servo-thread rate. Depending on your servo interface, you may be able to go to 2 or even 5 KHz. At 5 KHz, the buzz frequency will be moved up to 2.5 KHz, where it may be above the passband of the servo amps. This problem has been bugging me for some time, and I am planning to work on it at the EMC Fest in May in Wichita. My general plan would be to put in a fairly simple digital notch filter at 1/2 the sample rate. Maybe somebody well versed in control theory can expound on the implications of this, and whether it would be better to have a sharp notch or a more gradual rolloff starting a little below 1/2 f. Buzzing at rest may be eliminated by adding a little deadband. Depending on encoder resolution, a deadband equal to a couple encoder counts will often stop the oscillations entirely, or make them sporadic. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
John Kasunich wrote: No, for two reasons: 1) A lowpass filter will not solve PID of instability - if anything it will make it worse since it introduces a lag. 2) ilowpass is an _integer_ filter, it can't be used for floating point signals (which include the command, feedback, and output of PID loops). The correct solution is to tune your PID loops (using D and deadband as needed) until they are stable. You must use halscope to view the resulting waveforms and decide what to adjust. Once you have the axes tuned as well as possible, halscope will tell you the maximum error you have during a rapid. Assuming that is acceptable, you set the following error a bit higher so it doesn't trip. Yes, agreed, any lag introduced is a major problem in a control loop. But, the quantizing nature of the encoder and counter cause there to be a lot of power right at 1/2 f. It seems to me, a real neophyte in control theory, that that power is NON-information, almost entirely a product of the sampling process, ie. noise. Both the P term, but most especially the D term, magnify these velocity fluctuations. I normally run with a D term setting around 2, with a P term of 1500, on one machine. Make the D much higher, and the system breaks into oscillation. D should be damping, of course, but it creates so much amplification of the velocity jitter that it excites some modes in the system. (In my way of thinking, too much D should just make the response greatly underdamped, but instead, it becomes unstable. This is likely due to excessive mass spring elsewhere, possibly mechanical.) Maybe the whole problem is the system is trying to have too much bandwidth for an already sluggish mechanical system. With a 1 KHz servo-thread, it is trying for a 500 Hz bandwidth, and everything should just move to a lower bandpass. Especially on desktop machines with little motors, they definitely can have some real mechanical response at 500 Hz. On the other hand, I have had some improvement by increasing the servo-thread rate, moving the 1/2 f noise up to a higher frequency. I'll be glad to demonstrate all of this behavior at the Fest, we can instrument to your heart's content, and see what you think. I agree that a gradual lowpass filter would introduce too much lag, but there are a wide range of digital filter algorithms to choose from. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson wrote: A problem with EMC2 using the PID hal component is that the D term has no filtering on it. Due to the double quantized nature of encoders, there is a real spike in the frequency spectrum of the velocity at 1/2 the sampling rate. I call it double quantized because position is measured in discrete counts, and then the count is sampled at regular intervals. So, it is guaranteed that at certain velocities you will get a +1 / -1 jitter in the number of encoder counts per sampling interval. It's true that a digital system (such as a computer) estimating an analog value (such as encoder velocity) always quantises to some extent, there are things you can do with encoder counting that result in significantly less quantisation error. If the encoder counter can timestamp the arrival of the encoder edges with a temporal resolution that is high compared to the servo cycle period, then the velocity can be accurately and smoothly estimated at any (constant) velocity, from much less than one edge per servo cycle up to the max practical edge rate. If the encoder resolution is very high (I have 128,000 counts/inch on my minimill) it somewhat masks this. At lower encoder resolutions, the problem grows. Imagine a system where you are moving at 500 counts/second. With a sample rate of 1000/second, then the samples come up like this : 0, 1, 0, 1, 0 etc. That is a 100 % jump from sample to sample at 500 Hz. The Reciprocal Time Estimator solves this problem. See section 14.2 of this paper: http://repositories.cdlib.org/its/path/reports/UCB-ITS-PRR-95-3/ -- Sebastian Kuzminsky -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson wrote: Tom wrote: Jon Elson el...@... writes: snip... Oh, one big feature I added, with the expert help of Jeff Eppler at the Fest, was to put an integer lowpass filter on the jog dial to get rid of the nasty buzzing that the coarse jog dial counts caused. I have used this on both the Bridgeport and minimill, and it is a great improvement. The ilowpass component should be on all EMC2 distros since about July 2008. Oh oh... Apart from the jog pendant, you just touched on the one aspect of my Kasuga EMC2 conversion that still bugs me. All the axes buzz and moan while holding position, and if I try to adjust the D term or deadband to eliminate this, then my following error causes faults during rapids. Is there a way to use the ilowpass filter to eliminate all the noise my mill makes while at rest? What servo drives are you using? A problem with EMC2 using the PID hal component is that the D term has no filtering on it. Due to the double quantized nature of encoders, there is a real spike in the frequency spectrum of the velocity at 1/2 the sampling rate. I call it double quantized because position is measured in discrete counts, and then the count is sampled at regular intervals. So, it is guaranteed that at certain velocities you will get a +1 / -1 jitter in the number of encoder counts per sampling interval. If the encoder resolution is very high (I have 128,000 counts/inch on my minimill) it somewhat masks this. At lower encoder resolutions, the problem grows. Imagine a system where you are moving at 500 counts/second. With a sample rate of 1000/second, then the samples come up like this : 0, 1, 0, 1, 0 etc. That is a 100 % jump from sample to sample at 500 Hz. If you have much D turned on, it is going to buzz badly, as the D just miltiplies this effect. Try turning the D as low as you possibly can go. Another scheme that seems to help is to turn up the servo-thread rate. Depending on your servo interface, you may be able to go to 2 or even 5 KHz. At 5 KHz, the buzz frequency will be moved up to 2.5 KHz, where it may be above the passband of the servo amps. This problem has been bugging me for some time, and I am planning to work on it at the EMC Fest in May in Wichita. My general plan would be to put in a fairly simple digital notch filter at 1/2 the sample rate. Maybe somebody well versed in control theory can expound on the implications of this, and whether it would be better to have a sharp notch or a more gradual rolloff starting a little below 1/2 f. Buzzing at rest may be eliminated by adding a little deadband. Depending on encoder resolution, a deadband equal to a couple encoder counts will often stop the oscillations entirely, or make them sporadic. That will be something very interesting to experiment with at the Fest. I have long had my own thoughts on this issue. Our software encoder counter has a velocity output which is much less quantized than the position output. Some (but not all) hardware drivers also have a velocity output. If the PID loop had both position and velocity feedback inputs, it could use the velocity feedback for the D term. This has the potential to be better than any filter - the encoder counter (hardware or software) simply has more information to work with. The software encoder counter generates its velocity output by looking at not only how many counts arrived, but _when_ they arrived (with base period time resolution). I'm pretty sure the latest hostmot2 driver does the same - in that case it knows when pulses arrived with sub-microsecond resolution, and the velocity output can be very smooth. This image ( http://jmkasunich.com/pics/new-encoder.png ) shows the software encoder's velocity output (blue) compared to the actual velocity (green) and velocity calculated by differentiating the position (red). The improvement from red to blue is dramatic. The only time the blue trace shows any significant error is when the velocity is near zero, when many milliseconds go by with no counts at all. Despite the name of the image, this is not new - the velocity output was added to CVS in January of 2007 and was released as part of EMC 2.2.0. However, I've never gotten around to tweaking the PID loop to take advantage of it. Regards, John Kasunich -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
John Kasunich wrote: I have long had my own thoughts on this issue. Our software encoder counter has a velocity output which is much less quantized than the position output. Some (but not all) hardware drivers also have a velocity output. If the PID loop had both position and velocity feedback inputs, it could use the velocity feedback for the D term. This has the potential to be better than any filter - the encoder counter (hardware or software) simply has more information to work with. The software encoder counter generates its velocity output by looking at not only how many counts arrived, but _when_ they arrived (with base period time resolution). I'm pretty sure the latest hostmot2 driver does the same - in that case it knows when pulses arrived with sub-microsecond resolution, and the velocity output can be very smooth. The hm2 encoder driver is currently using 1 MHz for the encoder edge timestamp clock frequency. The hardware supports more, maybe I should bump it up... -- Sebastian Kuzminsky -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson el...@... writes: What servo drives are you using? I am using Advanced Motion pwm brush type amplifiers. See here: http://www.a-m-c.com/download/datasheet/30a20ac.pdf snip... This problem has been bugging me for some time, and I am planning to work on it at the EMC Fest in May in Wichita. My general plan would be to put in a fairly simple digital notch filter at 1/2 the sample rate. Maybe somebody well versed in control theory can expound on the implications of this, and whether it would be better to have a sharp notch or a more gradual rolloff starting a little below 1/2 f. Buzzing at rest may be eliminated by adding a little deadband. Depending on encoder resolution, a deadband equal to a couple encoder counts will often stop the oscillations entirely, or make them sporadic. Jon Wow... thanks Jon. I may have to re-read this several times until it sinks in. I will try setting the servo-thread rate higher and see how it reacts. Increasing deadband works from experience, but I will have to do some test cuts and see if following error is tolerable. Tom -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
On Tue, 7 Apr 2009, Tom wrote: Date: Tue, 7 Apr 2009 18:21:03 + (UTC) From: Tom kestrel...@yahoo.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: emc-users@lists.sourceforge.net Subject: Re: [Emc-users] ilowpass filter Jon Elson el...@... writes: What servo drives are you using? I am using Advanced Motion pwm brush type amplifiers. See here: http://www.a-m-c.com/download/datasheet/30a20ac.pdf snip... This problem has been bugging me for some time, and I am planning to work on it at the EMC Fest in May in Wichita. My general plan would be to put in a fairly simple digital notch filter at 1/2 the sample rate. Maybe somebody well versed in control theory can expound on the implications of this, and whether it would be better to have a sharp notch or a more gradual rolloff starting a little below 1/2 f. Buzzing at rest may be eliminated by adding a little deadband. Depending on encoder resolution, a deadband equal to a couple encoder counts will often stop the oscillations entirely, or make them sporadic. Jon Wow... thanks Jon. I may have to re-read this several times until it sinks in. I will try setting the servo-thread rate higher and see how it reacts. Increasing deadband works from experience, but I will have to do some test cuts and see if following error is tolerable. Tom Also (connecting some dots here) if you are using HostMot2, D term crunchyness should be much improved when EMCs PID loop is modified to be able to use the drivers Velocity output (which uses DeltaCounts/DeltaTime velocity estimation). This should allow larger D terms without instabilities -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Peter C. Wallace p...@... writes: snip... Also (connecting some dots here) if you are using HostMot2, D term crunchyness should be much improved when EMCs PID loop is modified to be able to use the drivers Velocity output (which uses DeltaCounts/DeltaTime velocity estimation). This should allow larger D terms without instabilities snip... Peter Wallace Mesa Electronics Peter, Are you saying that if I upgrade to Hostmot2, there is a Velocity output hal pin that is not available to me using Hostmot? Would this require modifications to the motion.hal file in order to modify the PID loop? Could you connect a few more dots for me here? thanks, tom -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Tom wrote: [snip] Peter, Are you saying that if I upgrade to Hostmot2, there is a Velocity output hal pin that is not available to me using Hostmot? Yes, hostmot2 uses different FPGA firmware and a different driver. Would this require modifications to the motion.hal file in order to modify the PID loop? That's actually two separate questions. Yes, you would need to modify your HAL files. The name of the driver and how it's loaded have changed, as well as the pin/parameter/function names. At the moment, the PID component can't take an externally supplied velocity as input. Several people are interested in working on this at Fest (if not before), so that may be rectified in the next couple of months. Could you connect a few more dots for me here? .___.___. :) - Steve -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Tom wrote: Peter C. Wallace p...@... writes: snip... Also (connecting some dots here) if you are using HostMot2, D term crunchyness should be much improved when EMCs PID loop is modified to be able to use the drivers Velocity output (which uses DeltaCounts/DeltaTime velocity estimation). This should allow larger D terms without instabilities snip... Peter Wallace Mesa Electronics Peter, Are you saying that if I upgrade to Hostmot2, there is a Velocity output hal pin that is not available to me using Hostmot? Would this require modifications to the motion.hal file in order to modify the PID loop? Could you connect a few more dots for me here? The hostmot2 encoder driver has a good velocity estimator, with the value available on the .velocity-fb pin. I believe (though i dont know for sure) that the older hostmot (aka m5i20) driver does *not* export encoder velocity, so with that driver velocity has to be estimated using additional HAL components (like ddt), which won't give as good a result. However... The current PID implementation in EMC2 does its own velocity estimation (controlled via the feedforward gain), and can not accept velocity information from outside itself. There are other reasons you might want good velocity feedback from your encoders, but better PID control is not yet one of them. Maybe in 2.4 ;-) -- Sebastian Kuzminsky -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson el...@... writes: snip... Maybe the whole problem is the system is trying to have too much bandwidth for an already sluggish mechanical system. With a 1 KHz servo-thread, it is trying for a 500 Hz bandwidth, and everything should just move to a lower bandpass. Especially on desktop machines with little motors, they definitely can have some real mechanical response at 500 Hz. On the other hand, I have had some improvement by increasing the servo-thread rate, moving the 1/2 f noise up to a higher frequency. I'll be glad to demonstrate all of this behavior at the Fest, we can instrument to your heart's content, and see what you think. I agree that a gradual lowpass filter would introduce too much lag, but there are a wide range of digital filter algorithms to choose from. Jon Thanks Jon I get the feeling you were responding to John K's comments more than my own... still I will take that as an invitation to attend the Fest in May ;-) Tom -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
John Kasunich wrote: I have long had my own thoughts on this issue. Our software encoder counter has a velocity output which is much less quantized than the position output. Some (but not all) hardware drivers also have a velocity output. If the PID loop had both position and velocity feedback inputs, it could use the velocity feedback for the D term. This has the potential to be better than any filter - the encoder counter (hardware or software) simply has more information to work with. The software encoder counter generates its velocity output by looking at not only how many counts arrived, but _when_ they arrived (with base period time resolution). I'm pretty sure the latest hostmot2 driver does the same - in that case it knows when pulses arrived with sub-microsecond resolution, and the velocity output can be very smooth. This image ( http://jmkasunich.com/pics/new-encoder.png ) shows the software encoder's velocity output (blue) compared to the actual velocity (green) and velocity calculated by differentiating the position (red). The improvement from red to blue is dramatic. The only time the blue trace shows any significant error is when the velocity is near zero, when many milliseconds go by with no counts at all. Certainly does look nice, but you can't do this with a standard encoder counter. Wait a minute, your scope trace is 100 ms/div, or 100 default servo cycles per div. So, I'm not sure this really does much different than a hardware encoder counter. If it does, I can't see it at this time scale. Anyway, due to the limitations of communication rates to external devices, I don't see a real easy way to improve upon such hardware as I sell. My encoder counter as it is really doesn't record more information to work with. One COULD put in a velocity counter, but if it is only sampled once per servo cycle, there's no more info in it. I think (hope) something useful can be done without increasing the sampling rate. It may well be that adding a smoothed velocity estimator to the encoder counter circuit would be beneficial, and by running that process at a higher clock rate in external hardware it could provide less delay than a filter limited by the servo sample rate. I'm not sure how much resources I can add to my FPGAs, but I know the register address space is pretty maxed out already. Also, the time to read the registers is already too long, I don't want to add any more data to read. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Sebastian Kuzminsky wrote: Jon Elson wrote: A problem with EMC2 using the PID hal component is that the D term has no filtering on it. Due to the double quantized nature of encoders, there is a real spike in the frequency spectrum of the velocity at 1/2 the sampling rate. I call it double quantized because position is measured in discrete counts, and then the count is sampled at regular intervals. So, it is guaranteed that at certain velocities you will get a +1 / -1 jitter in the number of encoder counts per sampling interval. It's true that a digital system (such as a computer) estimating an analog value (such as encoder velocity) always quantises to some extent, there are things you can do with encoder counting that result in significantly less quantisation error. If the encoder counter can timestamp the arrival of the encoder edges with a temporal resolution that is high compared to the servo cycle period, then the velocity can be accurately and smoothly estimated at any (constant) velocity, from much less than one edge per servo cycle up to the max practical edge rate. sampling jitter is not the problem. In some systems with relatively low encoder resolution, there are just a couple counts per servo cycle. So, the +1 / -1 nature of the sampling interval necessarily adds a noise to the perceived velocity. Estimating means filtering, as far as I can see. If the encoder resolution is very high (I have 128,000 counts/inch on my minimill) it somewhat masks this. At lower encoder resolutions, the problem grows. Imagine a system where you are moving at 500 counts/second. With a sample rate of 1000/second, then the samples come up like this : 0, 1, 0, 1, 0 etc. That is a 100 % jump from sample to sample at 500 Hz. The Reciprocal Time Estimator solves this problem. See section 14.2 of this paper: http://repositories.cdlib.org/its/path/reports/UCB-ITS-PRR-95-3/ I'll have to look at this. But, a quick scan shows you need to analyze the arrival time of each encoder count. My current external hardware doesn't do this, and may not have the FPGA resources to do it. With several hundred units in the field, I'm hoping for a solution that can work with the existing hardware. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Sebastian Kuzminsky s...@... writes: snip... The hostmot2 encoder driver has a good velocity estimator, with the value available on the .velocity-fb pin. I believe (though i dont know for sure) that the older hostmot (aka m5i20) driver does *not* export encoder velocity, so with that driver velocity has to be estimated using additional HAL components (like ddt), which won't give as good a result. However... The current PID implementation in EMC2 does its own velocity estimation (controlled via the feedforward gain), and can not accept velocity information from outside itself. There are other reasons you might want good velocity feedback from your encoders, but better PID control is not yet one of them. Maybe in 2.4 Sebastian, Stephen, Peter, John, Jon - Thank you all for the volumes of information. I have read everything carefully - most several times - and followed all of the links and images. btw (John K.) - I have a printout right here on my desk from Anders Wallins' web page on PID tuning that I have used as my guide during the EMC2 conversion. Thanks for the pointer. As a result of your generous feedback I have put together a plan to fix the problem: ergo - ` Upgrade the encoders to 2000 line (8000 ppr) With 5 turn/inch ballscrews this will get me in the range of 10 encoder counts per .0004 - since I am using the Mesa 5i20 I can still have reasonably fast rapids on a fast host computer. ` Adjust the servo period to a smaller value, test for latency issues. ` Using halscope, adjust PID loop for lowest FERROR with attention to the FF1 FF2 to minimize accel/decel errors, then back off on D term and/or increase deadband to improve stability (noise) at rest. ` Set FERROR MIN_FERROR to prevent erroring out. ` Wait patiently for a PID2 for EMC2 that hopefully gets incorporated into the Head. ` If so, then download and compile the latest Head version of EMC2, upgrade to Hostmot2, make the necessary adjustments to my ini hal files and enjoy a smoother PID loop. Tom -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] ilowpass filter
Jon Elson wrote: Sebastian Kuzminsky wrote: If the encoder counter can timestamp the arrival of the encoder edges with a temporal resolution that is high compared to the servo cycle period, then the velocity can be accurately and smoothly estimated at any (constant) velocity, from much less than one edge per servo cycle up to the max practical edge rate. sampling jitter is not the problem. In some systems with relatively low encoder resolution, there are just a couple counts per servo cycle. So, the +1 / -1 nature of the sampling interval necessarily adds a noise to the perceived velocity. Estimating means filtering, as far as I can see. If the encoder counter provides only the number of edges seen since startup (or since some reset event), then it's really hard to estimate velocity well - it'll be quantised and crunchy (though as you say, maybe filtering could help). But if the encoder counter has a fast clock (like the base period of the software encoder counter, or the Quadrature Timestamp Clock of the HostMot2 firmware), then it's possible to do better. In this setup, the data sent from the encoder counter to the driver takes the form X edges seen since reset, most recent edge seen at time T. By remembering the last time this timestamped edge count datapoint changed, the driver can estimate velocity as V = dX/dT. If the datapoint has not changed (no edges seen) since the previous time through the servo loop, then things get a little more complicated. We know an upper bound on the velocity - it's *not* so fast that we *just* saw an edge. If this upper bound is *greater* than the previous velocity estimate, then stay with the previous estimate. If the upper bound is *smaller* than the current velocity, then use the upper bound. So, the one edge every other servo period example above would look like this. Ts is the time that the servo loop runs, X is the total number of edges seen, and Te is the timestamp of the most recent edge. Ts=0.00 X=0 Te=0.00 Starting condition, first time through the loop. Report V = 0. Ts=0.001000 X=1 Te=0.000456 New datapoint! This informs the position, but we dont have enough data to estimate velocity yet. Ts=0.002000 X=1 Te=0.000456 No new edge this time. The fastest possible (average) speed since the last time through the loop would result in an edge right after we checked, which would mean X=2, Te=0.002001. *If* that edge arrived, we would see V = (2-1)/(0.002001-0.000456) = 647 edges/second. This is greater than the previous (initial) V of 0, so report that V = 0 still. Ts=0.003000 X=2 Te=0.002456 New datapoint! V = (2-1)/(0.002456-0.000456) = 1/0.002 = 500 edges/second. New datapoints (unlike upper bound estimates) force updating V, so report V = 500, which is the correct value for this thought experiment. Ts=0.004000 X=2 Te=0.002456 No new datapoint. The upper-bound V would result in a datapoint X=3 Te=0.004001, for V = (3-2)/(0.004001-0.002456) = 647 edges/second. That's higher than the previously reported velocity, so report the previous velocity instead, V = 500. Ts=0.005000 X=3 Te=0.004456 New datapoint! V = (3-2)/(0.004456-0.002456) = 1/0.002 = 500. New datapoints force updating V, so report (again) the correct value of 500 edges/second. Things could go on like above indefinately, and it would always report V=500. Let's say instead that the encoder stops moving at this time. True V is now 0. All future readings of the encoder counter will have the current datapoint of X=3 and Te=0.004456 Ts=0.00600 X=3 Te=0.004456 No new edge, estimate upper bound V = 647 edges, report old V = 500. Ts=0.00700 X=3 Te=0.004456 No new edge, upper bound V = (4-3)/(0.007001-0.004456) = 393. Report V = 393. Ts=0.008000 X=3 Te=0.004456 No new edge, report V = (4-3)/(0.008001-0.004456) = 282. I'll stop there, but the reported velocity decays towards zero, until you hit some timeout and give up and report V = 0. In hm2, this timeout is controlled by the encoder.XX.vel-timeout parameter. I think you can see how this system works well with both slower and faster encoder velocities across a great range, and how it reacts quickly to changes in velocity. Without the encoder counter reporting Te, the driver has to use Ts for the delta-T in the velocity estimation (just like the ddt HAL component does). The golden nugget of insight here is: The edge timestamping done by the encoder counter removes the servo period from the velocity estimation, replacing it with more information from the actual encoder hardware, and that removes the greatest source of quantisation error. -- Sebastian Kuzminsky -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
Re: [Emc-users] ilowpass filter
Tom wrote: Thanks Jon I get the feeling you were responding to John K's comments more than my own... Yes, at least mostly. But, I really have found this excessive high-frequency effect on the D term to be a real problem when tuning my own servo systems. I am pretty sure that most servos that use EMC's PID as is have to suffer from the same thing to some extent. My own analog velocity servo drives on my Bridgeport have a softer rolloff in the velocity loop, so they mostly handle it without great trouble, but it is not real hard to set up oscillations. My PWM drives are basically PWM-in voltage amplifiers with no filtering at all, and I have had a LOT of trouble getting stable response under all conditions. With insanely high encoder resolution I can make them work pretty well, but I really can't tell somebody else how to tune them, because I don't really know how **I** do it - I just kind of feel my way and eventually get a response I can live with, but I know it would be better with a bit more damping. But, if I turn D up any higher, it becomes unstable. There obviously is a phase shift somewhere in the system, I have a good idea it is from electrical through the motor to mechanical, and then back from the encoder. But, I don't really have a tool to quantify it. (For analog servo amps, I have a really fancy Schlumberger Dynamic Signal Analyzer that can crank out the tabular form of a Bode plot from any control loop system. But, that instrument won't work on a system where everything is digital.) It would be REALLY cool to work up a little HAL component that could excite a servo loop at various frequencies and examine the response, in amplitude and phase. still I will take that as an invitation to attend the Fest in May ;-) Oh, if you can make it, it is a MUST!!! for anyone interested in EMC. Jon -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
