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
The following models a discrete-time delay $y(k) = u(k-d)$. At $t = 2$, a step in the input occurs from 0 to 1, it should take $d$ seconds for the step to appear in the output, instead, it takes $d-1$ seconds, and the behavior for $d=0$ and $d=1$ are identical.
The problem is exposed by the following analysis
We use d discrete-time state variables to store the delayed signal. Let's assume d = 1 for simplicity
At time t, the input to the discrete partition changes (in the example t = 2 and the change is from 0 to 1)
At time t, the c2d variable is thus changed by c2d_obs(integrator.u, p, t)
At time t, the disc update stores the changed signal value in the discrete-time state variable which is used as memory
At time t, the d2c variable is set to the value of the discrete-time state variable. This is the incorrect step, the discrete update correctly represents x(k) = f(x(k-1), c2d(k), but the d2c update in this case has to output the old discrete-time state, not the new, since the Hold operator was applied to the delayed input signal input(k-d).
There are two ways to handle this issue
The compiler can realize that an additional state variable is required in order to keep the old value in memory until the d2c pass is run. Right now, the compiler correctly handles cases when the d2c involves state variables at time k, but not at k-d for some positive d.
Split the d2c update in two, one that is run before the discrete affect, and one after. This would reduce the number of state variables, but adds complexity instead.
MWE
using ModelingToolkit, Plots, OrdinaryDiffEq
using ModelingToolkit: D_nounits as D
using ModelingToolkit: t_nounits as t
k =ShiftIndex(Clock(t, 1))
@mtkmodel DelayModel begin@variablesbegininput(t) =0delay(t) =0x(t) =0end@structural_parametersbegin
d
end@equationsbegin
input ~ (t >=2)
delay(k) ~input(k-d)
D(x) ~ (-x +Hold(delay))/1e-3# Simple fast lowpass filter to be able to show a continuous-time output variableendendplot()
for d =0:3@mtkbuild m =DelayModel(; d)
prob =ODEProblem(m, [m.delay(k-3)=>0, m.delay(k-2)=>0, m.delay(k-1)=>0], (0.0, 10.0))
sol =solve(prob, Tsit5(), kwargshandle = KeywordArgSilent)
plot!(sol, lab="d = $d")
enddisplay(current())
the plot shows the result for a few different values of $d$
The text was updated successfully, but these errors were encountered:
The following models a discrete-time delay$y(k) = u(k-d)$ . At $t = 2$ , a step in the input occurs from 0 to 1, it should take $d$ seconds for the step to appear in the output, instead, it takes $d-1$ seconds, and the behavior for $d=0$ and $d=1$ are identical.
The problem is exposed by the following analysis
d
discrete-time state variables to store the delayed signal. Let's assumed = 1
for simplicityt
, the input to the discrete partition changes (in the examplet = 2
and the change is from 0 to 1)t
, the c2d variable is thus changed byc2d_obs(integrator.u, p, t)
t
, thedisc
update stores the changed signal value in the discrete-time state variable which is used as memoryt
, thed2c
variable is set to the value of the discrete-time state variable. This is the incorrect step, the discrete update correctly representsx(k) = f(x(k-1), c2d(k)
, but thed2c
update in this case has to output the old discrete-time state, not the new, since theHold
operator was applied to the delayed input signalinput(k-d)
.There are two ways to handle this issue
d2c
pass is run. Right now, the compiler correctly handles cases when thed2c
involves state variables at timek
, but not atk-d
for some positived
.d2c
update in two, one that is run before the discrete affect, and one after. This would reduce the number of state variables, but adds complexity instead.MWE
the plot shows the result for a few different values of$d$
The text was updated successfully, but these errors were encountered: