Discrete Time Integrator does not integrate every time step

Hello,

I would like to integrate a function with the Discrete Time Integrator in Simulink. I have a signal, which I first squared in order to have it only positive. My simulation time is let´s say 0.1s and I´d like to integrate over time steps of 0.01s. Therefore, the sample time of the Discrete Time Integrator is also 0.01s.

In the scope you can see the input signal "error", which can be positive and negative, and the squared error (the gain only helps to make it all visible in the scope at one glimpse). The problem is the integrated signal. Why is there no jump at 0.04s and 0.07s? It is always like this, also with different input signals like a simple jump signal.

I need this to build the reward signal for a reinforcement learning agent. Therefore, I also have continuous states and cannot change the solver. I would be very pleased, if someone has a suggestion. Thank you.

[Mathieu NOE]

hello

It would be interesting to know the sampling rate of the signal entering the integrator

[Lucia Liedl]

The input signal is continuous

[Mathieu NOE]

ok

I see you modifed your simulink file , does it work better now ? how does your fourth trace look like ?

Answer 1

[Mathieu NOE]

hello

hmm, maybe your "blue" spikes are not all perfectly matching the 0.01 s time spacing and then your integrator see no input variation according to its 0.01 s sampling

I made a very simple test

• solver : fixed step , ts = 1e-5 s
• a pulse generator sampled at ts =1e-5 s , period = 1000 samples => one pulse evry 0.01 s , pulse duration = 25 samples and no phase delay
• integrator with sampling at 0.01 s (so runs at a integer factor slower vs base rate)

as we can see it works , because the two processes are perfectly synchronous and the pulse generator has no phase delay with the 1e-2 s "beat" of the integrator

if now I introduce a phase delay of only 5 samples (= 5e-5 s) , the signal pulses get time shifted vs the time grid of the integrator and it's not working anymore. You would get the same result if Iintroduce a slight variation in the pulses period = phase shift (fix or variable)

my suggestion : run your integrator at a faster rate (the one of the incoming signal) and then reduce the output rate to 1e-2 s by using a zero order hold block (sampled at 1e-2 s) - see the red arrow

now whatever perturbation i do on my pulse generator , I always get a correct output

[Lucia Liedl]

Thank you very much for your response. I tried your suggestestion and it looks better now, but still isn´t exactly how it should be. There is now at every time step a step in the signal, but only when I reduce the sample time of the discrete time integrator to 0.001s. But the steps at 0.03s and 0.06s are still smaller than the other ones. The other ones have approximately the same value (the height of the step is the same).

With even lower sample times the steps of the signal become more alike but still at 0.03s and 0.06s the values are too low. Also, I do not want to reduce the sample time much more. Do you have any other suggestions I can try?

[Mathieu NOE]

hello again

why is the integrator output smaller at t = 0.03 and 0.06 s ? I don't see your input signal (blue trace) in the picture , does it mean also the signal peak is weaker ?

[Mathieu NOE]

also why do we use the technique of integrating U² ?

are you simply looking for a triggered counter (so you would get a constant amplitude staircase signal)

[Mathieu NOE]

this is for now pure speculation from my side , but I assumed there is a signal fluctuation on the input of the integrator that creates the variation in staircase signal output

(to generate the effect , my pulse signal has a sine amplitude modulation, we could also change the width of the pulses to get the same reasult)

[Mathieu NOE]

see that with the other strategy, based on a counter inside a trigered susbsystem block, you get a +1 constant amplitude staircase signal whatever happens on the incoming signal amplitude

[Mathieu NOE]

inside the trigered susbsystem block, there is only a counter (the +1 operation is to force the output to start at 1 and not 0 on the first trigger event