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

 
 

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

Submitted by:  None
Submitted on:  Thu 19 Aug 2021 01:33:04 PM UTC  
 
Category:  Octave Forge 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

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

( 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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
  •  

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

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-19 hwe Carbon-Copy- => Added holger.weiss@continental.com

    Back to the top


    Powered by Savane 3.6