C Symbols

The names you give tasks, signals and blocks on the canvas are the names you find in the generated C. To change a name, rename it in the model and regenerate; never rename it in the code.

What you get from a model

Each model generates <Model>.h and <Model>.c. Select an element to see the C symbol it becomes:

ModelTasksInputs & outputsTask-to-task dataStates

Model on the canvas

Generated C

/* Cruise.h */extern float64_t speed;extern float64_t speed_error;extern float64_t throttle; void Cruise_Init(void);void Sense(void);void Control(void); /* Cruise.c */static float64_t integral = 0.0;

Each task becomes one function with exactly the task's name.

In the model	In C	Example
Model	void <Model>_Init(void)	Cruise_Init()
Task	void <Task>(void), named exactly as the task	Sense(), Control()
Model Input / Model Output	Variable	speed, throttle
Connection between two tasks	Variable	speed_error
Memory block (Unit Delay, Integrator, …)	Internal variable	integral
Logged signal with Exposure Public	Variable	motor_speed
Container	Internal function	PiController
Enumeration type	Enum type and constants	DriveMode_t, DriveMode_SPORT

<Model>_Init(), the task functions and the input, output and public variables are the model’s interface. Internal variables and functions appear in the code for review only.

A logged signal stays internal unless you set its Exposure to Public in the Data Manager. It then appears in <Model>.h under its signal name.

Enumeration types

A user-defined enumeration type becomes a C enum type. Each member becomes a constant with its value:

Type in the model

DriveMode

ECO = 0NORMAL = 1SPORT = 2

Generated C

typedef enum { DriveMode_ECO = 0, DriveMode_NORMAL = 1, DriveMode_SPORT = 2} DriveMode_t;

In the model	In C	Example
Type DriveMode	<Type>_t	DriveMode_t
Member SPORT	<Type>_<Member>	DriveMode_SPORT
Signal of type DriveMode	Variable of type <Type>_t	DriveMode_t active_mode;
Literal DriveMode.ECO	The member constant	DriveMode_ECO

• Type and member names are kept exactly as written, including upper and lower case.
• The type name is always the prefix. Two types can share member names: DriveMode_ECO and PowerMode_ECO are different constants.
• Members appear in value order, each with its explicit value.

Type and member names must be valid C identifiers. Modeloop checks this when you define the type.

How a name is chosen

Modeloop uses the first name you gave, in this order. If you gave none, it uses an automatic name.

Element	1st choice	2nd choice	Automatic name
Model Input / Output	Signal connected to it	Model Input / Output block name	tmp_in_1, tmp_out_1
Connection between tasks	Connection name	Signal on the producing output	irv_1
Signal inside a task	Signal name	Name of the block that produces it	tmp_sum_1
Memory block	Its output signal name	Block name	tmp_st_1
Container port	Signal name	Virtual Input / Output name	in_1, out_1

Names become valid C identifiers: characters other than letters, digits and underscores become _, and a C keyword gets a leading underscore (for → _for). The name in your model stays unchanged.

Task names are used exactly as written. A task name must be a valid C identifier, must not be a C keyword, and must be unique across every model in the build. Otherwise, code generation stops and tells you which name to change.

When two names clash

Names stay exactly as you wrote them unless they clash. When two tasks of the same model use the same name, only those symbols get the task name as a prefix:

Model Filters: the name in the model → the name in C

Fastevery 1 ms

Inputraw→Fast_rawStateprev→Fast_prevOutputfast_avg→fast_avg

Slowevery 10 ms

Inputraw→Slow_rawStateprev→Slow_prevOutputslow_avg→slow_avg

Shared by both tasks: task name addedUnique: kept as authored

Here both tasks read model input raw, so write both Fast_raw and Slow_raw. Adding a task never renames a symbol that is still unique.

Code generation stops and asks you to rename one element when:

• Two different signals in the same task or Container would get the same C name.
• Two models in the same build have a task with the same name.

Naming tips

• Name signals at the model boundary. wheel_speed_rpm is a better variable than tmp_in_1.
• Name connections between tasks. Otherwise they become irv_1, irv_2, ….
• Name Containers after what they do. Their names appear as function names in the code.
• Use an enumeration type for modes. DriveMode_SPORT is clearer in the code than 2.
• Keep task names unique across the project. All task functions share one namespace in your firmware.