bugGNU Octave - Bugs: bug #61061, [octave forge] (control) margin()...

 
 

bug #61061: [octave forge] (control) margin() and step() giving wrong results

Submitter:  None
Submitted:  Thu 19 Aug 2021 01:33:04 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  None Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 5.2.0
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 20 Aug 2021 07:31:58 PM UTC, comment #7: 

I forgot to mention that you have to adjust the gain since zpkdata does not return the static gain but the gain of a transfer function in the form


       (s - z1)(s - z2)...(z - zm)
G = k -----------------------------
       (s - p1)(s - p2)...(z - pm)


Torsten Lilge <ttl>
Group Member
Fri 20 Aug 2021 03:42:05 PM UTC, comment #6: 

Using zpkdata and zpk, you can also test for and cancel the poles and zeros at zero.

Torsten Lilge <ttl>
Group Member
Fri 20 Aug 2021 03:23:42 PM UTC, comment #5: 

Without having tested it with your example, you could use zpkdata() to get zeros, poles, and gain. After removing the leftmost poles from the pole list you can use zpk() to define the new systems.

Torsten Lilge <ttl>
Group Member
Fri 20 Aug 2021 06:30:23 AM UTC, comment #4: 

Thanks for confirmation of the bug.

Leaving out the zeros for the s^1 and s^2 coefficients will be difficult, because the TF is generated automatically.

The bode(ax_0) phase is plotted from 360deg on and not from 0deg as expected.
Interestingly the margin(ax_0) phase is plotted correctly and the phase margin is calculated correct.

How can I apply your workaround of ignoring the stable poles of higher than 20 times the dominant pole ?

Is there any function or workaraund to do that ?


HWe <hwe>
Thu 19 Aug 2021 07:25:12 PM UTC, comment #3: 

Oops, missing comma. The bode command should read


bode (ax_eps, ax_0, logspace(5,35,1000))


Torsten Lilge <ttl>
Group Member
Thu 19 Aug 2021 07:21:31 PM UTC, comment #2: 

Thanks for the report. I can confirm the issue. After some debugging it turns out that the call to _sl_td04ad_, a wrapper to the SLICOT Fortran function TD04AD returns empty A, B and C matrices and D = 0. Passing a much lower tolerance to _sl_td04ad_ leads to a non emtpy state space representation but not to a reasonable step response.

When running

bode (ax_eps, ax_0 logspace(5,35,1000))

one can see that this is a very special system which is approximated by ax_0 for lower frequencies. I guess that the poles at 10^31 rad/s are somehow messing up the frequency range calculation in margin() and the state space representation in step(). A solution might be to just ignore stable poles that are more than 20 decades faster than the dominant poles.

Btw: The phase in bode() is only correct (no offset) when removing the zero coefficients for s^1 and s^0 in numerator and denominator.

Torsten Lilge <ttl>
Group Member
Thu 19 Aug 2021 01:49:33 PM UTC, comment #1: 

This is to create the "eps" transfer function:

>> denum = [7.384e-161, 8.987e-129, 3.342e-97, 3.697e-66, 1.25e-35, 9.206e-28, 1.943e-20, 9.427e-14, 1.085e-07,0,0];
>> num=[6.027e-84,3.668e-52,2.48e-21,9.427e-14,1.085e-07,0,0];
>> ax = tf(num,denum)


This is to create the "0" transfer function:

>> num=[2.479e-21,9.427e-14, 1.085e-07,0,0];
>> denum=[1.25e-35,9.205e-28,1.943e-20,9.427e-14, 1.085e-07,0,0];
>> ax = tf(num,denum)



Anonymous
Thu 19 Aug 2021 01:33:04 PM UTC, original submission:  

I am using the package “control” provided by Octave Forge to investigate the performance of a PLL transfer function.

The transfer function is derived from loop filter components R1 to R4 and C1 to C4. For lower order PLL transfer functions, some components e.g. R3/R4 and C3/C4 are not used - this means I can either set them to “0” or to “eps” (the smallest possible value).

I prefer to set them to “eps” to avoid any division by zero in future calculations.
The resulting transfer function with components set to “eps” looks like:


pll0.TF_cl_fbdiv_out
Transfer function ‘ans’ from input ‘u1’ to output …
6.027e-84 s^6 + 3.668e-52 s^5 + 2.48e-21 s^4 + 9.427e-14 s^3 + 1.085e-07 s^2
y1: -----------------------------------------------------------------------------------------------------------------------------------------------
7.384e-161 s^10 + 8.987e-129 s^9 + 3.342e-97 s^8 + 3.697e-66 s^7 + 1.25e-35 s^6 + 9.206e-28 s^5 + 1.943e-20 s^4 + 9.427e-14 s^3 + 1.085e-07 s^2


The functions margin(pll0.TF_cl_fbdiv_out) gets me wrong numbers and the step(pll0.TF_cl_fbdiv_out) function also does not shows any reasonable transient results.

But when setting the unused components to “0”, the transfer function results in:

>>pll0.TF_cl_fbdiv_out
Transfer function ‘ans’ from input ‘u1’ to output …
2.479e-21 s^4 + 9.427e-14 s^3 + 1.085e-07 s^2
y1: ----------------------------------------------------------------------------
1.25e-35 s^6 + 9.205e-28 s^5 + 1.943e-20 s^4 + 9.427e-14 s^3 + 1.085e-07 s^2


And the margin(pll0.TF_cl_fbdiv_out) gets me the expected numbers (PM=135deg@4.21rad/s) and the step(pll0.TF_cl_fbdiv_out) function also shows reasonable transient results.

Questions:
Is this a bug in the control package that it cannot handle those small values (e.g. 8.9e-129) in the “eps” transfer function ?
Is there a way to “cleanup” the transfer function parameter values to avoid such wrong results ?

Why can the margin() and step() functions not properly handle the transfer function ?

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by hwe
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-19 hwe Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code