CODEWITHSUNDEEP
matlabsimulink
Laurentiu Adrian Paraschiv
Laurentiu Adrian Paraschiv

Reputation: 11

Simulink model error

I've had to create the Simulink Diagram after this picture:

Diagram

My answer is this one:

Simulink image

I've gave some values to a, b and c (like 3, 4 and 5), but when I try to run it, it gives me the following warning:

Warning: The model 'ex2_2' does not have continuous states, hence Simulink is using the solver 'VariableStepDiscrete' instead of solver 'ode45'. You can disable this diagnostic by explicitly specifying a discrete solver in the solver tab of the Configuration Parameters dialog, or by setting the 'Automatic solver parameter selection' diagnostic to 'none' in the Diagnostics tab of the Configuration Parameters dialog

Warning: 'ex2_2/Unit Delay' is discrete, yet is inheriting a continuous sample time; consider replacing unit delay with a memory block. When a unit delay block inherits continuous sample time, its behavior is the same as the memory block. Unit delay block's time delay will not be fixed and could change with each time step. This might be unexpected behavior. Normally, a unit delay block uses discrete sample time. You can disable this diagnostic by setting the 'Discrete used as continuous' diagnostic to 'none' in the Sample Time group on the Diagnostics pane of the Configuration Parameters dialog box. "

and the output (scope) it's just a step signal...

I don't know where I'm wrong here.

Upvotes: 1

Views: 8558

Answers (2)

cyberdyne
cyberdyne

Reputation: 436

The block diagram you want to implement is a discrete-time system. Since there are no Ordinary Differential Equations (ODE) but only their discrete counterpart (Finite-differences equations), you do not need an ODE solver as the warning 1 points out.

In discrete-time systems you have to specify your sample time in order to approach to a continuous-time representation where every single instant t is built up by the discrete integer n and its progressions (n+1, n+2, and so on) as t = nT where T is your sample time; Simulink basically expects that you respect this kind of logic, then asks for a sample time. By default Simulink sets it variable which may lead the result "out of track". This is what the warning 2 points out.

Solution: In the 'Model Configuration Parameters' menu, at the Solver tab, set 'Fixed-Step' as Type. The pane will change with a field related to the sample-time (Fixed-step size); set then a Sample time in seconds different than "auto" (e.g. 0.01). This will solve the warning 2. Still in the Solver menu, set also 'Discrete (no continuous states)' instead of any other useless solver. This will solve the warning 1.

Upvotes: 0

Rody Oldenhuis
Rody Oldenhuis

Reputation: 38042

You've built the model correctly, but did not configure it correctly.

When running the model as-is, what will happen is the following:

  1. The Step block is a continuous-time source by default (it's Sample Time setting is 0).
  2. Simulink sees that the Step is connected to the Unit delay block, which is guaranteed to have constant output during minor steps (unlike Memory blocks)

  3. According to the documentation on sample times:

    [...] Simulink sets [Fixed-in-Minor step] as either an inherited sample time or as an alteration to a user specification of 0 (continuous). This setting is equivalent to, and therefore converted to, the fastest discrete rate when you use a fixed-step solver.

    Continuous sample time degrades to Fixed-in-Minor-Step rather than Discrete-time in the context of Variable-step solvers. Variable step size is used to speed up simulations (larger steps are taken when accuracy allows it), but requires trickery to compute, for example, the exact time at which the step triggers (the "Enable zero-crossing detection" tick box in the Step block's options). So, Simulink's best way forward in this particular situation is to convert the sample time of the Step block into Fixed-in-Minor-Step, which is propagated forward and inherited by all other blocks in the model.

  4. This is usually an awkward type of sample time, which is effectively not continuous-time, but still seen by all blocks as such. Therefore, the inherently discrete-time Unit delay will complain about being driven by a continuous-time signal (your 2nd warning), and Simulink itself will complain about the complete lack of "real" continuous-time blocks anywhere, while being instructed to use a continuous-time solver, ode45 (your 1st warning).

As usual in software development: it's always best to be explicit, about everything. In this case, the simplest way out of this is to explicitly specify a discrete-time, fixed-step solver in the model configuration dialog. That way, the continuous-time from the step will be automatically converted into discrete-time for the Unit delay.

Upvotes: 1

Related Questions