You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 tf and 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.
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, and impulse_response, it should be possible to just shift the input by the time delay. For frequency_response and __call__ it might be possible to simply add phase lag for the frequency response functions. forced_response is 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.
From Carl Sandrock's answer to above SO question, it looks like they have added a deadtime keyword to their transfer function class and use an InternalDelay class to convert a regular system to one that can handle internal delays:
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!
Hi 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.
Activity
sawyerbfuller commentedon Jun 8, 2021
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.MarcoMiretti commentedon Jun 8, 2021
Hi Sawyer! Great then, I'll start working on it to see what I can do.
Thanks for the tips! Those ideas sound great :)
murrayrm commentedon Jun 9, 2021
The JuliaControl toolbox supports a DelayLtiSystem type (which we would probably call
DelayLTI) that you might look at for some ideas.billtubbs commentedon Aug 5, 2021
This 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.
billtubbs commentedon Aug 5, 2021
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:murrayrm commentedon Dec 16, 2021
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.
zetavB commentedon Apr 27, 2022
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!
MythasNauveili commentedon May 11, 2025
Hi 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.