Re: [Emc-users] Scaling angular axis
John Kasunich wrote: > Don't use position-interpolated as feedback for position control. > Period. > > It even says that in the manual (I think). The problem is that as speed > approaches zero, and reverses, the interpolator keeps guessing at the > position until it sees the next encoder count. Those guesses will drive > the PID loop nuts. > Worse than just simple delay, a non-deterministic delay. Yeah, I was afraid of that. Jon -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
On Tue, 06 Oct 2009 10:25 +0100, "Andy Pugh" wrote: > 2009/10/6 Jon Elson : > > > I think the basic problem is that the encoder count is by necessity > > granular, > > and a lower INPUT_SCALE "magnifies" that granularity. > > Is 'encoder.X.position-interpolated' inappropriate in this situation? > Don't use position-interpolated as feedback for position control. Period. It even says that in the manual (I think). The problem is that as speed approaches zero, and reverses, the interpolator keeps guessing at the position until it sees the next encoder count. Those guesses will drive the PID loop nuts. The interpolated position output is intended mostly for threading, or any other application where some slave axis needs to track a master, and the master speed is more-or-less constant. There WILL be errors if/when the master speed changes abruptly or reverses, which a normal machine axis does all the time. Regards, John Kasunich -- John Kasunich jmkasun...@fastmail.fm -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
On Tue, 6 Oct 2009, Eric H. Johnson wrote:
> Date: Tue, 6 Oct 2009 11:19:11 -0400
> From: Eric H. Johnson
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "'Enhanced Machine Controller (EMC)'"
> Subject: Re: [Emc-users] Scaling angular axis
>
> John,
>
> Ok, got it. Fractional values for PID values just didn't seem right, but
> after closer inspection I see how it would work out that way. It wasn't that
> close to a divide by 360 however, more like divide by 60, at least for P. I
> and D were already too small to establish a meaningful proportionality.
>
> I had not really thought through the consequences of giving scaled, real
> world positions to the pid component's command and feedback pins, as opposed
> to raw encoder positions, as is the case with most other types of motion
> systems I have used.
>
> ISTM there are advantages to using raw encoder values rather than real world
> positions for PID tuning, in that it eliminates the effects of a number of
> variables such as gear ratio and acceleration (real world, as opposed to
> encoder counts per sec^2). It also means that the same motor / encoder pair
> should have the same, or very close to the same pid values, regardless of
> gearing or other scaling (linear vs. angular for example).
>
> Regards,
> Eric
Maybe there's a way to use the PWM scale to compensate for input scale so you
end up with commensurate PID values...
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
Andy Pugh wrote: > 2009/10/6 Jon Elson : > > >> I think the basic problem is that the encoder count is by necessity >> granular, >> and a lower INPUT_SCALE "magnifies" that granularity. >> > > Is 'encoder.X.position-interpolated' inappropriate in this situation? > I'm afraid I can't answer that. The systems I have worked on were done before the interpolated position or velocity estimation was used, and my drivers (blush) still don't have this feature. It certainly sounds like it might help, but when put into a servo loop, you have to be careful with anything that could introduce delay. Jon -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
John, Ok, got it. Fractional values for PID values just didn't seem right, but after closer inspection I see how it would work out that way. It wasn't that close to a divide by 360 however, more like divide by 60, at least for P. I and D were already too small to establish a meaningful proportionality. I had not really thought through the consequences of giving scaled, real world positions to the pid component's command and feedback pins, as opposed to raw encoder positions, as is the case with most other types of motion systems I have used. ISTM there are advantages to using raw encoder values rather than real world positions for PID tuning, in that it eliminates the effects of a number of variables such as gear ratio and acceleration (real world, as opposed to encoder counts per sec^2). It also means that the same motor / encoder pair should have the same, or very close to the same pid values, regardless of gearing or other scaling (linear vs. angular for example). Regards, Eric Write down the PID gains that work when the scale is 18400. Then, since you are dividing the scale by 360 to get 51.1, you should be able to also divide the gains by 360, and the resulting PID results should be identical. Take the old gains, divide by 360, and try them as a starting point for tuning. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
2009/10/6 Jon Elson : > I think the basic problem is that the encoder count is by necessity > granular, > and a lower INPUT_SCALE "magnifies" that granularity. Is 'encoder.X.position-interpolated' inappropriate in this situation? -- atp -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
John Kasunich wrote: > Write down the PID gains that work when the scale is 18400. Then, since > you are dividing the scale by 360 to get 51.1, you should be able to > also > divide the gains by 360, and the resulting PID results should be > identical. > Take the old gains, divide by 360, and try them as a starting point for > tuning. > This makes perfect sense to me, but I sure couldn't get it to work like that when I had the same situation. (This was several years ago, before some significant changes in EMC, so that experience may no longer apply.) I think the basic problem is that the encoder count is by necessity granular, and a lower INPUT_SCALE "magnifies" that granularity. So, a move of so many user units is fewer encoder counts, therefore the apparently flat periods between counts last longer, the counts are farther apart in TIME. The only possible fix to this is velocity estimation, if you are forced to use the raw encoder counts you can't get around the granularity. Jon -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
On Mon, 05 Oct 2009 12:42 -0400, "Eric H. Johnson" wrote: > Hi all, > > (For Peter) I think I found the main problem with tuning the X and Y > axes. I > used the registry values of the old system to set the initial parameters > for > EMC, and goofed on interpreting the accel parameters. In the Galil > world, > these are in encoder counts / sec^2 rather than units per sec^2. So > MAX_ACCELERATION was set much too high. After backing it off, I am > getting > much better results for the X and Y axis. > > My question now is about angular axes. While the X and Y axes have on > the > order of 5000 counts per inch, the rotational axis only has 51.1 counts > per degree (18400 per revolution) If I use 18400 for my INPUT_SCALE, I can > tune the axis rather easily. Of course in this case if I issue: > G1 A1 F50 It will turn 360 degrees rather than 1 degree. > > If I set INPUT_SCALE to 51.1 and adjust MAX_VELOCITY and MAX_ACCELERATION > proportionately, tuning again becomes much more difficult, ISTM due to > the granularity of the scaling. Write down the PID gains that work when the scale is 18400. Then, since you are dividing the scale by 360 to get 51.1, you should be able to also divide the gains by 360, and the resulting PID results should be identical. Take the old gains, divide by 360, and try them as a starting point for tuning. Regards, John Kasunich -- John Kasunich jmkasun...@fastmail.fm -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Scaling angular axis
Eric H. Johnson wrote: > My question now is about angular axes. While the X and Y axes have on the > order of 5000 counts per inch, the rotational axis only has 51.1 counts per > degree (18400 per revolution) If I use 18400 for my INPUT_SCALE, I can tune > the axis rather easily. Of course in this case if I issue: > G1 A1 F50 > It will turn 360 degrees rather than 1 degree. > > If I set INPUT_SCALE to 51.1 and adjust MAX_VELOCITY and MAX_ACCELERATION > proportionately, tuning again becomes much more difficult, ISTM due to the > granularity of the scaling. IOW, for the linear axes X and Y I get roughly > 5000 counts per machine unit (inch), but with the angular A axis I only get > 51 counts per machine unit (degree). Is this the correct way to set up an > angular axis? > Yup, I have observed the same problem with a Sherline rotary table and a 500 cycle/rev encoder directly on the motor shaft. The coarse resolution made it a problem to get good tuning. One thing is this low resolution makes the D term of the PID very dominant, so very small amounts of D work best. You can use FF1 and FF2 to improve the following error, but it won't do anything for stiffness. I think this might be a place where velocity estimation base on arrival time of the last encoder count is the only thing that will really help. Jon -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Scaling angular axis
Hi all, (For Peter) I think I found the main problem with tuning the X and Y axes. I used the registry values of the old system to set the initial parameters for EMC, and goofed on interpreting the accel parameters. In the Galil world, these are in encoder counts / sec^2 rather than units per sec^2. So MAX_ACCELERATION was set much too high. After backing it off, I am getting much better results for the X and Y axis. My question now is about angular axes. While the X and Y axes have on the order of 5000 counts per inch, the rotational axis only has 51.1 counts per degree (18400 per revolution) If I use 18400 for my INPUT_SCALE, I can tune the axis rather easily. Of course in this case if I issue: G1 A1 F50 It will turn 360 degrees rather than 1 degree. If I set INPUT_SCALE to 51.1 and adjust MAX_VELOCITY and MAX_ACCELERATION proportionately, tuning again becomes much more difficult, ISTM due to the granularity of the scaling. IOW, for the linear axes X and Y I get roughly 5000 counts per machine unit (inch), but with the angular A axis I only get 51 counts per machine unit (degree). Is this the correct way to set up an angular axis? Thanks, Eric -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
