im using Matlab function in Simulink and use data store memory to access the simulation time and implement something according to the time

So i build my code to control a buck boost converter by the matlab function i have four inputs a simulation time using clock block , Dsw4 which is a data store write and also lastUpdateTime which is also data store write so, in my code im trying when the simulation time reach the 0.08 and excute the else if statment as shown in the code to make step in Dsw4 acoording to the simulation time which mean every 16mili second the dsw4 increase step so, to know the lastupdateTime also and Dsw4 i used a data store read block but when i use a display to show the values of the data store reads and data store writes the value does not change and i also connect them with data inspector to check if the value of them change with the time and they not change and i tried to solve but i dont know where the problem

the code will be attach and a screen shot for matlab function connection:

function [voltage1, voltage2, voltage3, voltage4, lastUpdateTimeOut, Dsw4Out] = pulseGenerator(counter, t, lastUpdateTime, Dsw4)
% Parameters
frequency = 100e3; % 100 kHz
amplitude = 6; % Amplitude of the pulse
voltage1 = -3; % Initialize outputs
voltage2 = -3; % Initialize other outputs
voltage3 = -3;
voltage4 = -3;
% Calculate period in terms of simulation steps
period1 = round(1 / frequency * 1e6); % Convert to microseconds
period3 = round(1 / frequency * 1e6); % Same period for the second condition
% Adjust duty cycle based on simulation time
if 0 <= t && t < 0.035
    Dsw1 = 0.25; % Duty cycle for voltage1
    if mod(counter, period1) < Dsw1 * period1
        voltage1 = amplitude; % High state
    else
        voltage1 = -3; % Low state
    end
elseif 0.035 <= t && t < 0.08
    Dsw1 = 0.5; % Duty cycle for voltage1
    if mod(counter, period3) < Dsw1 * period3
        voltage1 = amplitude; % High state
    else
        voltage1 = -3; % Low state
    end
elseif 0.08 <= t && t < 0.1
    Dsw1 = 0.5; % Duty cycle for voltage1
    if mod(counter, period1) < Dsw1 * period1
        voltage1 = amplitude; % High state
    else
        voltage1 = -3; % Low state
    end
    % Gradually increase Dsw4 from 0 to 0.88 in 5 steps
    if (t - lastUpdateTime) >= 0.016 % Check if 16 ms has passed
        lastUpdateTimeOut = t; % Update last update time
        Dsw4Out = min(Dsw4 + 0.176, 0.88); % Update Dsw4 in steps
    else
        lastUpdateTimeOut = lastUpdateTime; % No update
        Dsw4Out = Dsw4; % No update
    end
    if mod(counter, period1) < Dsw4Out * period1
        voltage4 = amplitude; % High state
    else
        voltage4 = -3; % Low state
    end
elseif 0.1 <= t && t < 0.15
    voltage4 = -3;
    voltage1 = -3;
elseif 0.15 <= t && t < 0.4
    voltage1 = -3;
    voltage4 = -3;       
    Dsw3 = 0.24; % Duty cycle for voltage3
    if mod(counter, period1) < Dsw3 * period1
        voltage3 = amplitude; % High state
    else
        voltage3 = -3; % Low state
    end  
else
    voltage1 = 0; % Initialize outputs
    voltage2 = 0; % Initialize other outputs
    voltage3 = 0;
    voltage4 = 0;
end
% Outputs for Data Store Write
lastUpdateTimeOut = lastUpdateTime; % Output updated lastUpdateTime
Dsw4Out = Dsw4; % Output updated Dsw4
end

[Walter Roberson]

Have you configured for continuous time or discrete time? With the various discontinuities in your code, this code only has a chance in discrete time.

[ahmad salahat]

the system build for continuous time should i conveted to discontious to achive the required or there any way to implement for continuous time?

[Walter Roberson]

if 0 <= t && t < 0.035

When you are using continuous time, Simulink builds differential equations and uses a differential equation solver. By default for continuous time, it will use ode15s, ode45, or ode23t variable-step solvers. At any given time, those solvers all evaluate at a series of different proposed times and proposed states, and use the result to make a prediction. They then cross-check the prediction and if the predicted error would be too high, they reduce the step size and try again with shorter steps -- effectively going backwards in time. Even if the step succeeds, the order of the probing around is unspecified so the probing is potentially sometimes at earlier times than other probing steps.

At any given time and state, several probes around are made at positions it is not seriously expected that it will proceed to. Think of it as walking on a hill in the dark with a strobe flashlight: you shine the flashlight in carefully chosen directions and think about the results to determine where you really step (which might well be to a location that you did not specifically probe, with you counting on the hill hopefully not being too steep.)

Now the thing about those carefully chosen probe locations, is that the probe sequence only works if the hill has continuous second derivatives: if the hill has sudden steep outcroppings or sudden falls, then you might well end up stepping somewhere you should not have stepped.

When your code has breakpoints based on time, then it is quite likely that the second derivative of the code is not continuous (probably even the first derivative is not continuous either.) It is not impossible that you carefully coded for continuity of the second derivative at the boundaries, but it is unlikely.

Now, if you use discrete time with a timestep that divides all of the time boundaries, then this is not a concern.

[ahmad salahat]

the problem that i tried to converte the system to discrete to control the simulation by the time but it not possible for my buck boost system to be discrete .

the idea from the project to work with boost system after work for small periode of time as buck to reduce the current so the idea of divide the time as step come from this

To be honest i work with this steps in order to take this addvantage which is control the converter by simulation time insted of take order from me as a real time application.

i tried to convert it to discret from the model setting by convert the step to fixed and change the solver as discrete but it does not work so, im tring to implement the idea of control the converter as a real time application

[Walter Roberson]

Suppose you are "at" a certain time and state, and suppose you are using continuous time. Then the ode15s, ode45, or ode23t integrator will probe around at a number of different times and states, trying to estimate the best new state. When you are near one of the breakpoint times such as near the end of 0.1 <= t && t < 0.15 then some of the locations probed will be inside the time band, but some of the probed times will be inside 0.15 <= t && t < 0.4. The function will react differently, non-continuously between the two bands. Because the mathematics of RK calculations requires continuous second derivatives, the resulting estimated location will be wrong. If you are lucky then the integrator will notice and complain about being unable to integrate at that time. If you are not lucky then the integrator will silently accept the incorrect location and proceed as-if it were correct. At the very least, the waveform will be wrong near the boundaries; at worst the calculated location might be non-physical, somewhere that is not physically realistic.

You can reduce the danger by configuring a fixed-step integrator https://www.mathworks.com/help/simulink/ug/fixed-step-solvers-in-simulink.html -- but you will still get wrong results every time the starting time is on one side of a time boundary and the new step is on the other side of the time boundary. You can remove that effect if you ensure that the fixed step size is the greatest common divisor (GCD) of the time ranges (end time minus start time of the various bands)

[Paul]

I would think that a model of an electrical system is best simulated with a continuous solver. If the pulseGenerator block is running with a discrete sample time, then the continuous solver should have a variable step size, or fixed step size that that is an integer divide down of the pulse generator sample time (assuming no other discrete blocks in the model). If the pulseGenerator has to run with a continuous sample time then it might be best to bite the bullet and implement that logic in native blocks that can operate with and take advantage of Simulink's zero crossing detection.