how can i programmatically set and adjust initial conditions in simulink the right way?
4 views (last 30 days)
I have a simulink model to which i'm trying to implement tracking/control algorithm by re-initialization: I run the model, apply a bunch of machinery in the form of m-files to the output, and then change a few parameters, and try to restart the model from the state it was in with updated parameter values.
Things break unexpectely and it isn't clear why or how to correct it.
Here's what i'm doing internally, presented as minimally as i can muster but still be transparent:
SIMSYS = load_system('my_sim_model');
setActiveConfigSet( SIMSYS, 'Configuration1' );
cset = getConfigSet( gcs, 'Configuration1' );
set_param(cset,'StateSaveName', 'state_history'); % saving the 'output' states here in this object
tstart = time_intervals(k,1);
tend = time_intervals(k,2);
set_param(cset,'StartTime', string(tstart) );
set_param(cset,'StopTime', string(tend) );
if kk>1; %%% --- SET INITIAL STATE based on some point in previous output
set_param(cset, 'LoadInitialState','on'); % tell model to read from initial state
rststate = simOUT.state_history; %
[~,rst_kt] = min( abs(rststate.time - tstart) ); % get the index of the time point in the history closest to
% when i want to restart the model
rststate.signals(XXX) = ;
%??? ^^^ This line drops the history assoicated with the solver block, to avoid the following error:
% ``` signals(141).values field in the initial state structure has 1 element(s), where as the corresponding
% state 'Discrete' in block 'my_sim_model/Solver Configuration' has 2 element(s)```
% limit the restart state to the state at the time we want to restart
for rstkk = 1:length(rststate.signals);
rststate.signals(rstkk).values = rststate.signals(rstkk).values( rst_kt );
% Pass the restart state to the configset
set_param(cset, 'InitialState', 'rststate' );
% call the model
simOUT = sim( gcs, cset );
% apply a function to update some parameters, based on simout and some other monitors:
end %for kk
The number of elements in the state_history is 141, so XXX=141 in the questionable line above drops the solver block. The restart state should thus have 140 elements. The removed field is always at the end of the history (so far); i'm not removing anything in the middle of the blocks that would offset the ordering.
This approach (stop, lookup history, write history to intiial state, restart) worked before, but then i added some blocks to the model. It runs 9 times through the loop, and on the 10th time it errors:
Error my_simulink_wrapper_script (line 255)
Unable to load the specified initial state for model 'my_sim_model'. Cannot find
a matching block state corresponding to element 140 of signals structure array
However, when i debug into the 10th iteration where it breaks,
struct with fields:
So the 140th element is defined and is passed to the model's cset. I have no idea why it breaks. Is there perhaps some mismatch in the ordering of the output states and the order expected for the input states? If that's the case, where can i find the expected order of the inputs?
As an experiement: When i also remove the 140th element from the history to update, I get an error: ``Cannot find a matching block state corresponding to element 137 of signals structure array" on the 8th iteration of the loop. There' something inconsistent, and makes me think it's buried in the cset and initial state block ordering.
There doesn't seem to be a way to peak inside the configuration set:
>> get_param(cset,'InitialState') % returns the variable name i pass to it
There has got to be a more reasonable way to see inside the config set and to handle programmatically (viz non-gui) initial conditions, and understand why it works 9 times fine and errors unclearly on the 10th (or 7 and errors on the 8th, etc). Any advice, tips, or stimulating questions welcome.
I feel like i'm missing something obvious in the simulink documentation, but i can't seem to find anything relevant.
And yes, i know simulink has parameter estimation and control apps; we're not using those for a reason.