Re: [Emc-users] odd PID tuning problem
Jake Anderson wrote: Currently I am running a P of ~3 D of .01 FF1 0 FF2 .03 FF2 .0001 Why is the P term so low? Can you raise it? I know the Mesa is different from my boards, but I use P values from 50 to 4000 or so. I think this is the real reason you have different error at different speed. Jon -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On 9 July 2010 17:47, Jon Elson el...@pico-systems.com wrote: Why is the P term so low? Perhaps his error is in mm? -- atp -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On Fri, 2010-07-09 at 11:47 -0500, Jon Elson wrote: Jake Anderson wrote: Currently I am running a P of ~3 D of .01 FF1 0 FF2 .03 FF2 .0001 Why is the P term so low? Can you raise it? I know the Mesa is different from my boards, but I use P values from 50 to 4000 or so. I think this is the real reason you have different error at different speed. Jon Hi Jake, My Z axis on a cinci contourmaster (BP sized) mill is as follows; 5i20- 7i33 - 1525BR Servo Dynamics amp in torque mode - Keling KL-34-180-90 - 2:1 - 10 mm ball screw. P = 600 I = 1000 D = 1.3 FF0 = 0 FF1 = 0 FF2 = 0 This gives decent but not phenomenal following error. ~ 0.0005. When I tried running the amp at max (7 A) it screamed at me. I only got stability when I backed off the current. It will still do 80 ipm so no problem. I should revisit the Z tuning with the idea of raising the P some more. I initially tried tuning with large FF1 values but as I decreased it the following error got progressively better. There is almost no difference between FF1 = -0.03 and 0.0 so I left it at zero. Dave -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
Andy Pugh wrote: On 9 July 2010 17:47, Jon Elson el...@pico-systems.com wrote: Why is the P term so low? Perhaps his error is in mm? Yes, sure, that would scale it down by 25.4, but 3 still seems to be VERY low. Jon -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On 8 July 2010 02:43, Chris Radek ch...@timeguy.com wrote: One step more complicated is to have dual pid loops, a torque loop inside a velocity. I'm not sure what you'd use for torque/current feedback, though. Normally that's current sensing in hardware, and you have no equivalent that I can see. I _think_ what you would have in such a dual PID loop would be a loop closed by velocity but controlled by duty-cycle (and motor torque is at least approximately directly proportional to PWM duty cycle) driven by a loop closed by position and controlled by velocity. ie the Axis position goes into the first loop and the error becomes a velocity demand for the second loop, where the velocity error becomes a torque/current demand. Adding current feedback would probably be a third loop in the chain. But take everything I say with a pinch of salt, I have only tuned one servo axis ever, and that only well enough to prove out a motor driver. -- atp -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On Thu, 8 Jul 2010, Jake Anderson wrote: Date: Thu, 08 Jul 2010 10:32:50 +1000 From: Jake Anderson ya...@vapourforge.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: [Emc-users] odd PID tuning problem We have converted our mill to CNC and EMC2 and all is fairly well. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JakeAndRussells Having a little trouble getting the tuning just so however. I set P and D to get an acceptable step response and all is fairly well. however when I have the table moving at a set speed there is a fixed offset, IE the table lags .01 or so behind. so I use FF1 to null that out so the ferror hovers around 0 and it all looks really good. Unfortunatly when I change that cruise speed (g1 F200 vs G1 F100 say) the ferror goes up, and I start either leading or lagging the set point. I can tune to hover around 0 error at any given speed, but as the speed changes I start getting error again. Any tips? Do you have enough integral term to correct errors during cruise? the integral term is slow (so can have a lot of gain without becoming unstable) but should be set fast enough to track velocity. Does you motor power supply droop when doing a fast move? With a bare Hbridge (Voltage mode), FF1 is needed to compensate for the motors back EMF, so that without any other PID terms being applied, the H bridge output voltage matches the motors back EMF at any velocity. Once back EMF is compensated for, you have a ~torque (current) mode drive: IMotor = (VBridgeFF1-VMotorBEMF+VBridgePID)/RMotor where VBridgeFF1-VMotorBEMF ~=0 One problem with this scheme however is that the FF1 back EMF compensation depends on the power supply voltage (since Hbridge Vout = VSupply*PWMVal). Torque mode amplifiers depend on high bandwidth velocity feedback, so you may need to raise the sample rate to get fast enough velocity feedback (D term) Better velocity feedback will allow your P and D terms to be increased, improving following error. When tuning a torque mode drive, at least in my experience, you have to ratchet P and D up alternately while checking the step response. Higher D allows higher P (and higher P allows higher I). Dont know if EMCs PID loop has been modified to allow an external (not DPosition/DT) velocity input. If the PID component had a velocity input, you could use HostMot2s encoder velocity output as a better velocity feedback term than the (crunchy) DPosition/DT Peter Wallace Mesa Electronics -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
Chris Radek wrote: I see you're using bare H bridges which means you don't have a velocity loop. I think this problem with FF1 is because of that, and it is a fairly fundamental problem with a torque-mode setup. My PWM servo system is very similar, essentially a voltage-mode amplifier commanded by PWM output. So, PWM duty cycle commands a voltage to the motor. Back-EMF is pretty dominant, so it works like a velocity servo with low gain, and therefore low stiffness. But, I find that FF1 works VERY well to correct for the finite gain. I only have experience with this on my minimill, and I have a lot of reduction between motor and table - 4:1 belt reduction and 16 TPI screws. I can imagine a case where the motor is less well matched where motor resistance would tend to bog it down at higher speeds. I seem to recall from your pic that the motors were directly driving the leadscrews, and they did not look to be very large motors. Once you have FF1 correcting the cruise error, then a TINY amount of FF2 fixes the spikes during deceleration. I have 128,000 encoder counts/inch on my minimill, and can usually get the error down to about .5, or about 6 encoder counts, during acceleration, and even less during cruise, up to above 60 IPM. Jon -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
Andy Pugh wrote: I _think_ what you would have in such a dual PID loop would be a loop closed by velocity but controlled by duty-cycle (and motor torque is at least approximately directly proportional to PWM duty cycle) driven by a loop closed by position and controlled by velocity. If the motor had high resistance and no back-EMF, this might be true, where voltage out of the drive is proportional to current. In general, the motors have fairly low resistance, and the motor's back-EMF is pretty dominant, so voltage out is closely proportional to SPEED, not torque. This totally changes the way the servo loop operates. So, current is proportional to the difference between back-EMF and applied voltage. I = (Vout - bEMF) / R Jon -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
Peter C. Wallace wrote: Does you motor power supply droop when doing a fast move? With a bare Hbridge (Voltage mode), FF1 is needed to compensate for the motors back EMF, I believe FF1 compensates mostly for motor resistance, not back EMF. Back EMF turns the servo motor into a velocity servo with finite gain, ie. speed roughly follows applied voltage. Torque mode amplifiers depend on high bandwidth velocity feedback, so you may need to raise the sample rate to get fast enough velocity feedback (D term) Better velocity feedback will allow your P and D terms to be increased, improving following error. When tuning a torque mode drive, at least in my experience, you have to ratchet P and D up alternately while checking the step response. Higher D allows higher P (and higher P allows higher I). One of the big problems with using encoders for velocity feedback is that they are doubly quantized. First, position is quantized by the lines in the encoder. Then, position is sampled at regular intervals. So, every servo_period, some number of encoder counts occur, and there is an unavoidable jitter. For instance, when moving at an average velocity of 1.5 encoder counts/sampling interval, the velocity will be measured as alternating counts of 1/2/1/2/1 etc. This appears to the PID calculation as a constant fluctuation over a 2:1 speed range every alternate sample. Therefore, applying too much D term magnifies this fluctuation. As speeds increase, the percentage fluctuation becomes smaller. Moving to a higher sampling rate moves the worst-case speed to a higher velocity, but doesn't really fix the problem. It CAN, however, move the resulting 1/2f frequency up to where the servo drive can no longer pass such a frequency. At the default EMC2 1 KHz sampling rate, the worst case produces a 500 Hz ripple in the PWM output. If you move the servo rate up to 5 KHz, the ripple would move up to 2.5 KHz. Dont know if EMCs PID loop has been modified to allow an external (not DPosition/DT) velocity input. If the PID component had a velocity input, you could use HostMot2s encoder velocity output as a better velocity feedback term than the (crunchy) DPosition/DT This is pid2, but it still doesn't solve the quantization noise in the encoder-derived velocity. The one thing that really helps is to have insanely high encoder counts per user unit. This allows the PID to have lots of response to actual movement through the D term, but to reduce the sensitivity to the +1/-1 velocity quantization effect. I'm using 128,000 quadrature counts/inch on my minimill. This works pretty well, if I had just 5000 counts/inch, I think the tuning would be a lot poorer. Jon -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
Jon Elson wrote: [snip] Dont know if EMCs PID loop has been modified to allow an external (not DPosition/DT) velocity input. If the PID component had a velocity input, you could use HostMot2s encoder velocity output as a better velocity feedback term than the (crunchy) DPosition/DT This is pid2, but it still doesn't solve the quantization noise in the encoder-derived velocity. Actually, it does. The Mesa encoder counter has a timestamp of when the last encoder edge was seen, so the velocity is based on accurate (to some fraction of a microsecond) time sampling, not the servo loop rate (with its associated jitter). The same method is also used in the software encoder module, though the jitter will be much worse since the base thread is also subject to interrupt latency issues. - Steve -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
Stephen Wille Padnos wrote: Jon Elson wrote: This is pid2, but it still doesn't solve the quantization noise in the encoder-derived velocity. Actually, it does. The Mesa encoder counter has a timestamp of when the last encoder edge was seen, so the velocity is based on accurate (to some fraction of a microsecond) time sampling, not the servo loop rate (with its associated jitter). The same method is also used in the software encoder module, though the jitter will be much worse since the base thread is also subject to interrupt latency issues. OK, I wasn't sure that this ALSO solved the problem at higher speeds, it is clear the time stamp solves the problem at the lowest speeds. I was under the impression that when the velocity was above one count per servo cycle, the velocity estimation was phased out. Oh well, wrong again! (My HARDWARE has this, but the driver doesn't use it, yet!) Jon -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On 08/07/10 11:43, Chris Radek wrote: On Thu, Jul 08, 2010 at 10:32:50AM +1000, Jake Anderson wrote: We have converted our mill to CNC and EMC2 and all is fairly well. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JakeAndRussells ... Unfortunatly when I change that cruise speed (g1 F200 vs G1 F100 say) the ferror goes up, and I start either leading or lagging the set point. I can tune to hover around 0 error at any given speed, but as the speed changes I start getting error again. Any tips? Yes but beware they're all half-baked. I see you're using bare H bridges which means you don't have a velocity loop. I think this problem with FF1 is because of that, and it is a fairly fundamental problem with a torque-mode setup. In hand-wavey terms, a full velocity mode servo amp has a commanded velocity (output of emc's pid in our case) and actual velocity (from a tachometer) and it uses the difference between the two to determine the torque/current to apply to the motor. It seems like you can fake this up by using the mesa encoder's velocity output as your pretend velocity feedback. Use sum2 (one gain negative) to calculate the difference between your pid output and your velocity feedback. Pick your scales carefully so everything matches up. Use this resulting difference to drive your pwmgen. I haven't tried this and the whole idea came out of a late-night chat session with Kim K. Unfortunately I can't find the archive of it. I'd be thrilled to hear whether this gives you a stable loop and whether it tunes up better. Please do keep notes and report back if you try it. I'll have to catch you up on IRC and see if you can hand hold my way through setting that up lol (I'm Valen there btw) One step more complicated is to have dual pid loops, a torque loop inside a velocity. I'm not sure what you'd use for torque/current feedback, though. Normally that's current sensing in hardware, and you have no equivalent that I can see. ok well I have no hope of that lol. Simpler is to leave your pid as-is and try using I instead of FF1. If you can increase your I by a lot and still keep the loop stable, you'll get correct following at any (steady) speed. The tradeoff is sloppy settling at speed changes, like at the beginning and ending of moves. I can add a bunch of I and get it to be pretty good but things where it plunges then starts cutting wind up with an overshoot and the like. Currently I am running a P of ~3 D of .01 FF1 0 FF2 .03 FF2 .0001 or so (these vary for each axis) -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On 08/07/10 13:01, dave wrote: On Wed, 2010-07-07 at 20:43 -0500, Chris Radek wrote: On Thu, Jul 08, 2010 at 10:32:50AM +1000, Jake Anderson wrote: We have converted our mill to CNC and EMC2 and all is fairly well. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JakeAndRussells ... Unfortunatly when I change that cruise speed (g1 F200 vs G1 F100 say) the ferror goes up, and I start either leading or lagging the set point. I can tune to hover around 0 error at any given speed, but as the speed changes I start getting error again. Any tips? Yes but beware they're all half-baked. I see you're using bare H bridges which means you don't have a velocity loop. I think this problem with FF1 is because of that, and it is a fairly fundamental problem with a torque-mode setup. In hand-wavey terms, a full velocity mode servo amp has a commanded velocity (output of emc's pid in our case) and actual velocity (from a tachometer) and it uses the difference between the two to determine the torque/current to apply to the motor. It seems like you can fake this up by using the mesa encoder's velocity output as your pretend velocity feedback. Use sum2 (one gain negative) to calculate the difference between your pid output and your velocity feedback. Pick your scales carefully so everything matches up. Use this resulting difference to drive your pwmgen. I haven't tried this and the whole idea came out of a late-night chat session with Kim K. Unfortunately I can't find the archive of it. I'd be thrilled to hear whether this gives you a stable loop and whether it tunes up better. Please do keep notes and report back if you try it. One step more complicated is to have dual pid loops, a torque loop inside a velocity. I'm not sure what you'd use for torque/current feedback, though. Normally that's current sensing in hardware, and you have no equivalent that I can see. Simpler is to leave your pid as-is and try using I instead of FF1. If you can increase your I by a lot and still keep the loop stable, you'll get correct following at any (steady) speed. The tradeoff is sloppy settling at speed changes, like at the beginning and ending of moves. Chris Hi all, I is not that I know anything about tuning torque mode. Just did one a few weeks ago. I started out like usual as for a tach/velocity mode tune. Not the best idea. Take a look at the parameters used on the Mazak conversion. ~/emc2/emc2-trunk/configs/demo_mazak/demo_mazak.ini or something close to that. Those values look pretty radical but it gives you an idea what is needed for tuning torque mode. Maybe try 1/20th or less of those values and see what happens. Pretty much you get it going with a reasonable P and then use I and D get stability and then increase everything in steps to get decent stiffness and response. That's not the problem though, it works ok except for the fixed offset that varies with speed. At least on my machine FF(n) didn't do much good and believe me I did try them. Linear scales on machines that are not really low in backlash can be a challenge. I got better results with encoders on the ballscrew. There is very little lash in the setup, we can't measure it because its less than our dialguages can measure. We are using .001mm scales. on the Z drive there is more and we notice that at low movement rates. The mill was a Cinci contourmaster with servos that had, and still does, about 0.003 backlash. In terms of tuning, linear glass scales, encoders on the servo motors then encoders on the ballscrews; encoders on the ballscrews being by far the easiest to tune. SEM MT30H4s with tachs. for X and Y and a torque mode amp for the Z. Hope this helps. Dave -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net
Re: [Emc-users] odd PID tuning problem
On Thu, Jul 08, 2010 at 10:32:50AM +1000, Jake Anderson wrote: We have converted our mill to CNC and EMC2 and all is fairly well. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JakeAndRussells ... Unfortunatly when I change that cruise speed (g1 F200 vs G1 F100 say) the ferror goes up, and I start either leading or lagging the set point. I can tune to hover around 0 error at any given speed, but as the speed changes I start getting error again. Any tips? Yes but beware they're all half-baked. I see you're using bare H bridges which means you don't have a velocity loop. I think this problem with FF1 is because of that, and it is a fairly fundamental problem with a torque-mode setup. In hand-wavey terms, a full velocity mode servo amp has a commanded velocity (output of emc's pid in our case) and actual velocity (from a tachometer) and it uses the difference between the two to determine the torque/current to apply to the motor. It seems like you can fake this up by using the mesa encoder's velocity output as your pretend velocity feedback. Use sum2 (one gain negative) to calculate the difference between your pid output and your velocity feedback. Pick your scales carefully so everything matches up. Use this resulting difference to drive your pwmgen. I haven't tried this and the whole idea came out of a late-night chat session with Kim K. Unfortunately I can't find the archive of it. I'd be thrilled to hear whether this gives you a stable loop and whether it tunes up better. Please do keep notes and report back if you try it. One step more complicated is to have dual pid loops, a torque loop inside a velocity. I'm not sure what you'd use for torque/current feedback, though. Normally that's current sensing in hardware, and you have no equivalent that I can see. Simpler is to leave your pid as-is and try using I instead of FF1. If you can increase your I by a lot and still keep the loop stable, you'll get correct following at any (steady) speed. The tradeoff is sloppy settling at speed changes, like at the beginning and ending of moves. Chris -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] odd PID tuning problem
On Wed, 2010-07-07 at 20:43 -0500, Chris Radek wrote: On Thu, Jul 08, 2010 at 10:32:50AM +1000, Jake Anderson wrote: We have converted our mill to CNC and EMC2 and all is fairly well. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JakeAndRussells ... Unfortunatly when I change that cruise speed (g1 F200 vs G1 F100 say) the ferror goes up, and I start either leading or lagging the set point. I can tune to hover around 0 error at any given speed, but as the speed changes I start getting error again. Any tips? Yes but beware they're all half-baked. I see you're using bare H bridges which means you don't have a velocity loop. I think this problem with FF1 is because of that, and it is a fairly fundamental problem with a torque-mode setup. In hand-wavey terms, a full velocity mode servo amp has a commanded velocity (output of emc's pid in our case) and actual velocity (from a tachometer) and it uses the difference between the two to determine the torque/current to apply to the motor. It seems like you can fake this up by using the mesa encoder's velocity output as your pretend velocity feedback. Use sum2 (one gain negative) to calculate the difference between your pid output and your velocity feedback. Pick your scales carefully so everything matches up. Use this resulting difference to drive your pwmgen. I haven't tried this and the whole idea came out of a late-night chat session with Kim K. Unfortunately I can't find the archive of it. I'd be thrilled to hear whether this gives you a stable loop and whether it tunes up better. Please do keep notes and report back if you try it. One step more complicated is to have dual pid loops, a torque loop inside a velocity. I'm not sure what you'd use for torque/current feedback, though. Normally that's current sensing in hardware, and you have no equivalent that I can see. Simpler is to leave your pid as-is and try using I instead of FF1. If you can increase your I by a lot and still keep the loop stable, you'll get correct following at any (steady) speed. The tradeoff is sloppy settling at speed changes, like at the beginning and ending of moves. Chris Hi all, I is not that I know anything about tuning torque mode. Just did one a few weeks ago. I started out like usual as for a tach/velocity mode tune. Not the best idea. Take a look at the parameters used on the Mazak conversion. ~/emc2/emc2-trunk/configs/demo_mazak/demo_mazak.ini or something close to that. Those values look pretty radical but it gives you an idea what is needed for tuning torque mode. Maybe try 1/20th or less of those values and see what happens. Pretty much you get it going with a reasonable P and then use I and D get stability and then increase everything in steps to get decent stiffness and response. At least on my machine FF(n) didn't do much good and believe me I did try them. Linear scales on machines that are not really low in backlash can be a challenge. I got better results with encoders on the ballscrew. The mill was a Cinci contourmaster with servos that had, and still does, about 0.003 backlash. In terms of tuning, linear glass scales, encoders on the servo motors then encoders on the ballscrews; encoders on the ballscrews being by far the easiest to tune. SEM MT30H4s with tachs. for X and Y and a torque mode amp for the Z. Hope this helps. Dave -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
