Order Track — Control Systems/Vibration
Control_Systems/Vibration/Order_Track · 2 input / 2 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Order Track
Control Systems / Vibration
The amplitude of one or more shaft orders against time – MATLAB's
ordertrack on its Vold-Kalman path – over a running
window of the last W samples. Order k is the vibration component riding at
k·rpm÷60 hertz; the filter finds, over the window, the complex
envelope X for which 2·Re(X·ejθ) best matches
the signal while X stays smooth, with
θ[n] = (2πk÷60fs)·Σrpm taken from the speed
port. What is published is the size of that envelope for the window's centre
sample: peak = |2X|, rms = peak÷√2 or
power = peak²÷2, on a linear or a decibel scale.
Ports
- x – the sampled vibration signal, scalar: one channel and its own window.
- rpm – the shaft speed at the same instant, in revolutions per minute, scalar.
- mag – the order magnitudes, [K, 1] with one row per entry of Order List, in the units Amplitude and Scale select. Row k is the value at the sample (W−1)÷2 ticks ago, not at this tick.
- rpm out – the shaft speed of that same sample, [1, 1]: the
magnitudes are plotted against it, and it is delayed by the same
(W−1)÷2 samples so the pair belongs together. It is
ordertrack's second output.
Parameters
- Order List – the orders to track, a vector of up to eight positive numbers; they need not be whole. Defaults to [1 2]. K is its length and sets the height of mag.
- Bandwidth (Hz) – how fast the tracked amplitude is allowed to change, read as the filter's smoothness weight exactly as MATLAB reads it, r = (1.58·fs÷2πbw)2. A narrow bandwidth rejects a neighbouring order and follows a run-up slowly; a wide one does the opposite. Positive; defaults to 40. See the Notes for how it must be sized against the window.
- Window Length – W, the record the filter solves over: an ODD whole number from 17 to 513, odd so that the window has a centre. Defaults to 129. Every generated core carries W-sized arrays and W sine-cosine pairs per order per sample, which is what the upper limit is about.
- Sample Rate (Hz) – fs, the rate the two signals were sampled at: the bandwidth and the order frequencies are in hertz through it. Positive; defaults to 1000.
- Amplitude – what the magnitude means,
ordertrack's own three:- RMS – peak÷√2, the default there and here.
- Peak – the envelope itself, |2X|.
- Power – peak²÷2.
- Scale – Linear (the default) or dB: 20·log10 of an rms or peak magnitude, 10·log10 of a power one. A window in which the order is exactly absent is −∞ on this scale, as it is in MATLAB.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. The filter's matrix does not contain the data, so it is solved ONCE at export time and the core carries its W solution weights as numbers; each sample is then the window's cumulative speed, one sine-cosine pair per sample per order, one accumulation and one square root. All six settings are structural, so re-export after changing any of them.
⚠ The three HDL targets run those loops in simulation-only real arithmetic, quantizing only at the port boundaries: a Q16.16 datapath carries neither the sine and cosine of an accumulated phase, nor a decibel, nor a window of a thousand samples. They are not offered as synthesizable.
Simulink bridge
None (Support::None). ordertrack is a Signal
Processing Toolbox function and that toolbox ships no Simulink library, so there is
no path a diagram could name; the bridge reports this block rather than dropping it
silently, and it therefore has no parity testbench. Code export verification still
covers it across all ten languages.
Notes
- Stateful, and discrete by nature
(
setDiscreteOnlyBlock(true)): two shift registers of W samples, zero at the start of the run, so the first W−1 samples of a run are a window that is still filling. - ⚠ Both outputs lag by (W−1)÷2 samples – 64 at the default window. The least-squares envelope is unconstrained at the edge of its own record, so the window's newest sample is not a usable estimate: measured against the whole-record answer on a 600 to 1800 rpm sweep, the window's centre converges to it (9.0e−4 at (W−1)·bw÷fs = 5.1, 7.0e−7 at 10.2) while its newest sample stays at 1.0 to 2.4 on a true amplitude of 1.4 whatever the window length.
- ⚠ Size the window against the bandwidth. The agreement above is governed by (W−1)·bw÷fs: about 1e−3 at 5, 1e−6 at 10, 1e−12 at 20 – so a narrow bandwidth needs a long window, and W < 5·fs÷bw is a window that cannot hold the filter's own response. The defaults sit at 5.1.
- ⚠ MATLAB's
ordertrackonly runs this filter in one of its two syntaxes. Given the speed as a plain vector it takes the resampling path instead – an order map, read at the nearest order row – and refuses the bandwidth argument entirely. The Vold-Kalman path is the matrix-speed-and-index syntax, and it is the one this block implements; the resampling path belongs to the RPM-Order Map block. - Orders are tracked independently of one another, which is
ordertrack's default (Decouplefalse). The coupled solve, which separates orders that cross, needs a K·W system whose matrix DOES contain the data, so it is not offered here. - The filter order is fixed at 1, as
ordertrackfixes it. Order Waveform, whose counterpart exposes it, has it as a parameter. - An order whose frequency passes fs÷2 aliases, exactly as it would in MATLAB, which refuses such an order list outright; the speed arrives on a port here, so it cannot be checked at configuration time.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Vibration/Order_Track |
| family | Control_Systems/Vibration |
| solver environment class | ICoreBlock_0_Control_Systems_1_Vibration_2_Order_Track |
| source | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Vibration/Order_Track/ICoreBlock_0_Control_Systems_1_Vibration_2_Order_Track.cpp |
| header | src/ICoreBlocks/ICoreBlockLibrary/Blocks/Control_Systems/Vibration/Order_Track/ICoreBlock_0_Control_Systems_1_Vibration_2_Order_Track.h |
| default size on canvas | 140 × 76 px |
| ports at insert | 2 in, 2 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | x |
| 2 | in | ICoreDouble | rpm |
| 3 | out | ICoreDouble | mag |
| 4 | out | ICoreDouble | rpm out |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
| Config variable | Default | Simulink parameter |
|---|---|---|
Order List | [1 2] | not crossed |
Bandwidth (Hz) | 40 | not crossed |
Window Length | 129 | not crossed |
Sample Rate (Hz) | 1000 | not crossed |
Amplitude | RMS%~%Peak%~%Power~~RMS | not crossed |
Scale | Linear%~%dB~~Linear | not crossed |
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::None |
| Simulink path | — |
| port-count rule | PortsParam::None |
SampleTime parameter | yes |
| deliberately not crossed | Order List, Bandwidth (Hz), Window Length, Sample Rate (Hz), Amplitude, Scale |
Caveat (shown to the user): ordertrack is a Signal Processing Toolbox function and that toolbox ships no Simulink library, so there is no path a diagram could name; the Vold-Kalman order filter has no counterpart in any shipped block library
Catalog contract: src/ICoreBlocks/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Order Track -- MATLAB's ordertrack on its Vold-Kalman path, over a running window The same filter Order Waveform runs -- the Vold-Kalman least-squares envelope of the last W samples, read at the window's centre -- published as a MAGNITUDE instead of a waveform:
peak = |2 X|, rms = peak / sqrt(2), power = peak^2 / 2 dB = 20 log10(peak or rms), 10 log10(power)
which is ordertrack's
AmplitudeandScalearithmetic, spelled in its order. The second output carries the shaft speed of the sample the magnitude belongs to, which is ordertrack's second return value and what a user plots the track against.⚠ ordertrack HAS TWO PATHS AND THIS BLOCK IS ONE OF THEM, which is measured rather than assumed.
ordertrack(x, fs, rpm, orderlist)with rpm a VECTOR does not run the Vold-Kalman filter at all: it calls rpmordermap and reads the map's nearest order row -- and it REFUSES the Bandwidth, SegmentLength and Decouple arguments in that syntax ("These name-value arguments can be specified only when estimating order magnitudes with the Vold-Kalman filter"). The Vold-Kalman path is reached only through the matrix-rpm-plus-refidx syntax,ordertrack(x, fs, [rpm rpm], orderlist, 1, ...), and that is the path this block is. The resampling path is the RPM-Order Map block's subject, not this one.Measured against R2026a on that path (fs = 1000, a 600-to-1800 rpm sweep, order 2):
- ordertrack's rms output is exactly abs(vk amplitude)/sqrt(2), its peak output exactly
that amplitude and its power dB output exactly 10*log10(amp^2/2) -- all three to 0, which is what fixes the arithmetic above.
- ordertrack fixes the filter order at 1 and does not expose it, so neither does this
block; Order Waveform, whose MATLAB counterpart does expose it, has the parameter.
- The windowed solve is MATLAB's solve on the same window to 3.2e-14 (filter order 1),
while MATLAB's own default preconditioned-conjugate-gradient tolerance of 1e-3 puts its answer 1.2e-6 to 1.5e-4 from the exact one.
- The window's CENTRE converges to the whole-record answer as the window grows
(9.0e-4 at (W-1)*bw/fs = 5.1, 7.0e-7 at 10.2); its newest sample does not converge at all (1.0 to 2.4 against a true amplitude of 1.4), which is why the block reads the centre and carries (W-1)/2 samples of latency.
The rest -- why the matrix is a constant of the configuration, and what each target emits -- is on the family's ICoreVoldKalmanSupport, which both blocks share.
Sample results#
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | 0 … 0.03438 |
ramp | Ramp: slope 1 from t = 0 | 0 … 0.06533 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | 0 … 0.2533 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | 3.463e-6 … 0.08956 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category dynamic · sample time 0.1 · 60 steps · commit 6b0471a23bd6163d7d7f33f764df08a614c2b6b8 · produced by docsSample --out <folder> --blocks Scalar_Root_Find Scalar_Bounded_Minimization Order_Waveform Order_Track RPM_Frequency_Map RPM_Order_Map --steps 60 · data docs/generated/samples/Control_Systems__Vibration__Order_Track.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).