Execution order of MATLAB function blocks

I had to transfer some MATLAB code into a Simulink model. As the MATLAB code was split into multiple functions I interpreted each of them as a MATLAB function block in Simulink. The functions themselves do not have a clear input-output connection (the output of one does not have to be the input of the next executed function) so in order to define the order in which they are to be executed I used the Digital Clock block - every MATLAB function block has a digital clock input (clock), inside the function there is an if rem(clock,n)==m the function is executed (else the output values are not changed).

Now I have gotten the right results (compared to the original MATLAB code) but the Simulink model runs very slow. I am sure this is not the best way to solve my problem, but is there a way for me to make the execution faster - changing the solver type (I need it to be fixed-step though), sampling time of the digital clock...? Or alternatively a different way to define the execution order of MATLAB function blocks.

Thank you

Answer 1

[Walter Roberson]

You seldom need to define the execution order of MATLAB Function Blocks, unless the execution involves real-time factors (such as needing to wait until after a particular packet has been received.)

You typically just make the appropriate data connections and let Simulink work out the execution order. If a block needs two inputs and one of the inputs needs more blocks of transformation than the other, Simulink will take care of the details of when to execute and what the timestep associated with each item is.

You might potentially need to put a Zero Order Hold or Transfer Function or similar, but see https://blogs.mathworks.com/simulink/2015/07/18/why-you-should-never-break-an-algebraic-loop-with-with-a-memory-block/ and https://blogs.mathworks.com/simulink/2011/09/20/troubleshooting-the-transport-delay-block/ and https://blogs.mathworks.com/simulink/2011/07/25/are-you-using-the-right-block/

The various kinds of delay can be used to model timing imposed by external constraints (e.g., you might know that a signal is going to hardware that is clocked and will need such-and-such a time to process), but frobbing on the realtime clock is almost always the wrong way to go. It messes up behaviour on the various simulation modes for example -- and do you really want to have jumps in your model response if you pause for debugging?