Why Integrator with Wrapped State don't wrap the lower limit? (R2018b)

On simulink we have a block called "Integrator with Wrapped State". This behavior looks pretty simple. This image (from the help doc) show whats the expected output (depicted by "Wrapped state integrator"):

In the parameters configuration, I set the values as follow:

Hence, I expected a output between 0 and 4. However, I got this output:

Why Integrator with Wrapped State don't wrap the lower(=0) limit?

Answer 1

[Fangjun Jiang]

It should not be like that. Create a simple new model to verify it. Grab a Sine Wave block, change the amplitude to be 3, Connect it to the Wrapped State block, change the upper value to be 4 and sample time to be 0, run simulation for 20 seconds, you should see it limits at both ends.

[Rubem Pacelli]

Nice, I got this output

But now set the sample time of the Sine Wave to 0.0001 and set the sample time of "Integrator with Wrapped State" to -1. Run again. You will get this wrong output

Since I have worked with discrete-time systems, I have been struggling with this problem.

[Fangjun Jiang]

Good finding. I think I can explain.

If you look under mask, there are two variant subsystems. For continuous system, it utilizes the built-in wrapping capability, which can wrap at both upper and lower values.

For discrete system, it is done through external reset. The reset logic only contains comparing to the upper value. I think it could be regarded as a bug in the design of the block. You could contact the Mathworks tech support.

You could improve it yourself. Add the logic of comparing to the lower value. Combine these two triggers with OR operation. You also need to switch the reset value between -(WrappedStateUpperValue-WrappedStateLowerValue) and +(WrappedStateUpperValue-WrappedStateLowerValue)

[Rubem Pacelli]

Well Fangjun Jiang, I did it. The following picture shows what I changed in the Linked Block:

It solved my problem partially... When I run my system on sampled-based mode, the output matches the continuous-time output. It turns out that my system is a little bit complicated as it operates on frame-based. The following picture your example operating on continuous-time; discrete-time and sample-based; and discrete-time and frame-based (200 samples per frame).

And the outputs are, respectively

As you see, the last picture (discrete-time and frame-based) is a complete mess... I don't know what's exactly happens there. And I also don't know how can it keep in touch with the support team of Matlab (I never did it)

[Fangjun Jiang]

Not sure about the issue wrt frame-based. You can contact the Mathworks tech support online from your Mathworks account, or call them up.

1. Your reset value is valid only when lower value is 0. Thinking of an example when upper is 5 and lower is 3.
2. The same block in R2019b seems to have fixed the problem. It contains the OR logic you implemented and a different way for reset value.