Clock class represents a clock within the simulation. There is one main clock for the Simulator itself, and all other clocks, even if they are not physically derived off the same clock signal, are simulated by inserting events into the main clock.
@author Ben L. Titzer
@author Dana P'Simer <danap@bluesoftdev.com>
The {@code system} factory methods provide clocks based on the best availablesystem clock This may use {@link System#currentTimeMillis()}, or a higher resolution clock if one is available. @implSpec This abstract class must be implemented with care to ensure other classes operate correctly. All implementations that can be instantiated must be final, immutable and thread-safe.
The principal methods are defined to allow the throwing of an exception. In normal use, no exceptions will be thrown, however one possible implementation would be to obtain the time from a central time server across the network. Obviously, in this case the lookup could fail, and so the method is permitted to throw an exception.
The returned instants from {@code Clock} work on a time-scale that ignores leap seconds,as described in {@link Instant}. If the implementation wraps a source that provides leap second information, then a mechanism should be used to "smooth" the leap second. The Java Time-Scale mandates the use of UTC-SLS, however clock implementations may choose how accurate they are with the time-scale so long as they document how they work. Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds.
Implementations should implement {@code Serializable} wherever possible and mustdocument whether or not they do support serialization. @implNote The clock implementation provided here is based on {@link System#currentTimeMillis()}. That method provides little to no guarantee about the accuracy of the clock. Applications requiring a more accurate clock must implement this abstract class themselves using a different external clock, such as an NTP server. @since 1.8
08/11, 2011 - Created
09/27, 2011 - Updated compareTo to return Occurred
The {@code system} factory methods provide clocks based on the best availablesystem clock This may use {@link System#currentTimeMillis()}, or a higher resolution clock if one is available.
The principal methods are defined to allow the throwing of an exception. In normal use, no exceptions will be thrown, however one possible implementation would be to obtain the time from a central time server across the network. Obviously, in this case the lookup could fail, and so the method is permitted to throw an exception.
The returned instants from {@code Clock} work on a time-scale that ignores leap seconds.If the implementation wraps a source that provides leap second information, then a mechanism should be used to "smooth" the leap second, such as UTC-SLS.
Implementations should implement {@code Serializable} wherever possible and mustdocument whether or not they do support serialization.
The values parameter by default contains an array of IntTokens with values 1 and 0. The default offsets array is {0.0, 1.0}. Thus, the default output will be alternating 1 and 0 with 50% duty cycle. The default period is 2.0.
The type of the output can be any token type. This type is inferred from the element type of the values parameter.
If the period is changed at any time, either by providing an input or by changing the parameter, then the new period will take effect as soon as possible. That is, if there is already a period in progress, it may be cut short if the new period is shorter so that its time matches the new period. But it will only be cut short if current time has not passed the cycle start time plus the new period. Otherwise, the period in progress will run to completion.
This actor can generate finite sequences by specifying a finite numberOfCycles. The numberOfCycles has a default value UNBOUNDED, indicating infinite length of executions. If numberOfCycles is a positive number, once the specified number of cycles has been completed, then this actor returns false from the postfire() method, which indicates to the director that the actor should not be fired again. (A cycle is "completed" each time the last event in the values array is produced).
The actor can also generate a finite sequence by giving a finite value to the stopTime parameter. This gives a time rather than a number of cycles, and thus can be used to stop the clock in the middle of a cycle, unlike numberOfCycles. Just like numberOfCycles, when the stop time is reached, the actor's postfire() method returns false.
If the trigger input is connected, then an output will only be produced if a input has been received since the last output. The trigger input has no effect on the first output. After the first output event, no further output event will be produced until a time greater than or equal to the time at which a trigger input is received. At that time, the output produced will have whatever value would have been produced if the trigger input was not connected. Note that this trigger is typically useful in a feedback situation, where the output of the clock eventually results in a trigger input. If the time-stamp of that trigger input is less than the time between clock events, then the clock will behave as if there were no trigger input. Otherwise, it will "skip beats."
This actor can be a bit tricky to use inside a ModalModel. In particular, if the actor is in a state refinement, then it may "skip a beat" because of the state not being the current state at the time of the beat. If this occurs, the clock will simply stop firing, and will produce no further outputs. To prevent this, the clock may be reinitialized (by setting the reset flag of a modal model transition). Alternatively, you can assign a value to the the period of the Clock in the setActions of the transition. This will also have the effect of waking up the clock, but with a subtle difference. If you use a reset transition, the clock starts over upon entering the destination state. If you set the period parameter instead, then the clock behaves as if it had been running all along (except that its period may get changed). Thus, in the first case, the output events are aligned with the time of the transition, while in the second case, they are aligned with the start time of the model execution.
This actor is a timed source; the untimed version is Pulse. @author Edward A. Lee, Haiyang Zheng @version $Id: Clock.java,v 1.112 2007/12/06 21:56:29 cxh Exp $ @since Ptolemy II 0.3 @Pt.ProposedRating Yellow (eal) @Pt.AcceptedRating Yellow (yuhong)
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |