Repository navigation
Unexpected behavior for a system defined using zpk #1067
Description
I been scratching my head about whats going on with a very simple system.
Defining the system using tf yields results as expected. But defining the system through zpk does not.
Description
I intend to define the next system:
G(s) = K
---------------
(s+2)*(s+2/3)
With K adjusted for a ts=1 second. Very straight forward.
Reproduction
This is my code for zpk:
import control as ct
import numpy as np
import matplotlib.pyplot as plt
K = 10.314
G = ct.zpk([], [-2, -2/3], K)
T = ct.feedback(G)
ct.step_response(T).plot()
ct.step_info(T)
{'RiseTime': np.float64(0.0),
'SettlingTime': nan,
'SettlingMin': np.float64(-4.959514534383556e+52),
'SettlingMax': np.float64(8.010508330340013e+51),
'Overshoot': np.float64(9.04605979182796e+53),
'Undershoot': np.float64(5.600651440127666e+54),
'Peak': np.float64(4.959514534383556e+52),
'PeakTime': np.float64(5.180816459236604),
'SteadyStateValue': np.float64(0.8855245835956728)}
The result is not as expected. While defining the system through tf:
I = ct.tf([K], [1, 8/3, 4/3])
V = ct.feedback(I)
ct.step_response(V).plot()
ct.step_info(V)
{'RiseTime': np.float64(0.4186518350898263),
'SettlingTime': np.float64(2.5119110105389577),
'SettlingMin': np.float64(0.8127467853231765),
'SettlingMax': np.float64(1.118911703975943),
'Overshoot': np.float64(26.35435717033743),
'Undershoot': 0,
'Peak': np.float64(1.118911703975943),
'PeakTime': np.float64(0.9942981083383374),
'SteadyStateValue': np.float64(0.8855347207912633)}
Outputting both system definitions reveals they're the same. The transfer function is exactly the same. But I don't know what may be going on with the transfer object defined with zpk.
System info
I've installed the control package in a clean conda enviroment and using a jupyter notebook through VSCode.
Conda:
conda version : 23.1.0
conda-build version : 3.22.0
python version : 3.9.13.final.0
virtual packages : __archspec=1=x86_64__win=0=0
platform : win-64
Activity
murrayrm commentedon Nov 27, 2024
This same issue came up in #1062 and was fixed in #1064. The issue is that timebase in
zpkwas not being set correctly and so it was getting interpreted as a discrete time system.If you don't want to check out the latest main branch, you can fix the problem by changing the
zpkcall togereze commentedon Nov 27, 2024
Thank you for the help. I'm kind of ashamed I didn't found those issues when searching.