I have multiple signals going into a scope and also viewed in a Signal Viewer. The results should appear to be the same but they do not. The signals are of different sample times and this seems to occur with a decimation factor not equal to one.
MATLAB: Are the results in the Signal Viewer different than the scope even though they are the same signals
simulink
Related Solutions
There are many interesting things to note from the simulation of this model. These observations can be answered in the questions below:
1. Does 'sd.signals.plotStyle = 1' for Relay block output represent a discrete signal ?
A. Yes. 'sd.signals.plotStyle = 1' represents that a signal is discrete.
2. Why is the scope colored as red (discrete) while all incoming signals to scope are continuous (black) ?
A. There is some ambiguity in the coloring scheme for the scope block. In essence, the black signal line - 'continuous' and red - 'discrete' are both continuous in time. But, the scope block assumes the color 'red' due to the settings for the model, which, in this example is 'Fixed-Step-Discrete'.
3. Why is the plot for relay block output discrete, while for hysteresis is continuous ?
A. In Simulink, RELAY block is special in the way it is implemented. It is executes as :
- Continuous in time
- Discrete in Amplitude
The above observations imply that the relay block is executing 'continuous in time', but, its outputs are stored as only '0' or '1' with no intermediate values. Hence, we observe that the output from relay block looks like 'discrete in time', which is not actually whats going on.
In order to see the outputs of both Hysteresis and Relay blocks as discrete, you have to force the Hysteresis block to execute as fixed step discrete. To do so, use a 'Rate Transition Block' to feed the Hysteresis and relay blocks, as shown in the 'example_solution.mdl' attached to the solution below.
This is expected behavior for a discrete event subsystem with mux or bus inputs in SimEvents 3.0 (R2009b).
In SimEvents, it is probable that the inputs to your discrete events subsystem are coming from another SimEvents block and are event-based signals. You can mux (or bus) these signals together. Event-based signals don't have a sample time and they update asynchronously during the simulation.
It is completely acceptable to mux two event-based signals to create a virtual signal of width any width. A mux signal still retains the individual properties of its components. Hence the components of the mux can still fire asynchronously and are still event-based.
However, when this behavior changes when virtual mux signal feeds into a discrete-event subsystem , which is very similar to an Atomic Subsystem. The contents of a discrete-event subsystem always execute as a unit, and hence you can think of this subsystem as atomic in the "SimEvents sense". Feeding a virtual mux signal to the Inport block of such an atomic subsystem converts that signal to a non-virtual signal. For further information see the link below.
web([docroot '/toolbox/simulink/ug/bq4jy05-1.html'])In effect, the discrete event subsystem creates a new signal by copying over the constituent signals. Thus, inside the subsystem, we have a new non-virtual signal of width 2. This new signal cannot possibly be an event-based signal because its components can no longer update asynchronously. Both elements must now update together, and hence it becomes a time-based signal. Every time-based signal has a sample-time. The Simulink engine assigns this new time-based signal with the default sample time of 0.2. In the attached model it updates 5 times every second or 5 times the rate of the truly discrete signals. By feeding a virtual mux'ed signal into a discrete-event subsystem, the components of the signal have lost their event-based nature.
A similar argument applies for Bus Signals. You may use a Bus Selector block to select one of the two bus elements, the result would continue to be an event-based signal. However, by feeding this virtual bus to a discrete-event subsystem, this converts it to a non-virtual bus, which is a time-based signal because its components can no longer update asynchronously. Hence it is assigned the default sample time of 0.2.
If you wish to have a discrete events subsystem execute at a rate different than the time-based signals inside of it, you can do so with a triggered subsystem as noted by the "workaround" in the attached model.
Best Answer