MATLAB and Simulink for the engineering exam: what to know

MATLAB is the language you meet first in engineering, and Simulink is almost always the way in which you are asked for projects in control, signals, dynamics and modelling. And yet, in many courses at the Politecnico, the first hour of the lecture is “here is MATLAB, off to the lab” — and students find themselves chasing a syntax that is not Python’s and a vector logic that is not C’s.

What follows is the path I take my students through — from first-year student to the heaviest exams such as Automatic Control or Linear Systems — to arrive at the exam with MATLAB and Simulink that are solid, not improvised.

A note on method, if you are reading this post in September: the course has just started or is about to start, and the exam is in the winter session, in January. The way not to arrive unprepared is not “review everything in December”: it is to write code every week, even a little, from the start. MATLAB is quickly forgotten if you touch it only at lab sessions — it is a language kept up by constant practice, not by a final review.

The “first-year” level: MATLAB as a scientific calculator

If you are in the first year and MATLAB has appeared in a numerical calculus or algorithms course, you need only a very reduced subset of the language:

• Variables, vectors, matrices (and understanding well the difference between A * B and A .* B).
• The : operator to create ranges (x = 0:0.1:2*pi).
• Basic plotting (plot, subplot, figure, xlabel, legend), and hold on / hold off.
• Control structures (if, for, while) — syntax different from C/Python, watch the ends.
• Functions in separate .m files and the difference between script and function.

You do not need OOP, you do not need structs, you do not need the toolboxes. The important thing at this level is to understand that MATLAB thinks in matrices: every time you write a for over a vector, there is probably an equivalent vector operation that is 10x faster and more readable.

A typical first-year trap: writing a for i=1:n loop to calculate y(i) = sin(x(i)) instead of writing y = sin(x) directly. MATLAB applies functions elementwise on vectors without your having to tell it to.

The “intermediate” level: well-made scripts, debugging, readable plots

From the second year on, MATLAB exercises start to be more structured: you write a function that takes parameters, returns results, perhaps produces a decent graph. At this point you need:

• Function vs script: a function has its own workspace, a script does not. Understanding the difference avoids a thousand “why did the variable change” bugs.
• Default arguments and nargin: nargin tells you how many arguments were passed and lets you write functions that accept optional parameters.
• Interactive debugging: keyboard to stop inside a function, breakpoints in the editor, dbstop if error to break automatically at the first error.
• Readable plots: LineWidth, MarkerSize, set(gca, 'FontSize', ...), axis equal when needed. An unreadable graph in a report costs you marks, and it takes little to make it professional.
• Systematic vectorisation: bsxfun, arrayfun, meshgrid, repmat. Knowing they exist saves you hours of for loops.

The “control & signals” level: Simulink + toolboxes

When you reach the courses on Automatic Control, Linear Systems, Dynamics, Identification, Digital Filters, MATLAB becomes the means of using the toolboxes. Pure MATLAB syntax counts less: the toolboxes count.

The toolboxes I see my students use most:

• Control System Toolbox: tf, ss, step, impulse, bode, nyquist, pid, pidtune, lqr, place. Everything needed for linear controller design.
• System Identification Toolbox: iddata, arx, armax, n4sid, identification from data.
• Signal Processing Toolbox: fft, filter, butter, cheby1, freqz, spectrogram.
• Symbolic Math Toolbox: for when the professor wants symbolic derivatives and integrals inside MATLAB (syms, diff, int, simplify).

At this level, Simulink comes into play almost everywhere:

1. Modelling: you drag blocks (Sum, Gain, Integrator, Transfer Fcn, Saturation, Scope) onto a sheet and connect them.
2. Simulation: you launch the simulation, the scopes show how the signals evolve.
3. Tuning: the built-in PID Tuner to close the control loop, or LQR via MATLAB code called from a callback.
4. Code generation (rare at exam level, common in theses): you generate C from the Simulink model for microcontrollers.

Vectorisation: the same calculation, two ways of writing it

I come back to this point with a concrete example because it is the habit that distinguishes a “first-year” script from an “advanced lab” one, and because it is the request that markers of the Numerical Calculus and Control courses make most often: “do not use a for where it is not needed”.

The for loop version (it works, but it is the version to avoid when the vector is large and the code has to be written for a report):

n = 100000;
x = linspace(0, 10, n);
y = zeros(1, n);
for i = 1:n
    y(i) = sin(x(i))^2 + cos(x(i));
end

The vectorised version (exactly the same result, line by line comparable with the original):

x = linspace(0, 10, n);
y = sin(x).^2 + cos(x);

What changes, in practice:

1. Readability: the second version reads like the mathematical formula it represents, the first is a manual implementation of the same thing.
2. Speed: MATLAB is internally optimised for operations on vectors and matrices; a for loop that iterates element by element is almost always slower, and the difference grows with the size of the vector.
3. Less room for bugs: no index i to initialise, increment and use correctly — a typical source of “off by one” errors when you move from a zero-based language like Python or C.

The practical rule I give my students: if you are writing for i = 1:length(x) and inside the loop there is only an elementwise operation (+, -, .*, ./, .^, or functions like sin, exp, sqrt), you can almost certainly remove it. The for remains necessary when each iteration depends on the result of the previous one (e.g. step-by-step simulations, recursions), which is a different case and genuinely cannot be vectorised.

Mistakes I see most often

1. Confusing matrix and elementwise operations. A * B is matrix product, A .* B is elementwise product. It seems obvious, but it is cause #1 of dimensional errors in projects.

2. Indexes from 1. MATLAB indexes from 1, not from 0 like Python or C. When you move code from one to the other, be careful: x(1) is the first element, not the zeroth.

3. Global variables as a hack. If you find yourself writing global in more than one function, there is almost always a better design (function handle, a struct with the parameters, a class).

4. Plots without units of measurement and legend. Trivial but it costs marks in all lab courses. Always xlabel, ylabel with units in brackets, always a legend if there are several curves.

5. In Simulink, the scope as the only form of output. The scope is excellent for interactive debugging but for the report you need to export the data to the workspace (the “To Workspace” block) and do the plot in MATLAB with decent styling.

6. Tuning PIDs by eye in Simulink. It works for simple systems, but for Automatic Control exams it is better to design via Bode/root locus and then check in Simulink. The professor notices.

Realistic timescales

• From zero to a first-year exam (numerical-calculus type): 4-6 lessons to consolidate the syntax and do the lab exercises.
• Intermediate exam (Automatic Control, Systems and Signals): 8-12 lessons split between pure MATLAB and Simulink. You start from the control concepts (continuous or discrete?), simulate in Simulink, check analytically in MATLAB.
• Thesis project that uses MATLAB: variable. In general a well-prepared student uses the tutor to “unblock” specific moments (a new toolbox, a heavy debug) rather than to learn from scratch.

How we work in lessons

MATLAB lessons should be done in shared live coding. We open MATLAB on one side of the window, the editor on the other, and write code together: I explain a structure, you modify it, I make you go wrong on purpose in a controlled way to see what the debugger tells you.

For Simulink, the same: you drag blocks, simulate, we read the scope, we fix. The final model you write yourself, but built together.

We often work directly on your course materials (the professor’s slides, tutorial sheets, past exam papers): it is the quickest way to be prepared for that exam, not for “MATLAB in general”.

See also the page dedicated to computer science tutoring with the whole programme I follow (MATLAB, Simulink, Python, C, web development with React). If a Simulink project or a Control exam has dug its heels in, write to me: we look together at the code or the model and find where it gets stuck.

If in parallel you have calculus and linear algebra exams, you will find the university exam practice tests for Calculus 1, Calculus 2 and linear algebra, in the exam format. For algorithm complexity, which in programming courses crosses with MATLAB, there is the post on big-O notation.

To go further

• If in the same semester you also have a database exam: databases, ER and relational schema, SQL for the exam.
• If you come from a C course and pointer logic confuses you: pointers and memory in C explained well.
• If you are also starting Python from scratch: Python programming from scratch for students.
• For the linear algebra behind a good part of the control toolboxes: linear algebra: rank, kernel and image for the exam.
• For Numerical Calculus or Numerical Methods exams: numerical calculus: the numerical methods exam.