Considerations

This section describes support limitations, naming conventions, restrictions and performance considerations of Simulink code generation for PMP.

Supported MATLAB versions

At any time at most 5 MATLAB versions are supported. When starting to support a new version, support for the oldest version is dropped. The following MATLAB versions are tested. Other versions may work, but are not officially supported.

Supported versions

Versions

R2022b

R2023a

R2023b

R2024a

R2024b

Note

The list of the supported MATLAB versions can be found in the installation directory:

C:\Program Files\Prodrive Motion Platform\96.9.0.716123d8\matlab\simulink\versions\supportedVersions.csv

The following MATLAB toolboxes are required:

  • Simulink

  • MATLAB Coder

  • Simulink Coder

Supported compiler versions

One of the following compiler(s) is required to be installed depending on the selected target platform:

  • PMP simulator for Windows (win_x86_64):

  • PMP simulator for Linux (lnx_x86_64):

    • GCC C/C++ 12.2.0

  • PMP motion controller hardware (bb_x86_64, bb_armv8a_64, bb_x86_64_avx512):

    • Included in the PMP installer as sub-feature Simulink toolchain under Control loop customization.

Note

The matlab command mex -setup C++ lists the installed compilers.

Supported data types

The data types of parameters, testpoints and external input and output ports of a model for which code is generated are visible to PMP and are therefore subject to compatibility restrictions between Simulink and PMP. This section describes the data types that are allowed for these parameters, testpoints and external input and output ports. Internally, other data types supported by the Simulink code generator may also be used. Supported simple Simulink data types and their PMP counterparts. states the supported scalar Simulink data types. Note that the Simulink data types not necessarily use the same memory size as the corresponding C++ or PMP data types. The supported types can also be used as Simulink vector signals.

Simulink signals are allowed to be of a bus type. A bus type must consist of one or more scalar signals as listed in Supported simple Simulink data types and their PMP counterparts. or a Simulink vector signal of one of these types. Buses may not be nested on the testpoints, external input signals and output signals. Internal signals are allowed to contain arbitrary types and are allowed to have nested buses.

If an unsupported data type is used, the following error is shown during code generation: ‘Data type “datatype” is not allowed for input “name”.’

Supported storage classes

Simulink parameters and signals can be customized such that a different storage class is used. Different storage classes are not supported because this conflicts with instantiating a model multiple times in PMP. The storage class must be Model default, parameters and signals created with PmpParameter and PmpSignal do have this storage class.

Naming conventions and restrictions

This section describes the coupling between names used for Simulink entities and the names used for the corresponding PMP entity. All names must adhere to the PMP naming rules, see Named.

The name of each PMP entity consists of the name of the Simulink entity from which it originates, with a suffix in case of a vector, matrix or bus entity. The following table shows how the base name is determined:

PMP entity base name

Simulink entity

PMP entity

Base name

Inport

Input

BlockName of the Inport

Outport

Read-only Signal

BlockName of the Outport

Testpoint

Read-only Signal

Name property of the line that is the Testpoint.

Parameter

Read-Write Signal

Name of the corresponding workspace variable

The following suffixes may be applied to the PMP entity names:

  • Bus inports, outports or testpoints: The PMP entity name is suffixed by an underscore followed by the bus member name.

  • Vector inports, outport, testpoints and parameters: The PMP entity name is suffixed by an underscore followed by the 1-based index of the entity in the vector.

  • Matrix inports, outport, testpoints and parameters: The PMP entity name is suffixed by:

    • An underscore followed by the 1-based row-index of the entity in the matrix.

    • An underscore followed by the 1-based column-index of the entity in the matrix.

The PMP entity names resulting from the above rules must result in a unique name per entity. If a name clash occurs, an error will be shown during code generation: The name <name> is used multiple times in the model.

Note

PMP entities derived from Simulink entities with 1xN matrices use the Vector naming convention instead of Matrix naming convention. This is in line with the result of the MATLAB function isvector.

Note

PMP does not support:

  • inports, outports or testpoints based on Simulink objects which contain a bus-in-a-bus. Only a single bus-level is supported.

  • parameter structs. Only scalar values, vectors or matrices are supported.

Note

Simulink allows the same name for Simulink blocks (such as outports and inports) and Simulink signals. It is highly recommended to use unique names in the model.

Note

Care must be taken when spaces are used for block or signal names because Simulink might only use the part before the first space.

Examples

The following examples show how the naming rules apply and when the name clash error occurs.

  • A bus Inport In with 3 members Scalar, Vector (1x3), Matrix (2x2) result in the following signal names:

    • In_Scalar

    • In_Vector_1

    • In_Vector_2

    • In_Vector_3

    • In_Matrix_1_1

    • In_Matrix_1_2

    • In_Matrix_2_1

    • In_Matrix_2_2

  • A 2-vector inport named Data and a scalar outport named Data_1 will result in a name clash, even though the block names are not the same.

  • A bus-inport named Data with fields First and Second and a scalar outport named Data will not result in a name clash, even though the block names are the same.

Memory allocation

Generated code is not allowed to (de)allocate memory in a dynamic way (i.e. while the controller is in Run state). The asynchronous exception 0x0200004e is added to the asynchronous exception queue in this case. Consider disabling the MATLABDynamicMemAlloc option to prevent dynamic memory allocations through a compilation error, as discussed in the Simulink help.

Attention

The performance and memory usage of Simulink models on a motion controller or EtherCAT SubDevice cannot be guaranteed, because these depend on the implementation of the model. Custom processing blocks can have a negative performance impact on the remainder of the system, e.g. due to cache influences and memory accesses. It is the responsibility of the user to evaluate the performance.

Several features are available within PMP which can be used to get a performance indication:

  • Memory usage.

  • Timing measurements, only when supported by the motion controller or EtherCAT SubDevice.

  • Start Timer/Read Timer blocks, these blocks can measure the difference in the wall-time between the time a sample enters the Start Timer and Read Timer blocks.

Sometimes calculation time can be improved by splitting the Simulink model over smaller processing blocks, such that they be executed in parallel on different cores.