I have a signal in simulink which I want to normalize so that the highest value of the signal is always 1. So I use a MaxRunningResettable-Block to remember the highest value that passed so far. I then divide the signal by that value.
A little test with a signal generation block, the running resettable block, the divide block and a scope runs just fine. But when I add this normalizing function to my simulink model I get an error:
"Model initialization failed - Illegal rate transition found involving Unit Delay"
I don't even need to connect the little test case to my other model. Simply by putting it into my model I get this error. Strangely the RunningResettable-block turns yellow when I copy it - indicating that it has a different sampling rate I suppose. I don't get why this happens. I already tried to add a zero-order-hold-block behind the RunningResettable but that didn't help.
As suggest I tried to add another constant block to the R-input of the RunningResettable-Block. I tried several sampling frequencies for that Block (-1, 0, 1/fAb) but that didn't help.
Ok, finally I think that I found my failure. It seems, that the SignalGenerator outputs a continous signal (black). Because in my model there are mostly discrete signals this somehow causes errors. So when I simply add an zero-order-hold block after the signal generator everything seems to work just fine. The sampling frequency of the zero-order-hold has to be adjusted to the rest of the system.
Related
I am building a circuit model for a transformer which models the effects of hysteresis. It does so using the Matlab function block on the right, and works successfully when tested in isolation. However, the value of the magnetising inductance Lm depends on calculations requiring the value of Im. But Simulink cannot determine the value of Im without the value of Lm, thus forming an algebraic loop.
However, I have the initial value for the inductance, Lm_initial loaded into the workspace. With this, I should be able to solve for the first Im value, which can be used to determine the next Lm, and so on. However, specifying Lm_initial in the variable inductor's properties doesn't work; Simulink tries to evaluate Lm with the nonexistent 'phi' and 'Im' values rather than trying to solve for an initial Im using the value of the initial inductance.
I have tried solutions involving commenting/uncommenting blocks and implementing further subsystems which activate/deactivate depending on the time step, as well as unit delays, but these run into issues regarding tracking time for calculating the derivatives or output very incorrect/noisy waveforms.
Is there a relatively simple solution for this case? The problem appears as if it'd be relatively simple to solve, but I cannot seem to find a workaround for this.
Transformer Equivalent Model
The exact placement of the unit delay in the loop might be the key here: try to place the unit delay between the [lm] GoTo block and the lm input of your MATLAB function block fcn, that should work. And set the initial condition parameter to Lm_initial.
I had as primary objective to make a controller for the transfer function (5.551* s^2), using root locus I made the controller shown below. Analyzing the step response in the Workspace using the step () function I had a satisfactory answer but when I try to transfer this answer to Simulink the response behaves differently, at steady state for example I wish to have the smallest possible error as it was obtained in Workspace but in Simulink there is a big error and for some reason at 8 seconds time (Simulink simulation time) there is a "jump" as shown on the display and when I change the simulation time there is a change in this "jump" too and I do not know why these changes between one environment and another.
Step response in Workspace
Step response in Simulink with 8s of simulation
Step response in Simulink with 12s of simulation
Simulink controller
Simulink transfer function
I expected to make a controller that has an error less than 5% and an overshoot smaller than 25%, so I first made a controller with two integrators to nullify the effects of zeros on the source, after that I added two more integrators on the source to try decrease the error, the zero at -0.652 I used the angular condition for this and the gain of 0.240251 I used the modular condition.
I wasn't expecting the most optimized behavior possible, just that it has minimum conditions that satisfy the imposed conditions, so I didn't worry for example about the four integrators at the source.
I tried use the sisotool() command thinking that I had done something wrong, but the result changed a lot when I was simulating Simulink so I discarded this option and kept the controller I made using root locus.
Your MATLAB code and your Simulink model are not the same, and hence the different results.
MATLAB allows you to define the non-causal plant model P_ball, then form the causal closed loop CL, which can have its step response generated.
Simulink does not allow you to model non-causal blocks (even if the overall model is causal) and hence will not allow you to implement s^2, which I assume is why you have used two differentiation blocks. But a numerical differentiation is not the same as a Laplace s operator.
You would have to make the plant causal by incorporating two poles that are large enough to not adversely effect the overall simulation. So your plant model needs to be something like 5.551*s^2/((s/1000 + 1)(s/1000 + 1)) which can be implemented using a Transfer Function block with a numerator of 5.551*1000*1000*[1 0 0] and a denominator of [1 2*1000 1000*1000].
Alternatively you could just implement PID * P_ball (where you manually do the 2 zero/pole cancellations) which is causal.
I've had to create the Simulink Diagram after this picture:
My answer is this one:
I've gave some values to a, b and c (like 3, 4 and 5), but when I try to run it, it gives me the following warning:
Warning: The model 'ex2_2' does not have continuous states, hence Simulink is using the
solver 'VariableStepDiscrete' instead of solver 'ode45'. You can disable this diagnostic by
explicitly specifying a discrete solver in the solver tab of the Configuration Parameters
dialog, or by setting the 'Automatic solver parameter selection' diagnostic to 'none' in the
Diagnostics tab of the Configuration Parameters dialog
Warning: 'ex2_2/Unit Delay' is discrete, yet is inheriting a continuous sample time; consider
replacing unit delay with a memory block. When a unit delay block inherits continuous sample
time, its behavior is the same as the memory block. Unit delay block's time delay will not be
fixed and could change with each time step. This might be unexpected behavior. Normally, a
unit delay block uses discrete sample time. You can disable this diagnostic by setting the
'Discrete used as continuous' diagnostic to 'none' in the Sample Time group on the
Diagnostics pane of the Configuration Parameters dialog box. "
and the output (scope) it's just a step signal...
I don't know where I'm wrong here.
You've built the model correctly, but did not configure it correctly.
When running the model as-is, what will happen is the following:
The Step block is a continuous-time source by default (it's Sample Time setting is 0).
Simulink sees that the Step is connected to the Unit delay block, which is guaranteed to have constant output during minor steps (unlike Memory blocks)
According to the documentation on sample times:
[...] Simulink sets [Fixed-in-Minor step] as either an inherited sample time or as an alteration to a user specification of 0 (continuous). This setting is equivalent to, and therefore converted to, the fastest discrete rate when you use a fixed-step solver.
Continuous sample time degrades to Fixed-in-Minor-Step rather than Discrete-time in the context of Variable-step solvers. Variable step size is used to speed up simulations (larger steps are taken when accuracy allows it), but requires trickery to compute, for example, the exact time at which the step triggers (the "Enable zero-crossing detection" tick box in the Step block's options). So, Simulink's best way forward in this particular situation is to convert the sample time of the Step block into Fixed-in-Minor-Step, which is propagated forward and inherited by all other blocks in the model.
This is usually an awkward type of sample time, which is effectively not continuous-time, but still seen by all blocks as such. Therefore, the inherently discrete-time Unit delay will complain about being driven by a continuous-time signal (your 2nd warning), and Simulink itself will complain about the complete lack of "real" continuous-time blocks anywhere, while being instructed to use a continuous-time solver, ode45 (your 1st warning).
As usual in software development: it's always best to be explicit, about everything. In this case, the simplest way out of this is to explicitly specify a discrete-time, fixed-step solver in the model configuration dialog. That way, the continuous-time from the step will be automatically converted into discrete-time for the Unit delay.
The block diagram you want to implement is a discrete-time system. Since there are no Ordinary Differential Equations (ODE) but only their discrete counterpart (Finite-differences equations), you do not need an ODE solver as the warning 1 points out.
In discrete-time systems you have to specify your sample time in order to approach to a continuous-time representation where every single instant t is built up by the discrete integer n and its progressions (n+1, n+2, and so on) as t = nT where T is your sample time; Simulink basically expects that you respect this kind of logic, then asks for a sample time. By default Simulink sets it variable which may lead the result "out of track". This is what the warning 2 points out.
Solution: In the 'Model Configuration Parameters' menu, at the Solver tab, set 'Fixed-Step' as Type. The pane will change with a field related to the sample-time (Fixed-step size); set then a Sample time in seconds different than "auto" (e.g. 0.01). This will solve the warning 2. Still in the Solver menu, set also 'Discrete (no continuous states)' instead of any other useless solver. This will solve the warning 1.
Assume that you have a Simulink simulation where a certain signal is first positive and after some time t in a given interval, it becomes negative. Your goal is to find the zero-crossing.
A first approach would be to plot the signal over the given interval, save it and calculate the zero-crossing.
When repeating this simulation numerous times for varying parameters, it would be beneficial to be able to stop the simulation after the signal has become negative. Then there is already enough information for the calculation of the zero-crossing in Matlab. How could you do that?
Yes, use the Stop Simulation block with the appropriate logical input to the block:
You can use an if / else block to control the flow in the Simulink model. In the if / else block, you can choose the condition if u > 0, continue as normal if it's true, and use the else-option to bypass the rest of the flow you would otherwise run. For instance jump directly to the scope.
Another ways:
You can use Hit Crossing Block in Simulink to find time at the moment of hitting zero.
Another way - use any Trigger or Resettable system. It detects the zero crossing too. For example: this question at SO.
Of course you can also use User Defined function to detect zero crossing by your hand and do whatever you want with the signal at the same time.
About making a lot of simulations and then stops:
you can use Check Upper Static Bound for automatically stops simulation at the moment when zero will be crossed in nth time. For example:
I set upper bound = 10 for this block and this stops at 10th crossing.
There are a lot of ways to save function values in this points or just array of times but this is an another question :)
I am new with signal processing, i have following signals which i've got after some pre-processing on original signals.
You can see some of them has some similarities with others and some doesn't. but the problem is They have various range(in this example from 1000 to 3000).
Question
How can i analysis their properties scale-free(what i mean from properties is statistical properties of signals or whatever)??
Note that i don't want to cross-comparing the signals, i just want independent signals signatures which i can run some process on them sometime later.
Anything would help.
If you want to make a filter that separates signals that follow this pattern from signals that don't, well, there's tons of things you could do!
Just think practically. As a first shot at it, you could do something like this (in this order):
Check if the signals are all-positive
Check if the first element is close in value to the last element
Check if the maximum lies "in the middle" somewhere
Check if the first value is small, then the signal grows, then shrinks again
Check if the growth rates are gradual. You could for example analyze their derivatives (after smoothing):
a. derivative should be all-positive for a while, then all-negative.
b. derivative should be smooth (no jumps greater than some tolerance)
Without additional knowledge about the signal's nature/origin, it's going to be hard to come up with more meaningful metrics than these...