help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: control package, can't simulate complex systems


From: GoSim GoSim
Subject: Re: control package, can't simulate complex systems
Date: Sun, 14 Jun 2020 23:09:09 +0200

 
 
 
Sent: Wednesday, June 10, 2020 at 6:40 PM
From: "Doug Stewart" <doug.dastew@gmail.com>
To: "GoSim GoSim" <GoSim@mail.com>
Cc: "Nicholas Jankowski" <jankowskin@asme.org>, "Help GNU Octave" <help-octave@gnu.org>
Subject: Re: control package, can't simulate complex systems
 
 
On Tue, Jun 9, 2020 at 7:37 PM GoSim GoSim <GoSim@mail.com> wrote:
 
Thanks for the matlab test and pictures, I will create a bug report if I can upload your pictures without registering. I have the same behaviour in Octave.
 
Sent: Wednesday, June 10, 2020 at 12:37 AM
From: "Nicholas Jankowski" <jankowskin@asme.org>
To: "GoSim GoSim" <GoSim@mail.com>
Cc: "Help GNU Octave" <help-octave@gnu.org>, "Doug Stewart" <doug.dastew@gmail.com>
Subject: Re: control package, can't simulate complex systems
I don't have matlab so I can't check if it is supposed to be like this.
 
 
running those lines in Matlab 2020a: 
>> q=tf([  -1.46668928632582  38.5234944088261  -1023.42433722006  18055.8729050165  -275471.128598611  3680685.32154243  -40413629.6869944  433109318.542883  -3699840188.09672  32827566143.7738  -225798332168.488  1689921426466.71  -9494747382069.7  60613579740811.5  -278626623858487  1.52747193482069e+15  -5.6883783399098e+15  2.69067309068308e+16  -7.92226372994905e+16  3.25360727881732e+17  -7.2059792475876e+17  2.61175754638012e+18  -3.8909506684981e+18  1.31637705830625e+19  -9.12640045084024e+18  3.78290213329238e+19  1.41630594163597e+19  5.02932079881115e+19  1.29547036349465e+20  1.05983336007477e+19  2.43633391646665e+20  -1.31208497581345e+19  1.04713601706961e+20  7.83465823853832e+18  ],[  1  17.1698120499521  542.934121038049  7294.98595152311  126155.971925398  1377306.37948524  16829405.6386297  152789570.438515  1448656865.6342  11095921096.5808  85365123037.7488  556372911296.259  3555399791580.02  19799716986834.5  106353561602035  506292672690482  2.29624277698132e+15  9.31618125768562e+15  3.56349262092232e+16  1.22398996473335e+17  3.92373264437545e+17  1.12860046096021e+18  2.99632129507514e+18  7.09934073973815e+18  1.53176948230893e+19  2.91760427412351e+19  4.97010301791734e+19  7.33491370510952e+19  9.42777562297368e+19  1.01604047339533e+20  9.12510568398965e+19  6.44576522525933e+19  3.46367980244933e+19  1.23309424846899e+19  2.4145011614912e+18  ]);
>> step(q)
>> figure
>> lsim(q,ones(1,1001),[0:.01:10])
 
produces the attached figures in MatlabControlOutput.png.  All steps complete 'very quickly'. 
 
Trying to do the same in Octave 5.2.1 and Control 3.2.0, the step command takes a very long time, several times producing the following warning any time I bring focus to the plot window:
 
warning: opengl_renderer: data values greater than float capacity.  (1) Scale data, or (2) Use gnuplot
 
same thing with the lsim command.
 
if I try:
 
>> graphics_toolkit('gnuplot')
 
it runs, but the outputs are as attached in OctaveControlGnuplot.png
 
 
so, there does seem to be some issue here. 
 
 
 
 
try 
step(ss(q))
 
 
--
DASCertificate for 206392
 
 
 
I just wanted to thank the person who wrote to try what is written below, i can't see your e-mail because i'm not on the list, i only saw it on nabble.
was annoying me that i didn't thank someone who helped me. Thank you, thank you.
 
"
pkg load signal
[a,b,c,d] = tf2ss(q);
step(ss(a,b,c,d))
 
representing high order systems in transfer function form is not a good idea in general.
The pzmap of 'q' showed that the poles are all in the left half plane. That hinted that the coefficients are still probably good; which is why I tried converting to state space.
 
If possible in your application, avoid transfer functions where the order is very high.
"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]