Enabled Subsystem does not reliably disable
9 views (last 30 days)
Show older comments
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
- 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.
- 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. (?)
- 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
2 Comments
Paul
on 23 Sep 2024
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).
Answers (1)
MULI
on 23 Sep 2024
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:
See Also
Categories
Find more on General Applications in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!