Variable Transport Delay — Control Systems/Continues

Variable Transport Delay

Control Systems / Continues

Carries the input along a path of fixed length whose contents move at a speed the delay port sets – a conveyor, a pipe, an extruder. The delay actually applied is the one that was in force while the material was travelling, not the one in force when it arrives:

∫ ds / d(s) = 1 over [t − τ(t), t], and y(t) = u(t − τ(t))

Read that as: material leaves once a full path length has been covered. The port value d is the transit time that would apply if the speed held steady, in seconds.

Its sibling, Variable Time Delay, reads the same port as "how stale the signal is right now" and reaches straight back by that much. Hold d constant and the two are identical; move it and they part company, because this block keeps faith with material already in flight and that one does not. Pick this one for anything physically transported, and that one when the delay is simply a staleness you are imposing.

Ports

• u – the transported signal, of any size [m,n]. This is what comes out delayed.
• d – the transit time in seconds, a scalar [1,1]. It applies to the whole signal, not per entry. It is clamped into [one sample, Maximum Delay (s)]: a conveyor cannot carry material at infinite speed, so a zero or negative transit time is raised to a single sample.
• Output – the delayed signal, the SAME size [m,n] as u.

Parameters

• Maximum Delay (s) – scalar, the longest transit the block can represent, in seconds. Defaults to 10, matching Simulink. It sets the depth of the transit line and bounds the search for the exit sample, so cost is proportional to it – at a 0.01 s rate the default is 1000 stored samples per signal entry. Set it to the longest transit you actually need rather than leaving headroom.
• Initial Output – scalar, what the block emits while nothing has yet completed the journey. Defaults to 0. The whole line is pre-filled with it, so a run starts from a defined state rather than from samples that were never taken.
• Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period. It is the resolution the transit is resolved to, the floor the transit time is clamped to, and the unit the maximum delay is counted in, so it is part of the arithmetic and not merely a schedule.

Code export

All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. Each carries the transit line and the per-step travel as its state and repeats the same backward search the simulation runs, so all ten agree with it and with each other. Only dt, the line depth and the transit clamp are baked in; the transit time is read from its port every tick.

The three HDL targets are simulation-only, in the same sense and for the same kind of reason as Recursive IIR. Two steps of this block do not belong in a fixed-point datapath: the per-step travel is dt / d, a division by a signal rather than a constant, and the exit sample is found by searching back along the line until a full path length has accumulated, so the work per tick grows with Maximum Delay (s) / dt. Both are ordinary in real arithmetic, so the generated cores carry the conveyor in real and quantize only at the port boundary. They simulate correctly and are deliberately not offered as synthesizable – keep the maximum delay tight regardless, since the search is unrolled to its depth. The sibling Variable Time Delay indexes the line directly instead of searching it, and exports a genuine fixed-point core.

Simulink bridge

Import and export, mapped to simulink/Continuous/Variable Transport Delay. "Maximum Delay (s)" to MaximumDelay, "Initial Output" to InitialOutput. The block always implies VariableDelayType = "Variable transport delay" – that parameter is the only thing distinguishing this Simulink block from Variable Time Delay, which shares its BlockType – and PadeOrder = 0, since the transit is realized as a true line and never as a Padé approximation. A Simulink block carrying either at a different value is reported on import rather than silently accepted.

This block has no SampleTime parameter in Simulink – it is a continuous block there – so "Sampling Time (s)" stays on the ICore side and does not cross.

Simulink's block is continuous: it interpolates both the stored signal and the crossing, and its solver may take steps this block does not. This one resolves the exit to the nearest stored sample. The two agree closely for a transit that is slow next to the sampling rate, and differ by up to half a sample where it is not.

Notes

• Stateful: Maximum Delay / dt + 1 past values of the signal port, plus the travel each of those steps accrued.
• Discrete by nature – the line advances one slot per sample, so the block always runs at its own rate rather than being pushed through a continuous solver's stages.
• The exit is resolved to the nearest stored sample, so sub-sample transit is not interpolated. Shorten the sampling time for finer resolution.
• The rounding is chosen so that a constant transit time gives exactly round(d / dt) samples – the same answer Variable Time Delay gives, so the two blocks agree wherever the mathematics says they must.
• Not linear in the state-space sense, and so deliberately carries no state space: a pure delay is the transcendental factor e^(−sτ), which no finite A/B/C/D expresses, and a time-varying one is not even time-invariant.