
From:  Aidan Macdonald 
Subject:  Re: octavecontrol: stepinfo 
Date:  Mon, 9 Feb 2015 21:21:44 0800 
> <stepinfo.m>
On 10.02.2015, at 04:20, Aidan Macdonald <address@hidden> wrote:
>
> On Mon, Feb 9, 2015 at 5:36 AM, Doug Stewart <address@hidden> wrote:
>
>
> On Mon, Feb 9, 2015 at 12:30 AM, Aidan Macdonald <address@hidden> wrote:
>
>
> On Sun, Feb 8, 2015 at 7:59 PM, Doug Stewart <address@hidden> wrote:
>
>
> On Sun, Feb 8, 2015 at 10:30 PM, Doug Stewart <address@hidden> wrote:
>
>
> On Sun, Feb 8, 2015 at 10:29 PM, Aidan Macdonald <address@hidden> wrote:
>
> On Sun, Feb 8, 2015 at 6:54 PM, Doug Stewart <address@hidden> wrote:
>
>
> On Sun, Feb 8, 2015 at 9:48 PM, Aidan Macdonald <address@hidden> wrote:
>
>
> We always bottom post on this list
>
>
>
> Aidan Plenert Macdonald
> 4178 Decoro Street, San Diego, CA 92122
> Cell: 805 418 0174
>
> On Sun, Feb 8, 2015 at 6:31 PM, Doug Stewart <address@hidden> wrote:
>
>
> On Sun, Feb 8, 2015 at 8:41 PM, Aidan Macdonald <address@hidden> wrote:
> Hi,
>
> I wrote some code for stepinfo in the octavecontrol package. I tried to match the guidelines found here.
>
> I attached the code. It doesn't match the Matlab standard perfectly, but I was wondering how much I should do before submitting it. I wrote it to take in one system and give the results specified in http://www.mathworks.com/help/control/ref/stepinfo.html.
>
> I was also a little concerned with the math I did. I couldn't find a better explanation of the various parameters than Matlab's website specified. That said, I wrote it and compared it to a few examples using my universities Matlab and they mostly match.
>
> Let me know what I should do to improve it. I am very new to the open source contributing scene, let me know what I should do to help.
>
> Enjoy,
>
> Aidan Plenert Macdonald
> 4178 Decoro Street, San Diego, CA 92122
> Cell: 805 418 0174
>
> _______________________________________________
> Helpoctave mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/helpoctave
>
>
>
>
>
> I just did a quick read through and I see that for slope you did time over y_yalue
> I am sure that it should be the other way rise over run
>
> I will do more checking later
> Doug
> 
>
>
> Thanks for looking. No, I think the slope is right. I am using is to calculate the true times below given the error in the difference from the ideal 90% and 10% voltage. The slope is in units seconds/volts. With an error from the ideal in volts (the error come from discretization of the signal), I linearly approximate the true value.
> 
> OK you are using a different definition than calculus.
>
> Like I said I will do more checking.
>
>
>
>
> DAS
>
> Sorry, Does this look better? I am using Gmail
>
> Aidan Plenert Macdonald
> 4178 Decoro Street, San Diego, CA 92122
> Cell: 805 418 0174
>
> Yes very good :)
>
>
>
> Your calculation of Settling Time is my next concern.
>
> There are many definitions for settling time and I was wondering what you are using?
> I see the ST=.02 but then you multiplied it to ypeak.
> and you have yavg of the tail etc.
>
> What are you really doing?
>
> Doug
>
>
> Perhaps you could point me to a better definition, but I was using what Matlab said here that the response has settled when the error abs(yfinal  y(t)) has reached ST times the peak value. So I use convolution to average the y values over a span. I picked an arbitrary averaging width, perhaps you know a better one.
>
> I then take the use average in place of y(t), which I argue in the case of oscillating signals is required. I attempt to minimize the absolute value of the error minus the ST*ypeak value. The second abs(...) is so the min function isn't taking negative error differences.
>
> I take the minimum value of the error  ST*ypeak to be the closest point to settled, and use that corresponding time value.
>
> I looked around, including 2 books I have for more precise definition in terms of the step functions response. Wikipedia, from what I saw, only had it is a function of variables in the system function, but I want a numerical definition.
>
> Thanks.
>
> Aidan Plenert Macdonald
> 4178 Decoro Street, San Diego, CA 92122
> Cell: 805 418 0174
>
>
>
>
> I think the 2% settling time is defined to be :
> The last time the signal was outside the 2% range of the final value.
> So I don't agree with matlab's definition of being outside of 2% of the peek.
>
>
> Now as to your software even if we stay with matlab's definition, your software does not get the same results as Matlab's example.
>
> from matlab's example:
>
> sys = tf([1 5],[1 2 5 7 2]);
> S = stepinfo(sys,'RiseTimeLimits',[0.05,0.95])
>
>
> S =
> RiseTime: 7.4454
> SettlingTime: 13.9378
> SettlingMin: 2.3737
> SettlingMax: 2.5201
> Overshoot: 0.8032
> Undershoot: 0
> Peak: 2.5201
> PeakTime: 15.1869
>
>
>
> from your software:
> >> sys = tf([1 5],[1 2 5 7 2]);
> >> S = stepinfo(sys,'RiseTimeLimits',[0.05,0.95])
> yfinal = 2.5002
> ysettle = 0.47566
> settling_ind = 79
> S =
>
> scalar structure containing the fields:
>
> RiseTime = 5.1696
> SettlingTime = 39.866
> SettlingMin = 2.1908
> SettlingMax = 2.5192
> Overshoot = 0.0076091
> Undershoot = 0.012105
> Peak = 2.5192
> PeakTime = 15.381
>
>
> matlab has a settling time of 13.9 sec.
> and your software has 39.8 sec.
>
>
> I have taught this method for second order systems:
>
>
> d=poly([ 14j, 1+4j])
> n=[17]
> sys1=tf(n,d)
> a=roots(d)
> ar=real(a(1))
> [Y, T, X] =step(sys1);
> fv=Y(end)
> gg=fv*(1exp(ar .*T));
> plot(T,gg)
> hold on
> step(sys1)
>
> From the graph you can see that the settling time of the first order curve gives a good smooth function, that can be used as the settling time for the second order system. We then went with 4 or 5 time constants of the first order curve as or settling time.
>
> The definitions given at the start of my discussion both give very discontinuous results.
> That is  a small change in gain can give a jump in the settling time, because the last place that it was outside the 2% will be a different minor peak .
>
>
> I know that there are many definitions of settling time and that for this software we want a numerical approach.
> So my suggestion is to do something like Matlab but do it to 2% of the final value not the peak value .
>
> Lukas Reichlin is the maintainer of the control pkg. so he has the final say as to which way to go.
>
> Doug
>
>
> I like your definition of Settling Time, but I think it would be better to see what Lukas wants. I implemented your definition, if I understood it correctly, and it is attached.
>
> settling_ind = h  find(abs(fliplr(y)  yfinal) >= abs(ST*yfinal), 1);
> settling_time = t(settling_ind);
>
> My original idea to help avoid grabbing the minor minima and maxima for the settling time was to do a convolution average (low pass filter). I figured that that filter would flatten out the signal and give a more stable response. That said, I don't think a single filter would be good for all signals, so perhaps designing one on the fly for a given system based on the frequency of the ringing (high frequency oscillation).
>
> Again, these are ideas, but I think Lukas should say what he wants.
>
> Aidan Plenert Macdonald
> 4178 Decoro Street, San Diego, CA 92122
> Cell: 805 418 0174
>
Gentlemen,
Thank you for your work, Aidan  and your inputs, Doug! I think we need a definition (and a corresponding implementation) which delivers results close to Matlab's stepinfo. Otherwise, people will complain and write bug reports as they consider Octave as a "Matlab without a price tag".
Therefore, please find some "interesting" examples (LTI models) and test them against Matlab (and maybe Scilab). Please also consider corner cases like unstable systems. In case of significant differences between Octave and Matlab, don't forget to compare the step plots. If the step plots already differ, you found a serious bug in Octave's step function.
Once the formulae are working as expected, I can help you with options and error handling, converting examples into test blocks, Texinfo stuff and proper Octave coding style.
BTW: As I don't have access to Matlab at the moment, please send me its results.
Hope this helps and best regards,
Lukas
[Prev in Thread]  Current Thread  [Next in Thread] 