|On this page…|
When a block produces more than one output signal in response to events, the simulation behavior might depend on the sequence of signal updates relative to each other. This is especially likely if you use one of the signals to influence a behavior or computation that also depends on another one of the signals, as in Detect Changes in the Last-Updated Signal.
When you turn on more than one output signal from a SimEvents® block's dialog box (typically, from the Statistics tab), the block updates each of the signals in a sequence. See the Signal Output Ports table on the block's reference page to learn about the update order:
In some cases, a block's reference page specifies the sequence explicitly using unique numbers in the Order of Update column.
For example, the reference page for the N-Server block indicates that upon entity departures, the w signal is updated before the #n signal. The Order of Update column in the Signal Output Ports table lists different numbers for the w and #n signals.
In some cases, a block's reference page lists two or more signals without specifying their sequence relative to each other. Such signals are updated in an arbitrary sequence relative to each other and you should not rely on a specific sequence for your simulation results.
For example, the reference page for the N-Server block indicates that the w and util signals are updated in an arbitrary sequence relative to each other. The Order of Update column in the Signal Output Ports table lists the same number for both the w and util signals.
When a block offers fewer than two signal output ports, the sequence of updates does not need explanation on the block's reference page. For example, the reference page for the Enabled Gate block does not indicate an update sequence because the block can output only one signal.
The example below (open modelmodel) plots the ratio of the queue's current length to the time average of the queue length. The FIFO Queue block produces #n and len signals representing the current and average lengths, respectively. The computation of the ratio occurs in a function-call subsystem that is called when the Signal-Based Function-Call Generator block detects a change in #n (as long as len is positive, to avoid division-by-zero warnings). Because the FIFO Queue block updates the len signal before updating the #n signal, both signals are up to date when the value change occurs in the #n signal.
If you instead connect the len signal to the Signal-Based Function-Call Generator block's vc input port, then the block issues a function call upon detecting a change in the len signal. At that point, the #n value is left over from the block's previous arrival or departure, so the computed ratio is incorrect.