I have a question about my triggered subsystem in Simulink:
So the Susbsystem is executed every 0.01 s.
My question is: how can I get this variable (0.01) inside my subsystem?
NB: I don't need the Simulation step time.
I've already thought to two solutions:
1) use a Digital Clock with a Memory block
2) use a Weighted Sample Time block
but, both of them gave me an initial value of 0.
Do you have an elegant solution for my task
Thank you very much.
Have a nice day
The easiest solution is to have a constant block feeding into the subsystem. Define a MATLAB Workspace variable dt=0.01; and have the constant set to dt, and the sample rate of your Pulse Generator set to dt.
Alternatively you can use the Probe block to get the Sample Rate of the signal coming out of the Pulse Generator, and feed that as an input to the Subsystem.
Another way is to use get_param() command in your workspace.
In your case, it should be:
get_param('<path-to-block>/Pulse Generator','Period')
This should output:
>> ans =
0.01
I had this same problem myself. I received the following feedback from MATHWORKS when I reported it as a bug:
If triggered subsystems are executed on edge detection on the triggering event then it will require at least two model execution time steps in order to satisfy the triggering condition. As a result the triggered subsystem will not execute at 0 causing the results you are seeing. This is expected behavior.
If you require the triggered subsystem to execute on the first timestep you can change the "Trigger type" option to "function call." This option will execute the subsystem or model when the control signal receives a function-call event from a Statflow chart, Function-Call Generator block, or an S-function block." In this case you will just need to confirm that your function call block executes prior to the triggered subsystem block. This can be confirmed using the "Blocks - Execution Order" Debug tool under "Information Overlays."
Related
I have two Matlab function blocks that one is producing zero signal for the other. I want to store the exact time that signal changes to one in another parameter in order to use it elsewhere.
How can I do it?
This type of functinality is achieved using a Triggered Subsystem, as per the image below,
The output of the trigger block will take on value of the input (which in this case is the simulation time) every time the trigger signal rises. Look at the parameters of the Trigger block inside the subsystem for other options such as falling edge, or both edge, triggering.
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.
I have designed a signal by using the Signal Builder block in Simulink. During the run of my simulation, the signal builder is to restart depending on the satisfaction of a condition. The condition can be satisfied many times, so, the signal should start from the beginning each time. If I want to put it in another way: You can take step input instead of the designed signal. Step input is to be reset conditionally. How can I make it?
I haven't seen such a functionality built-in Simulink (maybe the newer versions have it?) but here is a workaround:
You can simulate passed time with an integrator that has a Constant block set to 1 as input. The point is that the integrator block has a reset port which you can connect to your condition. So, when your condition becomes true, the integrator restarts a time variable from 0 (which is set in the initial conditions). Beforehand, you need to have your signal saved in something like a Table Lookup block, which outputs the signal as a function of time. Then you connect the integrator output to the Table Lookup block.
Have you tried putting your Signal Builder block in an enabled subsystem? You probably need to set the states when enabling to reset for it to work. Have a look at Create an Enabled Subsystem in the documentation for more details.
I am trying to control a simulink from a M-file.
What I want to do in the M-file is give the simulink model some input, run the simulink model, change one input value at 0.6 seconds, continue running the simulink model with the new input.
I already know that by using set_param, I can start, pause and continue the simulink, but the problem is I don't know how to pause the simulink model at a certain time(0.6s), is it possible to get the current time from simulink model and read it in the M-file?
Another way I already know is using sim to run simulink model from 0 to 0.6s, and use SimState to save the information at 0.6s, then load these information to resume the simulation. I am trying to change the input before the simulation resumed, but it seems that the model will load the input values from the information it saved, it won't take the new input value.
I stuck in this problem for a very long time, could someone help me with this please?
Thank you very much.
You can get the current time of a running simulation with:
get_param('simulink_model_name', 'SimulationTime');
So for instance by checking this value from your M-file during simulation by using
timer(...)
you can detect when the simulation is at 0.6 seconds.
I used a combination of simulink and m-script to achieve a similar goal.
In your model, add one 'assert' block. Double click it, and uncheck 'Stop Simulation when assertion fails'. In the 'Simulation Callback when assertion fails' field, add three commands:
set_param(bdroot,'SimulationCommand','pause');
run('myscript.m'); %insert the script name
set_param(bdroot,'SimulationCommand','continue');
Now connect the inport of this block to a 'not equal to' relational operator. Connect the first inport of the relational operator to a clock (pls set the decimation for analog clock or the sample time [usually -1 for inherited] for the digital clock).
The second inport is connected to constant block with a value of 0.6
On simulating the model, the simulation will pause at 0.6 sec, execute the m-file to change the input parameter (considering that it's tunable) and then continue with the simulation.
The assertion block is called when its input signal becomes 0. At 0.6 sec, the output of the relational operator will be 0.
Let me know if it worked.
This is not currently possible from an M-file. If you want to dynamically change the input at a given time externally, it will require an S-Function. Even this solution is difficult and wrought with flakey-ness since the Mathworks does not want to support this functionality in that it defeats one of the features of another toolbox they sell. In time, I believe they will grant this privledge, but it does not exist today. Also, why not use a dynamic input block to change the input value, like a map, signal builder, etc. ?
I'm using Psychtoolbox in MATLAB to run a behavioral psychology paradigm. As part of the paradigm, users have to view a visual stimulus and respond to it using some input mechanism. For a keyboard, this works as follows:
show stimulus
poll keyboard for response
if no response detected, loop back to 1
if response detected, break and move on with script
This works fine for a keyboard, as step 2 takes between 1-2 ms. The problem comes when I use an alternate input mechanism; in that case, step 2 takes ~20 ms. (I need this alternate input to run the study, and that should be considered immutable fact.) As the stimulus changes with a very short timespan, this added delay breaks the task.
My current thought is to try to use the parallel processing, such that one thread shows the stimulus, and another thread polls the keyboard. I'm currently using the Parallel Computing Toolbox to do this. The problem I'm having is that I don't know how to direct keyboard input to a "parallelized" thread. Does anyone know (1) whether it's possible to direct keyboard input to a thread / have a thread send a visual signal to a monitor, and if yes, (2) how to do it?
Also, if anyone has any better ideas as to how to approach this problem, I'm all ears.
According to this MATLAB newsgroup thread, it appears that threads can't modify graphics objects. Only the desktop MATLAB client can do that. This means that you can't handle updating of graphics from a thread, and I can confirm this as I tried it and wasn't able to modify figures or even the root object from a thread.
However, I think you may be able to do the main graphics updating in MATLAB while a thread handles polling for your input. Here's a sample function for continuously updating a display until a thread waiting for input from KbCheck is finished running:
function varargout = plot_until_input
obj = createJob(); %# Create a job
task = createTask(obj,#get_input,4,{deviceNumber}); %# Create a task
submit(obj); %# Submit the job
waitForState(task,'running'); %# Wait for the task to start running
%# Initialize your stimulus display here
while ~strcmp(get(task,'State'),'finished') %# Loop while the task is running
%# Update your stimulus display here
end
varargout = get(task,'OutputArguments'); %# Get the outputs from the task
destroy(obj); %# Remove the job from memory
%#---Nested functions below---
function [keyIsDown,secs,keyCode,deltaSecs] = get_input(deviceNumber)
keyIsDown = false;
while ~keyIsDown %# Keep looping until a key is pressed
[keyIsDown,secs,keyCode,deltaSecs] = KbCheck(deviceNumber);
end
end
end
I was able to successfully run the above function with some simple plotting routines and replacing the code in get_input with a simple pause statement and a return value. I'm unsure whether KbCheck will work in a thread, but hopefully you will be able to adapt this for your needs.
Here's the documentation for the Parallel Computing Toolbox functions used in the above code: createJob, createTask, submit, waitForState, destroy.
I don't know of a way how you could do this with parallel processing.
However, a feature you might be able to use is the timer object. You would set up the timer object to poll the input mechanism, and, if anything is detected, change the value of a global variable. Then, you start your stimulus routine. In the while-loop in which you're updating the display, you keep checking the global variable for a change from the timer object.
You have to tackle the 20ms latency in your input device. If it's too slow then get another input device. You can get good sub-millisecond timing with proper response boxes.
All this talk about threading is misguided and not applicable to the PTB framework.