This is strange problem and I suspect this is a bug in Dymola (for reasons I will explain in a second).
It turns out you are running into this issue, although it isn't at all obvious in this situation why this should be the case.
So one solution is to use a slightly different implementation of the Timer
model, one that looks like this:
block Timer
"Timer measuring the time from the time instant where the Boolean input became true"
extends Modelica.Blocks.Interfaces.partialBooleanBlockIcon;
Modelica.Blocks.Interfaces.BooleanInput u "Connector of Boolean input signal"
annotation (extent=[-140,-20; -100,20]);
Modelica.Blocks.Interfaces.RealOutput y "Connector of Real output signal"
annotation (extent=[100,-10; 120,10]);
protected
discrete Modelica.SIunits.Time entryTime "Time instant when u became true";
initial equation
pre(entryTime) = 0;
equation
when pre(u) then
entryTime = time;
end when;
y = if u then time - entryTime else 0.0;
end Timer;
Note the presence of the pre
operator around the condition in the when
clause.
In general, the use of the pre
operator is a good idea (as I explain in that other issue). Why it is necessary in your specific case, I cannot explain. The conditional expression is simply true
in your case which means it should trigger the when
clause at the start of simulation. I don't see the algebraic loop that Dymola is talking about here. I suspect it has something to do with Dymola trying to organize all the things that should happen at the start of the simulation and running into some complication there. But it isn't obvious and it can all be avoided with the alternative Timer
model I mentioned.