Enabled Subsystem does not reliably disable

The Simulink model shown in the screenshot does not behave as I expect, and I would like to understand the reason.

All blocks are on default settings, except:

• Gain: 1/pi
• Compare To Constant: operator >=, constant value 1.0
• Logical Operator: XOR
• (Scope: two inputs, line markers)

Note that the Compare To Constant block has Zero-crossing (ZC) detection enabled by default. The Enabled Subsystem consists of one input port directly connected to the output port.

All solver settings are at default values. The solver is auto(VariableStepDiscrete). I only change the StopTime of the simulation (see below).

Expected behavior

The enabled subsystem should be enabled for exactly one time point (in major time step) and "sample and hold" the value of its input (the scaled clock signal).

This should occur when the scaled clock signal reaches the threshold value of 1.0 (but not later than that, thanks to zero-crossing detection).

The sampled and held value (see Display block) should be 1.0 (sampled at time t=pi).

Observed behavior

Sometimes the result (= sampled and held value at the end of the simulation) is larger than expected. The scope screenshot (lower half) shows that the enabled subsystem seems to be enabled for two time points (instead of one). In the first time point (at t=pi) it copies a value of 1.0 to its output, in the subsequent second time point a value of approx. 1.025, which is then held until the end of the simulation.

Whether the problem occurs, weirdly depends on the StopTime. Some examples:

• For these values of StopTime the problem occurs: 4.00001, 8, 9, 10.1, 11, 13.
• For these values everything works fine: 4, 6, 7, 10, 12.

My analysis so far

When the problem occurs, Simulink has placed two time points at the zero-crossing, one just before and one just after the zero-crossing. When the problem doesn't occur, there are three time points close to the zero-crossing (one just before, two just after the ZC).

Although the XOR block output is correctly true only for one time point (right hand side of the zero-crossing, see upper half of the scope screenshot), the final output of the enabled subsystem seems to always be equal to the value of its input sampled one time point later (that is: when the XOR has dropped to false again). That is not a problem if that time point is the third of 3 close to the ZC, but it produces a wrong result if that time point is much later than the ZC.

So I wonder why Simulink sometimes uses 3 time points at a ZC (good), but sometimes only 2 (bad). Any hints or explanations welcome why Simulink behaves like this and/or why it should(n't).

Some more notes

1. I know the expected behavior could be implemented differently. That's not the point. This is a minimal example. In my opinion it should not behave the way it does.
2. I'm unsure about the correct/official wording: What I mean by "time point" are the elements of "tout". Usually I refer to them as major time steps, but maybe that's wrong as they're points in time, not steps. (?)
3. My maybe related (and unfortunately still unanswered) question about zero-crossings and the number of time steps/points taken by Simulink: https://de.mathworks.com/matlabcentral/answers/553960-number-of-necessary-time-steps-to-handle-a-zero-crossing

[Paul]

I replicated your results and it does seem strange that in the "bad" case it sure looks the Enabled Subsystem is executed twice even though the enabling signal is true at only one value of tout (as it is also for the "good" case).

[creepydog]

Hi Paul. Thanks for your investigations. It looks as if the Enabled Subsystem were executed twice but I think it isn't. I just made an additional experiment: I added a counter to the subsystem and observed that it was incremented only once. Really strange.

Answer 1

[MULI]

Hi,

I understand that the Enabled Subsystem sometimes stays on for two time points instead of one because of how Simulink handles zero-crossings.

It might happen due to following reasons

• Simulink uses zero-crossing detection to pinpoint when signals change direction, which can trigger subsystems.
• Occasionally, the solver places extra time points around these crossings, causing the subsystem to remain enabled longer than expected.
• The VariableStepDiscrete solver adjusts its step size for accuracy and performance, which can lead to different time point placements, especially around zero-crossings.
• Changes in StopTime can affect how time points are distributed, impacting zero-crossing behaviour.

This behaviour can be fixed by following the below suggestions:

• By Switching to a fixed-step solver can help ensure consistent time point placement.
• Adjust the solver's tolerances to enhance zero-crossing accuracy.
• You can specify extra time points around expected zero-crossings to ensure they are evaluated properly.
• Implement a Stateflow chart to control when the subsystem is enabled or disabled, gives you more precise control. For an example of this, please refer to the example linked below:

https://www.mathworks.com/help/hydro/ug/drill-ream-actuator.html

[creepydog]

No, switching to a fixed-step solver sabotages the zero-crossing mechanism as the time steps cannot be changed to exactly hit arbitrary zero-crossings any more.

And no, adjusting the solver's tolerances does not change the behavior of my example (I tried up to 1e-12 for absTol and relTol).

Also: No, specifying extra time points manually (??) doesn't work for previously unknown zero-crossing events.

And finally: No, using Stateflow is a totally different implementation (see original question, section "some more notes", point 1).