On Mon, 7 Feb 2011 22:20:27 -0800 (PST)
"Peter C. Wallace" wrote:
> Right. I think I figured out the problem. We are using negative P,I,D
> terms which works fine except it breaks the integral freezing logic
> in the PID comp. This is for a velocity PID loop for spindle control.
> I blame Matt...
Jeff Epler wrote:
> On Wed, Feb 09, 2011 at 07:25:27AM -0800, Peter C. Wallace wrote:
>
>> The point is that its a convenient way to reverse the output polarity
>> especially if the output device does not have this ability.
>>
>
> Do we currently have a pwm/dac driver shipping with emc tha
On Wed, Feb 09, 2011 at 07:25:27AM -0800, Peter C. Wallace wrote:
> The point is that its a convenient way to reverse the output polarity
> especially if the output device does not have this ability.
Do we currently have a pwm/dac driver shipping with emc that doesn't let
you set a negative outpu
On Wed, 9 Feb 2011, Yi-Shin Li wrote:
> Date: Wed, 9 Feb 2011 22:21:45 +0800
> From: Yi-Shin Li
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] pid bug
>
> On Tue, Feb 8, 2011 at 11:26 PM, Peter C. Wallace wrote:
>
>>
>>
On Tue, Feb 8, 2011 at 11:26 PM, Peter C. Wallace wrote:
>
> --- if ( ( tmp1 * pid->limit_state ) <= 0.0 ) {
>
> +++ if ( ( tmp1 * pid->limit_state * pid->igain ) <= 0.0 ) {
>
> Is a possible patch if negative PID values are to be allowed
>
> Based on the diagram of this page
(http://en.wikipedia
--- if ( ( tmp1 * pid->limit_state ) <= 0.0 ) {
+++ if ( ( tmp1 * pid->limit_state * pid->igain ) <= 0.0 ) {
Is a possible patch if negative PID values are to be allowed
Peter Wallace
Mesa Electronics
--
The ultimate
On Tue, 8 Feb 2011, Hsuyao Tsai wrote:
> Date: Tue, 8 Feb 2011 12:43:47 +0800
> From: Hsuyao Tsai
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] pid bug
>
> Hi Peter,
>
> Theoratically the limit_state would not cause integrator fr
Hi Peter,
Theoratically the limit_state would not cause integrator freezing.
Use the following code block again.
/* if output is in limit, don't let integrator wind up */
if ( ( tmp1 * pid->limit_state ) <= 0.0 ) {
/* compute integral term */
*(pid->error_i) += tmp1 * periodfp;
}
We woul
Date: Fri, 04 Feb 2011 11:48:17 -0500
>> From: Dave
>> Reply-To: EMC developers
>> To: EMC developers
>> Subject: Re: [Emc-developers] pid bug
>>
>> I usually see anti-windup schemes for PID loops based on the output limits.
>>
>> When the output hits
On Fri, 4 Feb 2011, Dave wrote:
> Date: Fri, 04 Feb 2011 11:48:17 -0500
> From: Dave
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] pid bug
>
> I usually see anti-windup schemes for PID loops based on the output limits.
>
> When
I usually see anti-windup schemes for PID loops based on the output limits.
When the output hits 100%, don't allow the error to increase the I value
since the output is limited to 100% anyway.
That eliminates windup.
The car analogy is: If your foot is already on the floor what is the
point o
I have an idea for a better patch to the pid comp than simply removing the "if
limit_state" conditional around the integrator. I understand the benefit of
"freezing" the integrator when the output is saturated. This is useful for
good PID loop behaviour when a large step command is received: th
On Thu, 3 Feb 2011 19:49:05 +
andy pugh wrote:
> Is 8i20.N.N.amp-enable being set at the same time as pid-enable?
Yes, they're all in one net in the .hal file:
net amp-enable 8i20.enable hm2_5i20.0.8i20.0.0.amp_enable
<...>
### IF cfg==*h* uncomment these lines
net amp-enable pid.0.enabl
On 3 February 2011 19:21, Matt Shaver wrote:
> I would, but when the the bldc component is loaded with a "cfg"
> parameter that includes "h" (you have Hall sensors), there is no
> bldc.0.init-done pin created.
In that case there is no init stage, so that isn't the cause of the
integral windup.
I
On Thu, 3 Feb 2011, Matt Shaver wrote:
> Date: Thu, 3 Feb 2011 14:21:49 -0500
> From: Matt Shaver
> Reply-To: EMC developers
> To: [email protected]
> Subject: Re: [Emc-developers] pid bug
>
> On Thu, 3 Feb 2011 10:46:03 -0800 (PST)
> "Peter C.
On Thu, 3 Feb 2011 10:46:03 -0800 (PST)
"Peter C. Wallace" wrote:
> OK the first thing thats needed is to connect pid.n.enable to
> bldc.0.init-done so the integrator does not wind up during motor
> initialization.
I would, but when the the bldc component is loaded with a "cfg"
parameter that in
On Thu, 3 Feb 2011, Matt Shaver wrote:
> Date: Thu, 3 Feb 2011 13:18:03 -0500
> From: Matt Shaver
> Reply-To: EMC developers
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [Emc-developers] pid bug
>
> On Wed, 2 Feb 2011 21:08:09 -0800 (
On Wed, 2 Feb 2011 21:08:09 -0800 (PST)
"Peter C. Wallace" wrote:
> It was pretty surprising. I was using Matt Shavers velocity mode test
> hal file with halrun, so the effect was not masked by a FE as it
> would be under EMC. If we had any integral gain and put enough load
> on the motor that it
On Wed, 2 Feb 2011, Jon Elson wrote:
> Date: Wed, 02 Feb 2011 22:27:17 -0600
> From: Jon Elson
> Reply-To: EMC developers
> To: EMC developers
> Subject: Re: [Emc-developers] pid bug
>
> Peter C. Wallace wrote:
>> It looks like the integral term has some fun
Peter C. Wallace wrote:
> It looks like the integral term has some funny problems in the pid comp.
>
> The symptom is that when the integral term causes the output to saturate, and
> there is no integral limit or the integral limit is > MaxOutput/Igain it
> never recovers, and ends up driving in
It looks like the integral term has some funny problems in the pid comp.
The symptom is that when the integral term causes the output to saturate, and
there is no integral limit or the integral limit is > MaxOutput/Igain it
never recovers, and ends up driving in one direction regardless of the e
21 matches
Mail list logo
