Repository navigation
ENH: deadtime support for TransferFunction #628
Description
Activity
Hi Marco, that would be awesome -- for TransferFunctions and also ideally StateSpace Systems too. This is something the library is really in need of. I agree that pade doesn't really cut it for many things.
My take is that what you suggest is the right track: For or time-response systems like
initial_response,step_response, andimpulse_response, it should be possible to just shift the input by the time delay. Forfrequency_responseand__call__it might be possible to simply add phase lag for the frequency response functions.forced_responseis a bit more complicated but it might be possible to store a past history of inputs and then linearly interpolate between them as needed. I believe this is how simulink implements time delays.Reacted by Ben GreinerHi Sawyer! Great then, I'll start working on it to see what I can do.
Thanks for the tips! Those ideas sound great :)
Reacted by Ben GreinerThe JuliaControl toolbox supports a DelayLtiSystem type (which we would probably call
DelayLTI) that you might look at for some ideas.Reacted by Marco Miretti and Bill TubbsThis would obviously be great enhancement. I saw this 7-year-old question on stack overflow asking for a continuous time delay system and so far the only answer is by Carl Sandrock using his group's library Python code for Multivariable Feedback Control.
From Carl Sandrock's answer to above SO question, it looks like they have added a
deadtimekeyword to their transfer function class and use anInternalDelayclass to convert a regular system to one that can handle internal delays:H = tf(1, 1, deadtime=0.1) G = InternalDelay(G)Just finished watching the ControlSystems.jl (Julia) presentation at CDC'21. They talked briefly about their implementation of delay systems and write about it in their paper. They are using a linear fractional transformation (LFT) state space representation for delays, which seems like a nice way to go.
Hey all, I'd like to echo the utility of this update. In one of my projects I'm using the python-control library and simulating transport delays using Pade approximants gives inconsistent results depending on the behavior of the system. Specifically the delays often show an oscillatory behavior. Not super sure how a transport delay like the one present in MATLAB Simulink or other similar programs would be implemented, but it seems you folks have a few ideas!
Reacted by Cory SimonHi all, I've just provided a draft PR for supporting continuous delay sytems, building on LFT representation, and a minimal DDE solver based on scipy solve_ivp. I've compared the simulations with julia ConstrolSystem.jl and it works, but will need some refinement. Overall, I think it's a solid start.
Background
It would be quite useful to have real (
e^(- deadtime * s)) deadtime in transfer functions. When multiple operations are performed on them, (decoupling methods for mimo systems, multiloop control tunning strategies like BLT, etc.),pade's approximation doesn't quite cut it (the orders grow too much and the computation comes out imprecise).Proposal
I would like to try adding this feature for the
tfand most of it's methods. Of course, keeping retro-compatibility.I wonder if prior approaches have been done in order to address this problem, and if there is a big roadblock in sight. That would be nice to know.