"Derivative of state '1' in block is not finite" how to fix in Simulink?

Illustration
tristinwued295 - 2026-06-17T19:08:25+00:00
Question: "Derivative of state '1' in block is not finite" how to fix in Simulink?

Why Does Simulink Show the Error 'Derivative of State '1' in Block Is Not Finite'? Complete Guide to Identifying the Cause and Resolving the Issue

Expert Answer

Profile picture of John Williams John Williams answered . 2026-06-17

The error "Derivative of state '1' in block ... is not finite" in Simulink usually means the simulation encountered Inf (infinity) or NaN (Not a Number) values feeding into an Integrator (or a block with internal states like Transfer Fcn). This often points to a singularity (e.g., division by zero), unstable system dynamics, bad initial conditions, or numerical issues.

Common Causes
- Division by zero or operations producing Inf/NaN (e.g., in Divide blocks, math functions, or denominators approaching zero).
- Unstable model (incorrect equations, positive feedback, or physically unstable system).
- Poor initial conditions (especially for Integrators or Transfer Fcn blocks).
- Solver step size too large (solver can't handle rapid changes or stiffness).
- Algebraic loops combined with the above.
- Issues common in power electronics, PV models, control systems with Transfer Fcn, etc.

Step-by-Step Fixes

1. Enable Inf/NaN Diagnostics (Best First Step)
   - Go to Configuration Parameters (Ctrl+E) → Diagnostics → Data Validity.
   - Set Inf or NaN block output to `error`.
   - Rerun the simulation. It will now pinpoint the exact block producing Inf/NaN (often upstream of the Integrator). Fix that block (e.g., avoid divide-by-zero).

2. Check for Division by Zero
   - Look for Divide blocks, reciprocals (`1/u`), or expressions where the denominator can hit zero.
   - Add protection: Use a Switch block to replace zero with a small epsilon (e.g., 1e-6) when the denominator is near zero.
   - Or refactor: Replace division with multiplication where possible.

3. Set Proper Initial Conditions
   - Double-click affected Integrator or Transfer Fcn blocks.
   - Provide realistic Initial condition values (not zero if inappropriate).
   - Use an IC (Initial Condition) block on signals if needed.

4. Solver Adjustments
   - Try a variable-step solver like `ode45` or `ode23tb` (stiff solver) first.
   - If using fixed-step, reduce Fixed-step size (e.g., from 0.001 to 1e-4 or smaller).
   - Tighten Relative tolerance and Absolute tolerance (e.g., 1e-6 or 1e-8).
   - For stiff systems, try `ode15s` or `ode23s`.

5. Handle Algebraic Loops
   - Insert a Memory block or Unit Delay to break the loop (at the cost of a small delay).
   - Or enable algebraic loop solving in Configuration Parameters, but this can be slower.

6. Other Quick Checks
   - Verify your model equations and implementation.
   - Add Saturation blocks to limit signals that might blow up.
   - Use Scope blocks or To Workspace to log signals and inspect values around the error time.
   - Try the Simulink Debugger (set breakpoint on Inf/NaN).
   - For models with Derivative blocks: Avoid them if possible (use proper transfer functions like `s/(tau*s+1)` instead) as they amplify noise/discontinuities.

Quick Debug Workflow
- Run with Inf/NaN diagnostic → Identify culprit block.
- Fix math/initial conditions → Adjust solver if needed.
- Rerun and check scopes.

If the system is physically unstable, the error is expected - you may need to redesign the controller or parameters.

This resolves the issue in most cases (especially division-by-zero or initial condition problems). Share more details about your model (e.g., screenshot of the subsystem or what blocks are involved) for more targeted help!


Not satisfied with the answer ?? ASK NOW

Get a Free Consultation or a Sample Assignment Review!