Guy on Simulink

My Repository of AI Skills for Simulink

Guy Rouleau — Mon, 13 Apr 2026 01:41:20 +0000

Last week, MathWorks released the MATLAB Agentic Toolkit.

This toolkit packages tools and skills ready to use in your favorite agentic coding tool (Claude Code, GitHub® Copilot, Cursor, OpenAI® Codex, Sourcegraph Amp, Gemini CLI). It provides guidance for the AI coding agent to do things like build apps, create tests, create live scripts, through the MATLAB MCP server.

While we are waiting for an Agentic Toolkit focused on Simulink, I thought I should share a set of skills I developed in the last few weeks in this GitHub Repository:

simulink/skills: A collection of Simulink skills for agentic coding tools by Guy on Simulink.

You can use those skills today with the MATLAB MCP server, see my previous posts for how to set that up.

For now, the repository contains 6 skills:

simulink-interactions
simulink-simulation
simulink-baseline-test
simulink-profiler-analyzer
simulink-solver-profiler-analyzer
simulink-profile-initialization

Let see what each of them do.

simulink-interactions

The idea with this simple skill is to make it straightforward for the AI agent to know which Simulink component I want to interact with. It starts with this table:

User says	Resolution
"this model"	bdroot
"this system" / "this subsystem"	gcs
"this block"	gcb
"selected blocks" (plural)	see snippet below
"all [Type] blocks in this subsystem"	see snippet below
"all [Type] blocks in the model"	see snippet below

Where the "snippets below" are a few lines of code like this one, to find all selected blocks:

opts = Simulink.FindOptions;

opts.SearchDepth = 1;

blks = getfullname(Simulink.findBlocks(gcs, 'Selected', 'on', opts));

I find that this saves me some typing when time comes to tell the agent which model component to interrogate or modify. I use it when I need to do things that would otherwise require many clicks, or to write 10-20 lines of code to do. A few examples:

Set all models blocks to accelerator mode
Set the interpolation method of all selected lookup table blocks to Akima Spline
Enable interpolation in all Inports block at the root-level of the model

This skill also contains basic editing instructions, like how to use add_block and Simulink.connectBlocks. 

simulink-simulation

I find this skill very important. Because AI agents have been trained on whatever is available on the internet, they tend to use old syntax instead of the latest and greatest recommended best practices. While the code it generates is valid, it is often not ideal.

The skill includes best practices like:

Always simulate using Simulink.SimulationInput and Simulink.SimulationOutput
Everything that needs to be passed to the sim command must be through the Simulink.SimulationInput object
How to specify input signals through MATLAB timeseries stored in a Simulink.SimulationData.Dataset.
How to run multiple simulations using an array of Simulink.SimulationInput objects

For example, I asked Claude: "Write a MATLAB live script to simulate model HelicopterModelingSimulation for the 3 possible values of variable "state"". Without the skill, the code simulating the model looks like this:

model = "HelicopterModelingSimulation";

states = ["hover", "level", "path"];

load_system(model);

results = struct();

for i = 1:numel(states)

    state = states(i);  

    simout = sim(model);

    results.(states(i)) = simout;

end

With my skill, the code I get is:

modelName = "HelicopterModelingSimulation";

states = ["hover", "level", "path"];

in(1:numStates) = Simulink.SimulationInput(modelName);

for k = 1:numel(states)

    in(k) = in(k).setVariable('state', states(k));

end

out = sim(in);

Both codes are valid, but the second version is better for many reasons. The first code would have problems when used in context like parsim, rapid accelerator and Simulink Compiler. The first code would also fail when run from an app or a function because variable state would be written to the local workspace and not the MATLAB base workspace.

If you have existing code simulating Simulink models, try asking something like: "Use skill simulink-simulation to improve the code simulating a Simulink model in myFile.m". The coding agent should respond with something like this:

simulink-baseline-test

This skill creates a simple baseline test class for a Simulink model. It's useful when you ask the coding agent to refactor an existing model and validate that the results don't change, as I did in my previous post.

Without this skill, if I ask the AI to generate a baseline test, I find that it has a tendency to do more than what I need. It also has a tendency to add a teardown that closes the model after runnig the test. This is inconvenient when I have the model opened and want to look at it once the AI is done with its modifications.

Here is what a typical test class looks like:

classdef MyModelBaselineTest < sltest.TestCase

    properties (Constant)

        ModelName    = 'MyModel'

        BaselineFile = fullfile(fileparts(mfilename('fullpath')), 'baselineData.mat')

        RelTol = 1e-6

        AbsTol = 1e-8

end

    methods (TestClassSetup)

        function loadModelAndBaseline(testCase)

            wasLoaded = bdIsLoaded(testCase.ModelName);

            load_system(testCase.ModelName);

            if ~wasLoaded

                testCase.addTeardown(@()close_system(testCase.ModelName, 0));

end

            testCase.assertTrue(isfile(testCase.BaselineFile), ...

                sprintf('Baseline not found: %s\nRun %s.generateBaseline() first.', ...

                testCase.BaselineFile, mfilename('class')));

end

end

    methods (Test)

        function testAllSignalsMatchBaseline(testCase)

            in  = Simulink.SimulationInput(testCase.ModelName);

            out = sim(in);

            S = load(testCase.BaselineFile, 'baselineLogsout');

            testCase.verifySignalsMatch(out.logsout, S.baselineLogsout, ...

                'RelTol', testCase.RelTol, ...

                'AbsTol', testCase.AbsTol);

end

end

    methods (Static)

        function generateBaseline()

            modelName = MyModelBaselineTest.ModelName;

            load_system(modelName);

            in  = Simulink.SimulationInput(modelName);

            out = sim(in);

            baselineLogsout = out.logsout; 

            save(MyModelBaselineTest.BaselineFile, 'baselineLogsout');

            fprintf('Baseline saved to: %s\n', MyModelBaselineTest.BaselineFile);

            close_system(modelName, 0);

end

end

end

Profiling Skills

In my everyday work, I spend a lot of time helping Simulink users make their simulations run faster. For that, I often need to interpret results from the different profilers available in MATLAB and Simulink. I created 3 skills for my most common profiling workflows:

simulink-profiler-analyzer: Interprets results from the Simulink Profiler
simulink-solver-profiler-analyzer: Interprets results from the Simulink Solver Profiler
simulink-profile-initialization: Combines results from the MATLAB Profiler and sldiagnostics with the goal of helping you speedup model initialization

Those 3 skills have a similar pattern where you can ask the AI agent to run the desired profiler, or just to interpret saved results, if you already ran the profiler manually. In the end, it generates an HTML report that lists the most expensive operations and provides advice on what could be potentially improved.

To give you an idea, I tried running the Solver Profiler on this example: Hydrostatic Transmission - MATLAB & Simulink

Here is what the results look like in the Solver Profiler:

Here is what the recommendations from my skill look like:

Disclaimer: Those skills are experimental and can be wrong. They have a tendency to flag more things as "High" than I would typically do. I am improving these every time I use them and will push updates as they evolve.

Now it's your turn

Have you created your own skills to guide AI Coding Agents with Simulink? If not, I encourage you to download mine and tweak them to your preferences. I would be very interested to hear what you come up with.

Refactoring a Simulink Model using the MATLAB MCP Server

Guy Rouleau — Thu, 26 Mar 2026 17:12:27 +0000

Once you start using those AI agents, it's hard to stop!

In today's post, I used Amp, an AI coding agent made by Sourcegraph and similar to Claude Code, to do one of the tasks I help Simulink users with the most: Improve the componentization of a model by using a referenced model in accelerator mode.

The Challenge

A best practice I always recommend to Simulink users and that we describe in the article Improving Simulation Performance in Simulink is to leverage referenced models in accelerator mode. Because they can be precompiled, they initialize instantaneously and simulate faster when they are not modified between simulations.

To highlight the workflow, I started with this example: Helicopter Modeling and Simulation - MATLAB & Simulink

If you want to open this example in your MATLAB, you can execute this command:

openExample('simulink_aerospace/HelicopterModelingAndSimulationExample')

As it is the case in most user models I see, a good candidate to be converted to a referenced model is typically the control logic, in this case the subsystem Attitude and Altitude Control: 

While Simulink includes a Model Reference Conversion Advisor that can do most of the work, it's common that something does not work as expected after doing the conversion. 

I knew that this example had some of those, so I thought it would be a good candidate to test an AI agent.

The Final Result

Let's first look at a video of how Amp succeeded at the task by iterating through the MATLAB MCP server.

What I described is:

What to do: Convert the Attitude and Altitude Control subsystem into a referenced model
My motivation: Improve performance by simulating the referenced model in accelerator mode
Requirement: I need to be able to change variants in the controller without triggering a rebuild of the accelerator target

I suggested that it should start by creating a baseline test to validate that the final results match the original model and let it iterate.

The Details

Let's now dissect what the AI agent did during this video.

Skills

As you might have noticed, Amp loaded 3 skills I created. Those are very basic skills and not intended to help with model reference conversion. Here is a quick overview and hyperlink if you want to download them:

simulink-interaction: To help the AI Agent be aware of what is happening in Simulink. For example: "this block" means gcb, "this model" means bdroot, "this subsystem" means gcs, etc. I find this helps me "talk" to it more naturally.
simulink-simulation: To guide the agent toward using the Simulink.SimulationInput object syntax instead of the older combination set_param and sim('modelname'). This is not necessary, but I prefer how the code looks.
simulink-baseline-test: Also not necessary, the AI agent can figure out how to write such a test on its own. I use it for minor things like having the proper setup and teardown I personally like.

While additional skills could have made the work of the AI agent easier, requiring less tokens and converging faster, what I wanted to observe in today's experiment is how well it would do without additional skills.

Baseline Test

Whether you're an AI agent or a human, a baseline test capturing the system's behavior is always a good thing to have before starting to modify it. In this case, the agent was able to inspect the model and identify that the variable state was controlling variant conditions. Here is one example block using state:

In the test, it made it a test parameter to capture one baseline per variant configuration.

classdef HelicopterBaselineTest < sltest.TestCase

    properties (Constant)

        ModelName    = 'HelicopterModelingSimulation'

        RefModelName = 'AttitudeAltitudeControl'

        RelTol = 1e-6

        AbsTol = 1e-8

end

    properties (TestParameter)

        variant = {'hover', 'level', 'path'}

end

    methods (Test)

        function testVariantMatchesBaseline(testCase, variant)

            baselineFile = fullfile(fileparts(mfilename('fullpath')), ...

                sprintf('baseline_%s.mat', variant));

            testCase.assertTrue(isfile(baselineFile), ...

                sprintf('Baseline not found: %s', baselineFile));

            in = Simulink.SimulationInput(testCase.ModelName);

            in = in.setVariable('state', FlightMode.(variant));

            out = sim(in);

            S = load(baselineFile, 'baselineLogsout');

            testCase.verifySignalsMatch(out.logsout, S.baselineLogsout, ...

                'RelTol', testCase.RelTol, ...

                'AbsTol', testCase.AbsTol);

end

Model Reference Conversion

This can be accomplished in one line of code:

blk = 'HelicopterModelingSimulation/Attitude and Altitude Control';

mdlName = 'AttitudeAltitudeControl';

Simulink.SubSystem.convertToModelReference(blk,mdlName,...

    "AutoFix",true,...

    "ReplaceSubsystem",true,...

    "SimulationModes","Accelerator",...

    "BuildTarget","Sim");

One problem: Logged signals at the boundary of the original subsystem got lost during the conversion. The agent was able to quickly fix that and re-enable logging for the correct signals.

Changing Active Variants Without Rebuild

In the original model, the variant subsystems were configured for: Variant Activation Time = Update Diagram.

With this setup, the referenced model would need to rebuild every time the active variant changes. We don't want that because rebuilding takes time. To avoid that, it's possible to change for Variant Activation Time = Startup.

Startup activation time comes with limitations; there is a full documentation page on that: Considerations and Limitations for startup Variant Activation Time - MATLAB & Simulink.

The agent ran into the following problems:

When using Startup, each variant choice must be atomic
In Startup, strings are not allowed in variant control expressions

Making the variant choices atomic was easy. To work around the second limitation, the agent decided to create an enumerated type to replace the string. This is exactly what I would have recommended to any user. Here is the original on the left and the fix on the right:

No Rebuild Requirement

I have to admit, Simulink does not provide a straightforward way to programmatically determine if a referenced model is being rebuilt or not. The agent tried a few techniques:

Record a diary of the MATLAB base workspace and parse the build summary
Compare the output of Simulink.BlockDiagram.getChecksum
Compare the datenum field returned by dir on the referenced model mex-file

It landed on this last option, and I am ok with that, that seems reliable enough.

        function testNoRebuildOnVariantChange(testCase)

            variants = {FlightMode.hover, FlightMode.level, FlightMode.path};

            % First simulation — cold build may occur

            in = Simulink.SimulationInput(testCase.ModelName);

            in = in.setVariable('state', variants{1});

            in = in.setModelParameter('StopTime', '0');

            sim(in);

            % Record the MEX file timestamp after first build

            mexFile = which([testCase.RefModelName '_msf']);

            testCase.assertNotEmpty(mexFile, ...

                'Accelerator MEX target not found after first simulation.');

            d = dir(mexFile);

            timestampAfterBuild = d.datenum;

            % Simulate with remaining variants and verify no rebuild

            for v = 2:numel(variants)

                in = Simulink.SimulationInput(testCase.ModelName);

                in = in.setVariable('state', variants{v});

                in = in.setModelParameter('StopTime', '0');

                sim(in);

                d = dir(mexFile);

                testCase.verifyEqual(d.datenum, timestampAfterBuild, ...

                    sprintf('Accelerator target was rebuilt when switching to variant %d.', v));

end

end

If you watch the video carefully, I asked one minor modification to make the test complete faster by simulating for a stop time of zero instead of running the entire simulation. The agent applied it instantly.

Conclusion

Overall, I am pretty happy with the process. The agent probably took longer and used more tokens than it could have with clearly defined skills, but it succeeded... and it did it faster than it would have taken myself doing the same manually.

Now it's your turn

I am sharing my experiments with AI coding agents and Simulink because I know many readers of this blog are early technology adopters and cannot wait to see how Simulink can fit in this new world. If you're interested and motivated, what I highlighted in this post, and the previous one, is possible today with a bit of "do-it-yourself" setup.

If you prefer to wait, many colleagues are actively working on agentic tools and features that will be fully integrated in the Simulink ecosystem and should be available soon. 

Simulink and Simscape modeling using Claude Code and the MATLAB MCP Server

Guy Rouleau — Thu, 26 Feb 2026 20:44:26 +0000

This week, I am going one step further in my exploration of AI agents and how they can help Simulink workflows. 

In previous posts, I went through the basics of connecting GitHub Copilot with the MATLAB MCP Server, and created a set of basic coding rules to generate MATLAB code simulating Simulink models.

This week, I am taking one step sideways and one step forward:

Instead of using GitHub Copilot, I switched to Claude Code
Instead of simulating an existing model, I am creating a new Simulink model

Let’s see how that turned out.

The Challenge

I received a request from a colleague that sounded like:

Using the currently available version of MATLAB, how feasible or complex would it be to leverage an AI agent to build a Simulink model? For example, let’s start simple and model the temperature of a cup of coffee slowly cooling to room temperature, something like what’s described in this post.

Something like that:

There is no better way to answer this question than trying, so I got myself a Claude Pro account and gave it a try.

The Final Result

Without much experience using Claude Code, I turned on screen recording and started from scratch.

Here is a video that covers the essentials of this first experience. I edited away the parts where I stepped out to do some research and sped up the boring parts where the AI is thinking. Otherwise, I kept most of what I actually went through.

The Details

Here is a breakdown of what I went through.

Initial Setup

After following the Claude Code Quickstart instructions and downloading the latest version of the MATLAB MCP server, I launched a Windows PowerShell and executed this line to add the MATLAB MCP Server to the Claude configuration file:

claude mcp add

 --transport stdio matlab

 -- "C:\Path_To_MCP_Server\matlab-mcp-core-server-win64.exe"

 --matlab-root=C:\MATLAB\R2025b

 --initialize-matlab-on-startup=true

 --matlab-display-mode=desktop "--initial-working-folder=C:\MyProjectPath"

With that done, from an empty folder I typed claude, and it launched a new MATLAB session.

The Plan

I put Claude in plan mode and described my high-level goal.

It proposed an initial model

After a few iterations, I liked the proposed plan.

Before asking it to start implementing the plan, I took a few minutes to read Best Practices for Claude Code. One tip that seemed important is: "The more precise your instructions, the fewer corrections you’ll need.". This led me to try two things:

Skills: Following the instructions to create skills, I wrote down a few bullets describing how I typically go about picking and connecting Simscape blocks
Incremental Development: When I create a Simulink model, I never draw the entire thing in one shot. I develop and validate incrementally.

Skills

In a skills.md file, I wrote down the same few tips I give to users who want to write MATLAB code to programmatically create Simscape models. Here are a few examples:

## Adding blocks

- Add blocks using `add_block('libraryPath/BlockName', 'modelName/BlockName')`

- Add blocks from Simscape shipping libraries: fl_lib, sdl_lib, SimscapeFluids_lib, nesl_utility

- Don't set the position of blocks explicitly.

- After adding Simscape blocks use auto-arrange: `Simulink.BlockDiagram.arrangeSystem('systemName')`

## Connecting blocks

- Connect Simscape physical ports using `simscape.addConnection(block1,port1,block2,port2)`

- Obtain ports info using `portsInfo = simscape.connectionPortProperties(block)`. portsInfo fields are Name, Label and ConnectionType

- Only connect together ports with same ConnectionType

## Simscape variables logging

- Get the default variable table: `table1 = simscape.instrumentation.defaultVariableTable('modelName/Block')`

- Enable logging: `table1("variable").Logging = true`

- Apply: `simscape.instrumentation.setVariableTable('modelName/Block',table1)`

With that skill, Claude was able to quickly build this simple model for one part of my problem:

It was able to validate that the temperature evolution was as expected in the plan:

Developing Incrementally

Another set of advice I always give to Simulink users is:

Develop incrementally
Validate often
Clean things up as you go

So, I asked Claude to implement and validate each heat transfer path before moving to the next one, cleaning things up in between by grouping each heat transfer path in separate subsystems. I did not try this time, but I think it should be possible to create an agent to help automating that... I'll keep that for a future post.

Once it was done and the whole model was validated, I only made manual cosmetic changes (moving and resizing blocks) to give the model the visual look I like to see in screenshots for this blog. Here is the final model. 

I included in this project (you can reach it on GitHub using the link at the top of the post) the AI-generated code and model. Try running the live script run_coffee_mug.m.

What's Next?

Based on what I went through during this first short experimentation, and after reading a little bit about tools, skills, and agents, I have a good feeling. Things are moving quickly and I'm pretty confident that we will soon be able to provide you with tools, skills, and agents to create and validate Simulink models from high-level requirements.

Now it's your turn

Have you started using AI agents with MATLAB and Simulink? Share your experiences in the comments below.

Understanding the C/C++ Code Generated from a Simulink model

Guy Rouleau — Mon, 29 Dec 2025 14:42:09 +0000

One of the key benefits of Simulink is that you can generate C/C++ code from the model using Simulink Coder and Embedded Coder.

However, I have to admit, looking at the code generated from Simulink for the first time can be intimidating. In this post, I will try to demystify that a little bit.

The Challenge

The first time you generate code from a Simulink model, you notice that a folder gets created with multiple files in it. If you open one of them, for example "modelname.c", you will see something like this:

This probably raises a lot of questions: What are all those functions and variables? Where do they come from? Is there a naming convention? Can I control how the variables are named? How do the equations in the C code relate to the blocks and signals in my Simulink model?

To help answer those questions, this post goes through the following:

The Simulation Loop: To understand the code generated from Simulink, it's important understand how Simulink models are simulated
Generated Code - Data Structures: How the block parameters, states, and signals are organized in the generated code
Generated Code - Optimization: Why the code is usually not a 1-to-1 mapping with the blocks and signals in the model
Generated Code - Customization: Get full control of the variables and data structures in the generated code

Let's get started!

The Simulation Loop

To understand the code generated from Simulink, you first need to understand how Simulink solves the equations implemented as blocks in a model. For that, I like to use a simplified version of the diagram from this documentation page: Simulation Phases in Dynamic Systems - MATLAB & Simulink.

Obviously, this diagram is a simplification of what Simulink actually does. To get the full picture, I recommend this page: Simulink Engine Interaction with C S-Functions - MATLAB & Simulink.

For models without continuous states (this is true for most code generation use cases where the user cares about the generated code), the equations for all blocks are solved in two groups:

Output: Simulink computes the output of all blocks as a function of their current inputs and states.

[y(k)]=f([u(k)],[x(k)])" style="vertical-align:-5px">[y(k)]=f([u(k)],[x(k)])

Update Discrete States: Simulink computes the value of the states for the next step, as a function of the block inputs and current states.

[x(k+1)]=f([u(k)],[x(k)])" style="vertical-align:-5px">[x(k+1)]=f([u(k)],[x(k)])

Now, let's look at a specific example.

Example: Discrete State-Space

In my opinion, the best classic example to illustrate the basics of how Simulink works is a Discrete State-Space system (State-space representation - Wikipedia). It results in one equation for the Output phase and one equation for the Update phase.

While Simulink includes a Discrete State-Space block, for the purpose of this blog post, I decided to implement it as typically seen in controls or dynamic systems books:

mdl = "testCG";

open_system(mdl)

This gives two equations:

Output:

y(k)=Cx(k)+Du(k)" style="vertical-align:-5px">y(k)=Cx(k)+Du(k)

Update Discrete States:

x(k+1)=Ax(k)+Bu(k)" style="vertical-align:-5px">x(k+1)=Ax(k)+Bu(k)

The Generated Code

If you generate code for the above model, you will see a folder like this being generated:

slbuild("testCG");

Functions

With the default settings (minus the comments), Simulink Coder produces three functions in testCG.c: initialize, step, and terminate:

void testCG_initialize(void)

{

  testCG_DW.UnitDelay_DSTATE = testCG_P.UnitDelay_InitialCondition;

}

void testCG_step(void)

{

  testCG_Y.y = testCG_P.C * testCG_DW.UnitDelay_DSTATE + testCG_P.D * testCG_U.u;

  testCG_DW.UnitDelay_DSTATE = testCG_P.A * testCG_DW.UnitDelay_DSTATE + testCG_P.B * testCG_U.u;

}

void testCG_terminate(void)

{

}

Most users prefer to see the Output and Update phases described above combined into a single function, so Simulink Coder combines them into a single Step function. There are options to control this behavior if desired.

Data Structures

To understand this code, let's look at how the data is organized. In most code generated from Simulink, you will find 4 data structures:

Inputs ("U"): a structure with one field per Inport
Outputs ("Y"): a structure with one field per Outport
Parameters ("P"): a structure with one field per parameter
States ("DW"): a structure with one field per state. (DW stands for Discrete Work vector)

Knowing that, we can find their declaration in the generated header file (testCG.h):

typedef struct {

  real_T u;                            /* '/u' */

} ExtU_testCG_T;

typedef struct {

  real_T y;                            /* '/y' */

} ExtY_testCG_T;

struct P_testCG_T_ {

  real_T A;                            /* Variable: A */

  real_T B;                            /* Variable: B */

  real_T C;                            /* Variable: C */

  real_T D;                            /* Variable: D */

  real_T UnitDelay_InitialCondition;   /* Expression: 0 */

};

typedef struct {

  real_T UnitDelay_DSTATE;             /* '/Unit Delay' */

} DW_testCG_T;

The values for block parameters are specified in the data file (testCG_data.c),:

/* Block parameters */

P_testCG_T testCG_P = {

  /* Variable: A */

  0.95,

  /* Variable: B */

  0.25,

  /* Variable: C */

  0.2,

  /* Variable: D */

  0.0,

  /* Expression: 0 */

0.0

};

For the initial state, the value is set in the initialize function (testCG.c)

/* Model initialize function */

void testCG_initialize(void)

{

  testCG_DW.UnitDelay_DSTATE = testCG_P.UnitDelay_InitialCondition;

}

To observe the relationship between the blocks in the model and the generated code, I recommend opening the Code Panel. This feature enables bi-directional highlighting: you can hover over parts the code and the corresponding blocks get highlighted, or you can click on blocks in the canvas and the corresponding code gets highlighted:

A little bit more about block parameters

While inputs, outputs, and states map to individual modeling elements, parameters can be used in multiple blocks, and this is reflected in the generated code. Let's take this simple example where I use a variable "b" in both the Bias and Gain block:

 The comments in the data file (testCG_custom1_data.c) indicates that the same C code variable is used by two blocks:

/* Block parameters (default storage) */

P_testCG_custom1_T testCG_custom1_P = {

  /* Variable: b

   * Referenced by:

   *   '/Bias'

   *   '/Gain'

*/

2.0

};

In the equation for the step function, we can confirm that the same variable "testCG_custom1_P.b" is used for both the bias and the gain:

void testCG_custom1_step(void)

{

  testCG_custom1_Y.y = (testCG_custom1_U.u + testCG_custom1_P.b) * testCG_custom1_P.b;

}

Optimization

At this point, you might be wondering:

You said that Simulink computes the output and states of each block. The model has 10 blocks, and I only see two equations, what happened?

The answer is simple: By default, Simulink Coder optimizes the generated code!

Simulink has tons of optimization settings that I will not cover in detail here. Personally, the most frequent reason I have to disable optimizations is debugging, to inspect intermediary variables more easily. 

This can easily be set in the model configuration:

Programmatically, this can be done using:

set_param("testCG","OptimizationLevel","level0");

And we now get one line of code per block:

void testCG_step(void)

{

  /* UnitDelay: '/Unit Delay' */

  testCG_B.x = testCG_DW.UnitDelay_DSTATE;

  /* Gain: '/GainC' */

  testCG_B.GainC = testCG_P.C * testCG_B.x;

  /* Gain: '/GainD' */

  testCG_B.GainD = testCG_P.D * testCG_U.u;

  /* Outport: '/y' */

  testCG_Y.y = testCG_B.GainC + testCG_B.GainD;

  /* Gain: '/GainA' */

  testCG_B.GainA = testCG_P.A * testCG_B.x;

  /* Gain: '/GainB' */

  testCG_B.GainB = testCG_P.B * testCG_U.u;

  /* Sum: '/SumAB' */

  testCG_B.xk1 = testCG_B.GainA + testCG_B.GainB;

  /* Update for UnitDelay: '/Unit Delay' */

  testCG_DW.UnitDelay_DSTATE = testCG_B.xk1;

}

As you can see, this introduces a new data structure ("B"), containing the output of the individual blocks.

Don't forget to switch back the optimization level to maximum when you're done debugging!

set_param("testCG","OptimizationLevel","level2");

Customization

In many cases, you don't need and don't want to customize the generated code. In fact, if you generate code for Rapid Prototyping or Hardware-In-the-Loop simulation, you probably don't even need or want to look at the generated code!

However, in some cases, you might have a good reason for wanting to customize the generated code. Good news, with Embedded Coder, it is possible to customize almost everything in the generated code.

One common and simple use case is the need to interface with hand-written code. For that, you want to tell Simulink Coder that a specific modeling element should become a specific variable in the generated code. Let's look at two examples of that.

Customization 1: Exporting a State

Let's say that we want the generated code to read and write the state of the Unit Delay block in our state-spate system to a variable named "x" that the hand-written code will be able to access. 

Customization 2: Exporting a Signal

As discussed in this previous post, another common customization is to retain a specific signal in the generated code. For our state-space example, let's say we want to be able to access "A*x" and "B*u":

To implement those two customization, you can use the Code Mapping Editor. Go to the Signals/States tab, and change the Storage Class of the state of the Unit Delay block and of the two signals Ax and Bu to ExportedGlobal. In the Property Inspector, you can specify the Identifier you want to appear in the generated code:

With that change, the generated code becomes:

void testCG_step(void)

{

  testCG_Y.y = testCG_P.C * x + testCG_P.D * testCG_U.u;

  Ax = testCG_P.A * x;

  Bu = testCG_P.B * testCG_U.u;

  x = Ax + Bu;

}

When generating code for the simple examples I publish on this blog, I like to abuse this capability a little bit. With a few more clicks in the Code Mapping Editor, I can turn the generated code into this:

void testCG_step(void)

{

  y = C * x + D * u;

  x = A * x + B * u;

}

You probably don't want to go that extreme for the code generated for your application!

Now it's your turn

I think it's enough for an intro to the C/C++ code generated from Simulink Coder. Let us know in the comments below if there are other code generation related topics you would like to see covered on this blog.

MATLAB AI Coding Standards for Simulating Simulink Models

Guy Rouleau — Mon, 15 Dec 2025 14:02:17 +0000

In my previous post, I went through the basics of using GitHub Copilot and the MATLAB MCP Server to generate MATLAB code that can simulate a Simulink. While the AI-generated code simulated the model to completion, it had multiple issues, including:

Unnecessary logic for my application
Old syntax going against recommended modern best practices
Unexpected simulation results
Simply not the style I like

In this post, I will define coding instructions to guide the copilot such that it will generate the code I want at the first iteration.

MATLAB AI Coding Rules

Are you aware of this repository?

github.com/matlab - MATLAB Development & AI Coding Projects

It contains a set of coding rules optimized for use with AI coding assistants like Cursor, Windsurf, Claude Code, and GitHub Copilot.

Unfortunately, as of today, none of those rules apply specifically to Simulink models. It's time to change that!

Here is my first attempt at defining AI coding rules for MATLAB code simulating Simulink models.

Disclaimer: The rules defined in this post do not try to be general rules that all users should follow when simulating a Simulink model. Some are general best practices I encourage everybody to follow, for example using the Simulink.SimulationInput syntax. Others are specific to the code I like to see on this blog when simulating a model.

Coding Rules to Simulate Simulink Models

For this first attempt, I will focus on rules to generate MATLAB code I like to see on this blog to simulate Simulink models and plot results.

To begin, let's write down a few high-level requirements for the code I like to see:

Use the Simulink.SimulationInput object syntax.
Input signals to be passed through root-level Inport blocks should be stored as timeseries.
Signals are logged in a Simulink.SimulationData.Dataset object and the individual signals stored as timeseries.
The code plotting simulation results should be as short and simple as possible.

Using the Coding Rules

As instructed in the MATLAB AI Coding rules readme.md, I stored those rules in a markdown file named .github/copilot-instructions.md

By the way, did you know that the MATLAB Editor is now able to display markdown files?

I typed my request in the GitHub Copilot chat, and it immediately created a first version of the script stepSim.m.

Create a MATLAB script named stepSim.m that simulates the Simulink model BasicModelingSimpleSystem.slx with a step input signal and plots the logged signal 'x'.

The generated code is not exactly what I want, but it's closer than the first attempt in my previous post.

% Model name

modelName = 'BasicModelingSimpleSystem';

% Load the model

load_system(modelName);

% Get the stop time from model

stopTime = str2double(get_param(modelName, 'StopTime'));

% Create time vector for step input signal

t = linspace(0, stopTime, 1000);

F_data = ones(size(t));

% Create step input as timeseries

F = timeseries(F_data, t);

% Create input dataset

simInput = Simulink.SimulationInput(modelName);

simInput = simInput.setExternalInput(F);

% Simulate the model

simOut = sim(simInput);

% Extract logged signals and plot 'x'

x_signal = simOut.logsout.getElement('x');

figure('Name', 'Step Response', 'NumberTitle', 'off');

plot(x_signal.Values.Time, x_signal.Values.Data, 'LineWidth', 2);

xlabel('Time (s)');

ylabel('x');

title('Step Response of BasicModelingSimpleSystem');

grid on;

While this works, here are a few things I would like to tweak:

There is no need to use load_system before simulating a model. The sim command will load the model if needed.
I prefer to use in instead of simInput for the Simulink.SimulationInput object.
I prefer to use out instead of simOut for the Simulink.SimulationOutput object.
When plotting simulation results, I prefer to use the plot method of MATLAB timeseries, instead of extracting the time and data vectors.

Based on this result, I went through a series of iterations, adding more and more specific rules.

In the end, I came up with this set of rules: copilot-instructions.md

## Usage of the sim command to Simulate Simulink models

### General syntax

- Simulink models should always be simulated using the sim command

- The sim command should be used with the syntax "out = sim(in)", where "in" is a Simulink.SimulationInput object and out is a Simulink.SimulationOutput object.

- Use the variable name "in" for the Simulink.SimulationInput object.

- Use the variable name "out" for the Simulink.SimulationOutput object.

- Avoid using set_param for simulation. All parameters should be set through Simulink.SimulationInput methods.

- Avoid using load_system or open_system for simulation. Models will be loaded automatically by the sim command.

- Model parameters should be specified using the Simulink.SimulationInput method setModelParameter.

- Block parameters should be specified using the Simulink.SimulationInput method setBlockParameter.

- New values for MATLAB variables used by the Simulink models should be specified using the Simulink.SimulationInput method setVariable.

### Input signals

- Input signals should be passed to the model using Inport blocks.

- The values for the individual input signals should be stored in MATLAB timeseries. 

- The timeseries should be combined into a Simulink.SimulationData.Dataset. For example: "ds=Simulink.SimulationData.Dataset;ds{1} = myTimeseries;"

- The Simulink.SimulationData.Dataset should be specified using the Simulink.SimulationInput method setExternalInput. For example: "in = in.setExternalInput(ds);"

### Data logging

- Data is logged in dataset format.

- Logged data can be accessed through the logsout field of the Simulink.SimulationOutput object, for example "out.logsout".

- Logged signals can be accessed by name using the get method, for example: "out.logsout.get('signalName')"

- Logged signals should be plotted using the timeseries plot command, for example: "plot(out.logsout.get('signalName').Values)"

- Avoid creating unnecessary variables when accessing logged data. Access logged data directly from the Simulink.SimulationOutput object. For example, use "out.logsout.get('signalName').Values" instead of creating a separate variable for the logged signal.

- Avoid unnecessary validation of the Simulink.SimulationOutput object. Assume the sim command returns a valid object. No try-catch or validation code is needed.

- A Simulink.SimulationOutput does not have a isfield method. Do not use isfield to check for logged data.

I repeated my original query. This time, the generated code is exactly what I was hoping for:

% Simulation end time (seconds)

tEnd = 10;

% Create a step timeseries: 0 for t < 1, 1 for t >= 1

t = linspace(0, tEnd, 1001)';

u = double(t >= 1);

stepTS = timeseries(u, t);

% Package into a dataset for external input

ds = Simulink.SimulationData.Dataset;

ds{1} = stepTS;

% Create SimulationInput using the model name (Simulink will load the model automatically)

in = Simulink.SimulationInput('BasicModelingSimpleSystem');

in = in.setModelParameter('StopTime', num2str(tEnd));

in = in.setExternalInput(ds);

% Run simulation

out = sim(in);

% Plot the logged signal 'x'

plot(out.logsout.get('x').Values);

title('Logged signal: x');

xlabel('Time (s)');

grid on;

Now that I have that working, let's keep exploring.

MATLAB Test Class

For my next experiment, I tried creating a MATLAB-Based Simulink Test:

Simulate the Simulink model BasicModelingSimpleSystem.slx for a step input, capture the signal "x" and store it in a MAT-file to be used for baseline validation.

Create a MATLAB Test class that simulates the Simulink model BasicModelingSimpleSystem.slx do baseline validation using the saved MAT-file.

I was pretty happy with the results. It created 3 files:

A script to generate and save the baseline
A MAT-file containing the baseline results
The requested MATLAB Test class

Here is what the MATLAB Test class looks like. It's simple and follows my coding rules.

classdef TestBasicModelingSimpleSystem < matlab.unittest.TestCase

    % Test class for baseline validation of BasicModelingSimpleSystem.slx

    methods (Test)

        function testBaselineX(testCase)

            % Simulation end time

            tEnd = 10;

            t = linspace(0, tEnd, 1001)';

            u = double(t >= 1);

            stepTS = timeseries(u, t);

            ds = Simulink.SimulationData.Dataset;

            ds{1} = stepTS;

            in = Simulink.SimulationInput('BasicModelingSimpleSystem');

            in = in.setModelParameter('StopTime', num2str(tEnd));

            in = in.setExternalInput(ds);

            out = sim(in);

            x_actual = out.logsout.get('x').Values;

            % Load baseline

            baseline = load('x_baseline.mat', 'x_baseline');

            x_baseline = baseline.x_baseline;

            % Compare signals (allowing for small numerical differences)

            testCase.verifyEqual(x_actual.Data, x_baseline.Data, 'AbsTol', 1e-8);

            testCase.verifyEqual(x_actual.Time, x_baseline.Time, 'AbsTol', 1e-8);

end

end

end

I could add more rules to refine this test class, but I think this will be enough for today.

Now it's your turn

What kind of Simulink AI Coding Rules would you like to see? Which AI coding assistant is your favorite? Let us know in the comments below.

Simulating a Simulink Model through GitHub Copilot and the MATLAB MCP Server

Guy Rouleau — Wed, 10 Dec 2025 15:39:23 +0000

Today I am continuing my exploration in the world of AI coding assistants and how they can help with Simulink. The topic for this post: The MATLAB MCP Server.

MATLAB MCP Server

MathWorks recently released the first version of the MATLAB MCP Core Server on GitHub. 

If you're not familiar with the Model Context Protocol (MCP), you might want to give a quick look at the Wikipedia page: Model Context Protocol - Wikipedia. In short, it's a protocol adopted by the major AI providers like OpenAI and Anthropic to interface with... well... pretty much everything.

MathWorks providing an MCP server means that tools like Claude Desktop and GitHub Copilot in VS Code are now able to ask MATLAB to run the code they generate, get the output back and iterate on their own. As my colleagues Yann Debray and Akshay Paul described in their introduction blog post, no more need for a human to manually copy and paste code between tools!

In this post, I will walk you through my first attempt at generating MATLAB code to simulate a Simulink model using GitHub Copilot in VS Code.

Disclaimer: I would really prefer to do everything I am describing today within the MATLAB desktop. However, this is not possible yet. I am sure someday it will be, and I will be happy to write about it when this becomes available.

The Challenge

For this blog post, I will start with a MATLAB Project containing this simple Simulink model.

open_system('BasicModelingSimpleSystem');

My goal is to get the GitHub Copilot in VS Code to generate MATLAB code that will simulate the model by feeding it a step input and plot the logged signal "x". 

Let's begin by setting up the toolchain and confirming that it works. The steps below are probably more detailed than you need, but that's what I would have liked to see the first time I set that up, so here it is.

Setup

Start by visiting the MATLAB MCP Server GitHub repository and read the readme.md file to get an overview of the required setup and options.

Download the MATLAB MCP Core Server

Download the Latest Release of the MATLAB MCP Server. For me, on Windows, it would be that one:

Store the executable in a convenient location on your computer. You will need to specify its location later when we will create a mcp.json file.

Download Visual Studio Code

Visual Studio Code is one of the most popular code editors these days. It's so popular that MathWorks released the MATLAB Extension for Visual Studio Code, allowing users to edit, run, and debug MATLAB code in Visual Studio Code.

If you don't already have it, download and install it here: Visual Studio Code.

GitHub Copilot Chat Extension

For what we want to do today, install the GitHub Copilot Chat Extension. Search for it in the VS Code extensions panel and click install.

Once this is done, open a new chat

You will need to log into your GitHub Account. 

If you're not familiar with that, follow these instructions to setup your copilot account: Set up GitHub Copilot in VS Code. To reproduce the content of this blog post, the GitHub Copilot Free account should be enough.

Once you sign in, you will see the short list of models available for free. If you have a paid subscription, you will see many more.

Registering the MATLAB MCP Server in Visual Studio Code

The simplest way to validate if the MATLAB MCP server is configured properly is to ask which MATLAB toolboxes are available. At this point, we have not configured it yet, so asking the question in the copilot chat will result in something like that:

This is not what we want, so let's cancel that. 

With the MCP server configured properly, copilot does not need to use "matlab -batch" to run MATLAB code.

The Visual Studio Code instructions to setup a MCP server can be found here: https://code.visualstudio.com/docs/copilot/customization/mcp-servers

More specifically, MathWorks recommends that you follow the steps in the section "Add an MCP server to a workspace mcp.json file". This file needs to be located in a folder named .vscode

The syntax for this file is described here. At the minimum, the "command" field should point to the full path of the MATLAB MCP Server executable downloaded previously. In my case, I also added arguments to specify which MATLAB version to use and the initial working folder, so my mcp.json looks like this:

{

    "servers": {

        "matlab": {

            "type": "stdio",

            "command": "C:\\MATLAB\\MCP\\server\\matlab-mcp-core-server-win64.exe",

            "args": ["--matlab-root=C:\\MATLAB\\R2025b",

                     "--initial-working-folder=C:\\MATLAB\\blog\\MCP\\post"]

}

}

}

Let's ask the same question about the available MATLAB toolboxes. This time a new MATLAB session gets launched automatically, and the copilot asks your permission to run code. As pointed out by the disclaimer, that's the part where you want to be careful. The MCP server will run the AI generated code; it's up to you to decide if you want to let that happen or not. 

If everything works fine, you should get a response that looks like this, representative of the toolboxes and blocksets you have available:

Opening and simulating a Simulink model

Now, let's make a first attempt at generating MATLAB code that can simulate our Simulink model.

Here is what I asked:

Create a MATLAB script named stepSim.m that simulates the Simulink model BasicModelingSimpleSystem.slx with a step input signal and plots the logged signal 'x'.

Depending on the model chosen, copilot might try to run MATLAB code to understand the model before generating the code I requested. In my case, it tried running commands like get_param and find_system to figure out what's in the model, how to specify the requested step input, and how the signal "x" is logged.

After thinking for some time, a file named stepSim.m appears in MATLAB current directory:

In addition to generating MATLAB code, the AI assistant might also try to simulate the model and validate that the code works. Here are additional outputs I could see in the chat;

In the end, the AI-generated file contains a little bit more than 100 lines of code, which is a lot more than I was expecting. I will paste the first part here:

modelName = 'BasicModelingSimpleSystem';

modelFile = fullfile(pwd, [modelName '.slx']);

if ~exist(modelFile,'file')

    error('Model file "%s" not found in current folder: %s', [modelName '.slx'], pwd);

end

% Simulation parameters

tStop = 10;      % stop time (s)

dt = 0.01;       % sample interval for external input

stepTime = 1;    % time at which step goes from 0 -> 1

% Build external input as a two-column [time, value] matrix

t = (0:dt:tStop)';

u = double(t >= stepTime);

in = [t u];

% Load model (does not open the GUI by default)

load_system(modelFile);

% Run simulation using the external input. Use Dataset save format to capture

% logged signals (logsout) when available.

simOut = sim(modelName, ...

    'ExternalInput','in', ...

    'StopTime', num2str(tStop), ...

    'SaveOutput','on', ...

    'SaveFormat','Dataset');

The rest is a logic described as "Attempt to extract logged signal 'x'" that I will not cover here.

Here are my first thoughts when looking at the above code:

I don't need the "exist" check at lines 5 to 7, I know the file is in my project
No need to use load_system, the sim command will load the model
The line "in = [t u];" is old style, I would prefer a more modern syntax using a Simulink.SimulationData.Dataset
I would prefer if the sim command was using the more modern Simulink.SimulationInput object syntax

Running the code and plotting the results, I get:

plot(simOut.logsout.get('x').Values)

Not really the step response I was expecting!

(For those curious wondering why the out is zero, the code specifies ExternalInput, but does not set LoadExternalInput to on, so the specified ExternalInput is never used)

Conclusions and Next Steps

Here are a few conclusions from this first experiment:

On the good side, I confirmed that the MATLAB MCP server enables GitHub Copilot to create and run MATLAB scripts.
On the challenging side, I realized that an AI coding assistant is not magic. Vague requests will most likely result in code that does not do exactly what you had in mind.

As next steps, I could keep chatting with the copilot to refine the code. After multiple iterations, I am pretty confident that I could get the code I want. However, it would probably take longer than writing the code myself. And I don't want to repeat that same process of back and forth chat iterations every time I want to simulate a Simulink model.

Instead, I will stop for today.

In my next post, I will take inspiration from the MATLAB AI Coding Rules GitHub repository and define my own Guy on Simulink AI Coding Rules. That way, I will be able to guide the GitHub Copilot to generate the code I want at the first iteration!

Now it's your turn

Have you tried and adopted the MATLAB MCP Server? Let us know in the comments below what you have tried so far and what you are planning to do with it in the future.

My Personal Simulink AI Assistant

Guy Rouleau — Fri, 05 Dec 2025 00:10:21 +0000

In my previous post, I introduced MATLAB Copilot and the Simulink Copilot Beta. Today, I continue my exploration into the world of AI assistants and how they can help in a Simulink context.

What should a Simulink AI Coding Assistant do? And How?

Since I started using AI coding assistants, I keep thinking: What do I want an AI assistant to do for me in a Simulink context?

For me, one of the first things that comes to my mind is using natural language to do repetitive editing tasks: the kind of things that I know how to do but will require more clicks or more lines of code than I would like.

 The next question that comes to my mind is: How should an AI assistant for Simulink do those tasks?

Most AI coding assistants are based on Large Language Models (LLMs), but Simulink is a block diagram programming language. So, it's not "text in -> text out" like other text-based programming languages. 

This is where my colleague Mike Croucher comes into play with his blog post The MATLAB Blog: Giving LLMs new capabilities: Ollama tool calling in MATLAB. As you can imagine, my first thought after reading this post was: Can I use that to talk to Simulink in natural language?

In this post, I will share what I came up after just a few hours of experimentation with LLMs tools calling. 

Disclaimer: I am no AI expert; this is just me having fun.

The Challenge

I decided to start small and focus on setting block parameters. For example, I want to write queries like the following and have the tool to do it automatically:

Find all blocks of type Model Reference and change their simulation mode to Accelerator
Set the value of this Gain block to 42
Change the color of all Inport blocks to green

The Plan

To make that happen, I made myself a road map where I would split my tool in 4 functions:

Find the blocks to be modified
Determine which block parameter to set
Determine the value of the parameter to be applied
Call set_param with the 3 items above

Setup

To get started, you will need two things:

Install Large Language Models (LLMs) with MATLAB from MATLAB File Exchange or from GitHub.

Install Ollama and pull one of the models that support tools. In my case, after installing Ollama, I launched the Windows Powershell and executed "ollama pull qwen3". There is no special reason why I chose qwen3, it just seemed to work well.

Note: I am using Ollama because it's free, so everyone reading this can immediately try. The Large Language Models (LLMs) with MATLAB project also supports OpenAI® Chat Completions API (which powers ChatGPT), and Azure® OpenAI Services, which gives you access to more powerful models and more computational power.

With that done, you should be good to go.

Text Processing versus Tools

Obviously, Large Language Models are good at processing text. This means that I could probably have saved the Simulink model as MDL format, and feed that to the LLM to be processed. However, I see two potential problems with that approach:

The MDL file can become very large, and a simulation can be made of multiple Simulink files. If there is a simple API in MATLAB to get the info I need, it's probably more efficient to use that instead of parsing the MDL text file.
The MDL file contains only static information. My use cases above require something more dynamic. When I will type "This block", I want the tool to know which block is currently selected in the Simulink editor.

Based on that, I decided to go with a tools calling approach. Let's see what I came up with.

Finding the blocks to modify

To modify blocks, I need their block path to pass to the set_param function.

As described in Mike's post, I created two tool functions that the LLM can call if it decides it needs block paths.

For the first one, I find the selected blocks in the current system. I expect the tool to decide to call this function if the query mentions things like "This block" or "The selected blocks".

function blks = findSelectedBlocks(data) %#ok

    opts = Simulink.FindOptions;

    opts.SearchDepth = 1;

    blks = Simulink.findBlocks(gcs,'Selected','on',opts);

end

The second function is a bit more complex. Beforehand, I created a comma-separated list of all block types in Simulink and stored that in a MAT-file. I then ask the LLM to find the most likely match based on the natural language block type specified by the query:

function blks = findBlocksOfType(data)

    % Function to be called by the LLM if it determines that it

    % needs blocks of a certain type

    type = string(data.blockType);

    % I did find_system on simulink.slx and stored the types of all blocks found

    d = load('allBlockTypes.mat');

    if any(strcmp(d.bTypes,type))

        % Type passed by the LLM is already in the list

        blockType = type;

    else

        disp("Determining block type based on: ''" + type + "''");

        systemPrompt = "You will receive a sentence and comma-separated list " + ...

        "of parameters for a Simulink block. " +...

        "Find the parameter that corresponds the most likely to the sentence. " +...

        "Returns only the parameter name.";

        modelName = "qwen3:latest";

        mdl = ollamaChat(modelName, systemPrompt);

        [blockType, message] = generate(mdl, "The sentence: " + type + "The listof parameters: " + d.blkTypesStr); %#ok

end

    opts = Simulink.FindOptions;% Could be modified to include referenced models

    blks = Simulink.findBlocksOfType(bdroot,blockType,opts);

end

With those two functions available, I can register them in my query to the LLM:

function obj = findBlks(obj)

tool1 = openAIFunction("slModifier.findSelectedBlocks",...

    "Returns the list of currently selected blocks in a Simulink model");

tool2 = openAIFunction("slModifier.findBlocksOfType",...

    "Returns the list of blocks of a specific blockType in a Simulink model");

tool2 = addParameter(tool2,"blockType",type="string");

systemPrompt = "You are an automated tool designed to modify Simulink models, " +...

    "a block diagram programming language. " + ...

    "The user will make a request, you need to find which " + ...

    "modeling elements the user is trying to modify";

agent = ollamaChat(obj.modelName,systemPrompt,tools=[tool1,tool2]);

[response, message] = generate(agent, "The sentence: " + obj.request);

obj.blks = slModifier.callTool(response, message);

end

Determine which parameter to set

In a second pass, I do something similar to what I did earlier with block types, but this time for block parameters. I query the list of parameters for the blocks found in the previous step using get_param and ask the LLM to find the most likely match based on the original query:

function obj = findParam(obj)

    d = get_param(obj.blks(1),'ObjectParameters');

    f = fieldnames(d);

    commaSeparatedString = string(strjoin(f, ', '));

    systemPrompt = "You will receive a sentence and comma-separated list of parameters for a Simulink block. " + ...

        "Find the parameter that corresponds the most likely to the sentence. " + ...

        "Returns only the parameter name.";

    agent = ollamaChat(obj.modelName,systemPrompt);

    [obj.param, message] = generate(agent, "The sentence: " + obj.request + "The list of parameters: " + commaSeparatedString); %#ok

    disp("Found parameter to set: ''" + string(obj.param) + "''");

    disp(newline);

end

Determine the value of the parameter to be applied

One more similar round, but this time I am looking for the value to be applied.

function obj = findParamValue(obj)

    systemPrompt = "You are an automated tool designed to modify Simulink models. " + ...

        "The user will make a request, your task is to identify the value " + ...

        "of the parameter that needs to be applied. " + ...

        "Return only a single word. " + ...

        "Example: Set the color of this block to red, the answer should be red. " + ...

        "Example: Set the value of a Gain block to 3, the answer is 3.";

    agent = ollamaChat(obj.modelName,systemPrompt);

    [obj.value, message] = generate(agent, "The sentence: " + obj.request); %#ok

end

Call set_param

Once I have all the necessary info, call set_param:

function doTheModif(obj)

    for i = 1:length(obj.blks)

        set_param(obj.blks(i),obj.param,obj.value);

end

end

The Final MATLAB Class

Assembling that together in a single MATLAB class for convenience, this give (with the functions described above collapsed):

classdef slModifier < handle

    properties

        modelName

        request

        findOptions = Simulink.FindOptions;

        blks

        param

        value

end

    methods

        function obj = slModifier()

            obj.modelName = "qwen3:latest";

end

        function run(obj)

            obj.findBlks();

            obj.findParam();

            obj.findParamValue();

            obj.doTheModif();

end

        function obj = findBlks(obj)

end

        function obj = findParam(obj)

end

        function obj = findParamValue(obj)

end

        function doTheModif(obj)

end

end

    % Tools passed to the LLM

    methods (Static=true)

        function out = callTool(response,message)

end

        function blks = findSelectedBlocks(data) %#ok

end

        function blks = findBlocksOfType(data)

end

end

end

Testing the results

Test 1: Modify multiple blocks of the same type

Let's use this simple model:

open_system('sldemo_mdlref_basic');

and run this code:

h = slModifier;

h.request = "Find all blocks of type Model Reference and change their simulation mode to Accelerator";

h.run;

1 - Analyzing request for blocks to modify
Determining block type based on: ''Model Reference''
Found blocks to modify:
- sldemo_mdlref_basic/CounterA
- sldemo_mdlref_basic/CounterB
- sldemo_mdlref_basic/CounterC
2 - Analyzing which parameter to set
Found parameter to set: ''SimulationMode''
3 - Analyzing which value to set
Setting ''SimulationMode'' to ''Accelerator''
4 - Make the modification
Click here to apply:
set_param('sldemo_mdlref_basic/CounterA','SimulationMode','Accelerator');
set_param('sldemo_mdlref_basic/CounterB','SimulationMode','Accelerator');
set_param('sldemo_mdlref_basic/CounterC','SimulationMode','Accelerator');

The dark corners on the Model blocks confirm that this worked:

Test 2: Modify selected blocks

I manually select this Gain block:

h = slModifier;

h.request = "Set the value of this Gain block to 42";

h.run;

1 - Analyzing request for blocks to modify
Found blocks to modify:
- sldemo_mdlref_basic/Gain
2 - Analyzing which parameter to set
Found parameter to set: ''Gain''
3 - Analyzing which value to set
Setting ''Gain'' to ''42''
4 - Make the modification
Click here to apply:
set_param('sldemo_mdlref_basic/Gain','Gain','42');

Test 3: Change the color of all Inport blocks to green

open_system('sldemo_mdlref_counter');

h = slModifier;

h.request = "Change the color of all Inport blocks to green";

h.run;

1 - Analyzing request for blocks to modify
Found blocks to modify:
- sldemo_mdlref_counter/ upper
- sldemo_mdlref_counter/ input
- sldemo_mdlref_counter/lower
2 - Analyzing which parameter to set
Found parameter to set: ''ForegroundColor''
3 - Analyzing which value to set
Setting ''ForegroundColor'' to ''green''
4 - Make the modification
Click here to apply:
set_param('sldemo_mdlref_counter/ upper','ForegroundColor','green');
set_param('sldemo_mdlref_counter/ input','ForegroundColor','green');
set_param('sldemo_mdlref_counter/lower','ForegroundColor','green');

Now it's your turn

Have you been experimenting with Large Language Models? Incorporating tools for specialized tasks?

When Simulink Copilot gets released, what will you ask? Let us know in the comments below.

A Copilot for Simulink!

Guy Rouleau — Tue, 02 Dec 2025 00:02:49 +0000

I recently decided to investigate different AI coding assistant technologies and see how they can help with Simulink. This led me into a series of blog posts that I plan to publish in the next few days and weeks.

In this post, I will begin with:

MATLAB Copilot
Simulink Copilot Beta

In future posts, I am planning to visit

My personal attempt at talking to Simulink
MATLAB MCP Server
AI Assistant Coding Rules Simulink

MATLAB Copilot

Even if it's not specifically targeted at Simulink, MATLAB Copilot is trained with the entire MATLAB documentation, so it can answer Simulink-related questions and handle Simulink-related code.

My two favorite ways to access it are:

Copilot Chat

A new panel in the MATLAB desktop where you can pose all types of requests, including Simulink-related ones. Here is a simple example:

The buttons on the upper right of the AI-generated code allows you to:

Copy the code to the system clipboard
Insert the code at the cursor location in the MATLAB Editor
Execute the code

Ask Copilot

Another MATLAB Copilot feature I like is the "Ask Copilot". Let's say I type this code in the MATLAB Editor. I can select the second line and select Ask Copilot.

A dialog appears where I can type my request.

MATLAB Copilot will generate code that I can accept or reject.

It might not generate exactly what you need, but I find that, very often, it starts me in a good place and saves time.

Simulink Copilot Beta

Even though it's not fully ready, I can share that we are actively working on a Simulink Copilot. 

If you're an enthusiastic Simulink user, I strongly encourage you to visit the Simulink Copilot landing page and sign up for upcoming beta testing opportunities for Simulink Copilot. You don't want to miss this chance to provide feedback and impact the design!

I have been testing Simulink Copilot during its development, but I will not share my experience yet to not impact the feedback we hope to receive during beta testing.

Here is a screenshot to give you a feeling of what this will probably look like.

I promise a blog post dedicated to Simulink Copilot soon after the official release!

Now it's your turn

Visit the Simulink Copilot landing page and sign up for upcoming beta testing opportunities for Simulink Copilot.

I would also be very interested to hear in the comments below what you would like Simulink Copilot to do for you.

How do you Inspect Logged Signals?

Guy Rouleau — Wed, 29 Oct 2025 19:26:34 +0000

I receive and debug Simulink models all day every day. This means that I often need to log many signals and inspect them to understand what the model is doing.

For that, I like using the Simulation Data Inspector Browse Mode in combination with the in-canvas logging badges. I decided to share that today because this is not the default behavior, and I don't want you to miss it.

Here is what it looks like. Simply clicking the logging badge controls the signal displayed in the Simulation Data Inspector. That way you can quickly follow the flow of data in the canvas and determine at which point something unexpected happens.

How to Enable Browse Mode

In the Simulation Data Inspector preferences, go to the Inspect - Selection section to select between Check Mode and Browse Mode

Check Mode versus Browse Mode

I like to use Check Mode when I want to create a persistent reusable view, save it and share it. In that case, a check box is displayed next to each signal, and you need to click it to display the signal, and click it again to remove it.

When I am in an exploration or debugging workflow and I don't really know which signal I will want to look at in advance, I like to use Browse Mode. In that mode, the check boxes are gone and clicking on a signal replaces the signal displayed. To display multiple signals on the same plot, you can use the Shift key to multi-select.

Now it's your turn

Are you leveraging those two modes when visualizing logged data? Let us know in the comments below.

Extracting Timetables… Simulink style

Guy Rouleau — Fri, 29 Aug 2025 19:31:18 +0000

Today I want to share a simple tip to interact with data logged from a Simulink model

The Problem

Let's take this simple model that logs 3 signals with different sample times:

After simulating, it is possible to use extractTimetable to create a single timetable with all the logged signals:

out = sim('testLog');

TT = out.logsout.extractTimetable

TT = 11×3 timetable 
TimesineTs1sineTs2sineTs3
sec000
sec0.0628NaNNaN
sec0.12530.1253NaN
sec0.1874NaN0.1874
sec0.24870.2487NaN
sec0.3090NaNNaN
sec0.36810.36810.3681
sec0.4258NaNNaN
sec0.48180.4818NaN
sec0.5358NaN0.5358
sec0.58780.5878NaN

	Time	sineTs1	sineTs2	sineTs3
1	0 sec	0	0	0
2	1 sec	0.0628	NaN	NaN
3	2 sec	0.1253	0.1253	NaN
4	3 sec	0.1874	NaN	0.1874
5	4 sec	0.2487	0.2487	NaN
6	5 sec	0.3090	NaN	NaN
7	6 sec	0.3681	0.3681	0.3681
8	7 sec	0.4258	NaN	NaN
9	8 sec	0.4818	0.4818	NaN
10	9 sec	0.5358	NaN	0.5358
11	10 sec	0.5878	0.5878	NaN

What's the problem? In one word: NaN.

By default, extractTimetable inserts NaN for steps where signals with a sample time slower than the fastest rate did not execute. While this is technically correct because there was no data point at this time, I find this not ideal for data logged from Simulink. 

In Simulink, if I was to connect a Rate Transition block and other blocks downstream from this logged signal, they would not receive NaNs. Instead, the previous value would be held.

Those NaNs also make plots look strange. Here is the data as seen in the Simulation Data Inspector:

When plotting the timetable, the NaNs cause gaps in the signals:

stackedplot(TT);

The Solution

To obtain a timetable that I find better aligned with Simulink's behavior, you can first extract the data as a cell array that contains one timetable per signal, and then combine them using the synchronize function:

TT = out.logsout.extractTimetable(OutputFormat="cell-by-signal");

TT = synchronize(TT{:},"union","previous")

TT = 11×3 timetable 
TimesineTs1sineTs2sineTs3
sec000
sec0.062800
sec0.12530.12530
sec0.18740.12530.1874
sec0.24870.24870.1874
sec0.30900.24870.1874
sec0.36810.36810.3681
sec0.42580.36810.3681
sec0.48180.48180.3681
sec0.53580.48180.5358
sec0.58780.58780.5358

	Time	sineTs1	sineTs2	sineTs3
1	0 sec	0	0	0
2	1 sec	0.0628	0	0
3	2 sec	0.1253	0.1253	0
4	3 sec	0.1874	0.1253	0.1874
5	4 sec	0.2487	0.2487	0.1874
6	5 sec	0.3090	0.2487	0.1874
7	6 sec	0.3681	0.3681	0.3681
8	7 sec	0.4258	0.3681	0.3681
9	8 sec	0.4818	0.4818	0.3681
10	9 sec	0.5358	0.4818	0.5358
11	10 sec	0.5878	0.5878	0.5358

This looks better.

stackedplot(TT);

Now it's your turn

Do you prefer the default behavior of extractTimetable? Would you prefer if the "zero-order hold" behavior shown in this post was the default? Let us know in the comments below.