Module tuning_math 

Tuning-constant math: turns a completed MRFT run’s peaks/troughs/switch-times into Kp/Ti/Td for all three ResponseLevels, then into the PID parameters in whatever representation/units a DCS/PLC template expects.

Pure port of TuningConstantsCalc (measure_oscillation + calculate_tuning_result) and CalculatePIDparameters (calculate_pid_parameters), split the same way the legacy app split them. Like core-mrft, this module does no I/O and reads no clock — every timestamp it reasons about is already inside switch_times, taken from a completed crate::mrft::Action::Complete.

Structs

CheckedTuningResult

A checked result for one response level.

OpcWriteValues

The literal values to write back to the DCS/PLC for one PidParameters — see opc_write_values. Distinct from PidParameters because integral/derivative may differ from the calculated values for controller types that don’t use one or both terms.

Oscillation

Oscillation measurements derived from a completed MRFT run, before applying any response-level-specific Kp multiplier. Pure port of the period/frequency/amplitude portion of TuningConstantsCalc.

PidParameters

The final PID parameters in a DCS/PLC template’s own representation (e.g. proportional band instead of gain, reset rate instead of reset time, seconds instead of minutes) — pure port of CalculatePIDparameters, applied to one TuningResult.

TuningMathCompat

Legacy-bug replication flags for this module, mirroring crate::mrft::MrftCompat’s pattern (see core-bug-register). Every field defaults to false: the fixed, correct behavior.

TuningResult

Calculated Kp/Ti/Td for one ResponseLevel, before DCS-specific unit conversion. Pure port of the Kp/Ti/Td portion of TuningConstantsCalc. ti_minutes/td_minutes are identical across all three response levels for a given run — only kp varies — since C2/C3 don’t vary by response level (see crate::constants::lookup).

Enums

TuningResultInvalidReason

Why a calculated response-level result was marked invalid.

TuningResultStatus

Whether a calculated response-level result contains values that are safe to use.

Functions

calculate_all

The top-level entry point: computes the PID parameters for all three response levels from a completed MRFT run, in one call. Composes measure_oscillation (once) with calculate_tuning_result and calculate_pid_parameters (once per ResponseLevel). Pure port of MRFTcompletionActions’s call into TuningConstantsCalc + CalculatePIDparameters.

calculate_all_checked

Checked counterpart to calculate_all.

calculate_pid_parameters

Converts a TuningResult into the PID parameters a specific DCS/PLC template expects. Pure port of CalculatePIDparameters.

calculate_tuning_result

Applies one ResponseLevel’s tuning constants to an Oscillation, producing Kp/Ti/Td. Pure port of the per-response-level portion of TuningConstantsCalc.

measure_oscillation

Computes oscillation measurements (period, frequency, PV amplitude) from a completed MRFT run’s recorded peaks/troughs/switch-times. Pure port of TuningConstantsCalc’s period/frequency/amplitude math — everything before the per-response-level Kp/Ti/Td split, which calculate_tuning_result handles.

opc_write_values

The literal integral/derivative values to write back to the DCS/PLC for one PidParameters, given the controller type the run was configured for. Pure port of the controller-type-conditional part of WritePIDparametersToOPCtags — proportional is always pid.proportional, so this only exists to decide integral/derivative, which ControllerType::P/ControllerType::Pi algorithms don’t use: