Clarify multiple Clock ticks per Event Mode for different Clock types (…

…modelica#1937)

docs/2_3_common_states.adoc

@@ -573,7 +573,8 @@ _As part of the iterations to solve the algebraic loop, latexmath:[v] acquires a
 _If the final (or some intermediate) value of latexmath:[v] no longer activates the Clock, then this Clock must be deactivated by the Importer during the same super-dense time instant.]_ +
 The importer can set a Clock to `fmi3ClockInactive` only if the Clock has the attribute <<canBeDeactivated,`canBeDeactivated = true`>>.
 Any Clock active during <<fmi3UpdateDiscreteStates>> must be deactivated by the FMU itself. +
-Only <<time-based-clock,time-based Clocks>> must not be active for more than one call of <<fmi3UpdateDiscreteStates>> per <<EventMode>>. +
+<<periodic-clock,Periodic Clocks>> must not be active for more than one call of <<fmi3UpdateDiscreteStates>> per <<EventMode>>.
+This restriction does not apply to <<triggered,triggered Clocks>>, nor does it apply to <<aperiodic-clock,aperiodic Clocks>>, for which latexmath:[T_{\mathit{interval}} = 0] can be returned by <<fmi3GetInterval>>. +
 _[The event iteration for handling discontinuities of the continuous part of the FMU should precede handling of time-based Clocks._
 _No further constraints on activations of <<time-based-clock,time-based Clocks>> are defined, e.g. activating at the first instant of super-dense time._
 _If the semantics of some Clocks require any specific treatment, e.g. activation at the same super-dense time instant, only the importer will know and must therefore enforce proper activation of the respective Clocks.]_