I am trying to find a transfer function of bldc motor speed over duty cycle percent. I made two measurements for different duty cycle percentages in order to both estimate transfer function and its validation.
For the first one (%65 duty cycle step input) I got below measurement and its transfer function estimation.
For the second one (%70 duty cycle step input) I got below measurement and it transfer function estimation.
The problem is that my transfer functions are not validating each other as shown below. They do not give the same response for the same input. Can anyone explain the reason?
It looks like the two measurements are very different. One has a maximum of 220, the other has a maximum of 350. This means the data acquisition is at fault, or the motor is itself variable.
Why don't you try measuring 20 times, and see if the raw data look similar?
Otherwise would need more info about your recording setup and the protocol for testing the duty cycles. It doesn't sound like a matlab or programming problem.
-- edit
Transfer functions are usually the output as a function of the input. Not functions of time.
Transfer function estimation assumes that the system is linear and time-invariant.
Most likely the system exhibits a nonlinear response characteristic which causes a very large change in output amplitude when input is increased from 65% to 70%, so a transfer function obtained at one operating point is not valid for the other.
Related
An outside Library (from PreScan) requests 200 Hz while my control plant model needs to run at 100 Hz. Therefore, my question is that how can I coordinate these two activities? My concern is that if I use 200Hz in Simulink, it may compromise my control plant’s fidelity.
Is it possible to set simulink time step as 1/100 while keep the outside library to run at 200Hz?
Simulink works perfectly happily with multi-rate models. The thing (it appears) that you don't understand is the difference between the overall model sample rate - i.e. the settings of your solver - and the sample rate of individual blocks within your model.
It's very typical to have some blocks in your model sampled at say 100Hz, while other parts of your model sampled at 200Hz. In this case you would choose a discrete solver and give it a sample time of 200Hz. The 200Hz blocks would get executed at every solver time step, while the 100Hz blocks would get executed every second solver time step.
You should look at the Sample Times in Systems section of the documentation.
You can use both explicit and implicit rate control in Simulink.
Sample Time
To set the fundamental sample time go to: Configuration Parameter>Solver>Fixed-step size. You can also use the Simulink API:
get_param(bdroot, 'FixedStep')
set_param(bdroot, 'FixedStep', '0.005') % 200Hz
Colors
To activate the Sample Time colors go to: Display>Sample Time>All. The Sample Time Legend will help you understanding how the implicit rate control works.
Sample time Option
You can control the tasking and sample time options via: Configuration Parameter>Solver>Tasking and sample time options.
At the beginning you can activate the automatic handling of rate transition for data transfer. Then you shall analyse what colors your model elements are and place the Rate-Transition blocks on the data signal lines between the model elements with different sample rates.
Now the rate control is implicit. If you use the function calls to explicitly call your subsystems at a required rate by involving a predefined scheduler, than the rate control is explicit.
You can open build in Simulink examples to see how it works:
sf_ladder_logic_scheduler
sf_loop_scheduler
I am new to Simulink and try to achieve the following:
I have a signal which simulates output power of an engine. I now want to be able to change this power output to a new value.
My question: How do I implement a linear adjustment from the current output to the newly requested output? Linear in the sense of a constant rate of change, e.g. x Watt/second.
Thanks!
The simplest way to handle this is probably the Rate Limiter block.
If you cause a step-change in the demand, the rate limiter will take the demand as an input and produce an output with the rate of change limited to the rate specified in its dialog parameters.
There is a dynamic version if you want the maximum slew rates to be specified via signals.
I am using the Lomb-Scargle code to estimate some frequencies in a short time-series, the time series is shown in the first image. The results of the Lomb-Scargle analysis are shown in the second, and I have zoomed in on a prominent peak at about 2 cycles per day. However this peak is smeared and thus it is proving difficult to resolve the real frequency of this component. Is there any other methods, or improvements to the method I am using, to accurately resolve the important frequency components within this short time-series?
There is some information on the use of methods for short time series here but its not clear whether they need to be regularly sampled. Ideally I am looking for a method that works with irregularly sampled data, from some research it appears that maximum entropy methods are the answer, but I am not sure whether these have been implemented in MATLAB? Although from the this link, it appears that there is an equivalent method, 'The Yule-Walker AR method produces the same results as a maximum entropy estimator. However again its not clear whether the data need to be uniformly sampled?
I believe I am doing something fundamentally wrong when trying to import and test a transfer function in Simulink which was created within the System Identification Toolbox (SIT).
To give a simple example of what I am doing.
I have an input which is an offset sinusoidal wave from 12 seconds to 25 seconds with an amplitude of 1 and a frequency of 1.5rad/s which gives a measured output.
I have used SIT to create a simple 2 pole 1 zero transfer function which gives the following agreement:
I have then tried to import this transfer function into Simulink for investigation in the following configuration which has a sinusoidal input of frequency 1.5rad/s and a starting t=12. The LTI system block refers to the transfer function variable within the workspace:
When I run this simulation for 13 seconds the input to the block is as expected but the post transfer function signal shows little agreement with what would be expected and is an order of magnitude out.
pre:
post:
Could someone give any insight into where I am going wrong and why the output from the tf in simulink shows little resemblance to the model output displayed in the SIT. I have a basic grasp of control theory but I am struggling to make sense of this.
This could be due to different initial conditions used in SimuLink and the SI Toolbox, the latter should estimate initial conditions with the model, while Simulink does nothing special with initial conditions unless you specify them yourself.
To me it seems that your original signals are in periodic regime, since your output looks almost like a sine wave as well. In periodic regime, initial conditions have little effect. You can verify my assumption by simulating your model for a longer amount of time: if at the end, your signal reaches the right amplitude and phase lag as in your data, you will know that the initial conditions were wrong.
In any case, you can get the estimated initial state from the toolbox, I think using the InitialState property of the resulting object.
Another thing that might go wrong, is the time discretization that you use in Simulink in case you estimated a continuous time model (one in the Laplace variable s, not in z or q).
edit: In that case I would recommend you check what Simulink uses to discretize your CT model, by using c2d in MATLAB and a setup like the one below in Simulink. In MATLAB you can also "simulate" the response to a CT model using lsim, where you have to specify a discretization method.
This set-up allows you to load in a CT model and a discretized variant (in this case a state-space representation). By comparing the signals, you can see whether the discretization method you use is the same one that SimuLink uses (this depends on the integration method you set in the settings).
I have a Simulink xPC target application that has blocks with discrete states at several different sample rates and some sections using continuous states. My intention on keeping the continuous states is for better numerical integration.
What creates the problem: One block is reading a device at a very fast rate (500 hz). The rest of the application can and should run at a slower rate (say, 25 or 50 Hz) because it would be overkill to run it at the highest rate, and because the processor simply cannot squeeze a full application cycle into the .002 secs of the faster rate. So I need both rates. However, the continuous states run by definition in Simulink at the faster discrete rate of the whole application! This means everywhere I have continuous states now they're forced to run at 500 Hz when 25 Hz would do!
Is there a way to force the continuous states in xPC target to a rate that is not the fastest in the application? Or alternatively, is there a way to allow certain block to run at a faster speed than the rest of the application?
You are thinking about continuous solvers in the wrong way - continuous doesn't only mean that it's run as fast as possible - it uses a fundamentally different algorithm to solve the equations than discrete. Due to this, they must be run at least as fast as the discrete solvers.
From Using Simulink:
Continuous solvers use numerical
integration to compute a model's
continuous states at the current time
step from the states at previous time
steps and the state derivatives.
Continuous solvers rely on the model's
blocks to compute the values of the
model's discrete states at each time
step.
Mathematicians have developed a wide
variety of numerical integration
techniques for solving the ordinary
differential equations (ODEs) that
represent the continuous states of
dynamic systems. Simulink provides an
extensive set of fixed-step and
variable-step continuous solvers, each
implementing a specific ODE solution
method (see Solvers).
Discrete solvers exist primarily to
solve purely discrete models. They
compute the next simulation time step
for a model and nothing else. They do
not compute continuous states and they
rely on the model's blocks to update
the model's discrete states.
So the upshot is that no it's not good enough to have the continuous run more slowly than the fastest discrete solvers - otherwise they are, by definition, not continuous. You should reconsider why you are specifying them as continuous.
What are you trying to accomplish by slowing down the continuous solvers? Is this a simulation time/performance issue?
-Adam
My take on this is that it cannot be done. One way to approach this is to replace the continuous states by discrete ones (perhaps at an intermediate rate, say 100 Hz), and cross my fingers that the loss of precision is bearable.
Maybe it's possible to isolate a block and run it separately at a faster rate somehow, but I don't know.
Truly continuous computation is impossible in a digital processor such as your computer's.
What MATLAB/Simulink means by "continuous" is "I will (dynamically) try to guess what discrete step size is small enough so that discretization error is very small in your application".
If you already know, by knowing your application, that 20ms (50Hz) would be small enough, then use discrete - 50Hz.