bugGNU Octave - Bugs: bug #43263, control package: @lti/minreal may...

 
 

bug #43263: control package: @lti/minreal may generate inaccurate result

Submitted by:  None
Submitted on:  Sat 20 Sep 2014 03:42:54 AM UTC  
 
Category: Octave Forge PackageSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Inaccurate Result
Status: FixedAssigned to: None
Originator Name: Saul MtakulaOriginator Email: -unavailable-
Open/Closed: ClosedRelease: other
Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 09 Jun 2015 04:44:47 PM UTC, comment #4:

Thanks for reporting, I've pushed a changeset as proposed:

https://bitbucket.org/paramaniac/control/commits/9cab4686fc041bb579360985bcbafca2bc4a1f97

Lukas Reichlin <paramaniac>
Sun 31 May 2015 07:03:24 PM UTC, comment #3:

A workaround has been proposed, but this may still be something that the control package maintainer would be willing to take a look at, adding in cc.

I can at least confirm different step response between the original example and Endre's modification to use a state-space model.

Mike Miller <mtmiller>
Project Administrator
Tue 23 Sep 2014 04:18:24 AM UTC, comment #2:

Thanks Endre
I have always had to go state space for multivariable problems in Octave but did not anticipate that would be necessary for SISO problems. Anyways your solution worked well (and it is by using Scilab I was able to get the correct solution first time). Octave is great because it also runs on Android but one needs to be extra careful as demonstrated here.

Anonymous
Mon 22 Sep 2014 12:01:02 PM UTC, comment #1:

I guess the problem is near to singularity somewhere. Scilab signals this at least.
I changed the code a bit at calculation of Gff. Thus the resulting plot looks as expected.

Endre Kozma <theorizer>
Sat 20 Sep 2014 03:42:54 AM UTC, original submission:

Control toolbox 2.6.5 refers. Code for the m file is shown below. The step response after manipulations of the transfer functions in the code should be a damped oscillation. The response obtained is not correct; my suspicion is on the minreal command because when it is omitted the step response is unbounded. It could be the feedback command is the problem.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by paramaniac (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by mtmiller
  • -unavailable- added by theorizer (Posted a comment)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 17 Jun 2015 03:02:34 PM UTCmtmillerOpen/ClosedOpen=>Closed
    Wed 17 Jun 2015 03:02:33 PM UTCmtmillerStatusConfirmed=>Fixed
    Sun 31 May 2015 07:03:24 PM UTCmtmillerSeverity3 - Normal=>1 - Wish
      Item GroupNone=>Inaccurate Result
      StatusNone=>Confirmed
      Release3.8.1=>other
      Operating SystemMicrosoft Windows=>Any
      SummaryMinreal (control toolbox) may generate inaccurate result=>control package: @lti/minreal may generate inaccurate result
      Carbon-Copy-=>Added paramaniac

    Back to the top


    Powered by Savane 3.1-cleanup1