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.3.0.190c8728\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_armv8a_64, bb_x86_64):

    • 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.

Inports, outports and testpoints

The following naming rules are used for the corresponding PMP entities:

  • Scalar signals: the name of the inport/outport is used.

  • Vector signals: for every vector element the name of the inport/outport is postfixed with and underscore and the index of the element. For example a vector signal x of size 2 is split into two PMP signals named x_0 and x_1.

  • Scalar bus element: for every scalar bus element the inport/outport name is postfixed with an underscore and the name of the bus element if the bus in nonvirtual. For example an outport y based on a bus with elements a and b is split into two elements y_a and y_b. In case of a virtual bus the name of the outport is omitted, the PMP entity gets the name of the bus element.

  • Vector bus element: for every vector bus element the inport/outport name if postfixed with bus element name and element index, all separated by an underscore, e.g. z_a_0 and z_a_1 for an outport z with element a of size 2. In case of a virtual bus, the name of the inport/outport is omitted, the PMP entity gets the name of the bus element.

Because of the signal naming done by the PMP code generator name clashes can occur with the naming performed by Simulink.

Note

If a name clash occurs during code generation, the following error will be shown: ‘The name “name” is used multiple times in the model.’

The Simulink code generator does allow the same name for Simulink blocks (such as outports and inports) and Simulink signals. However, because PMP requires unique names for inputs and signals all blocks and signals must have unique names in Simulink. In case duplicate names are used, the same error as shown above is thrown during code generation.

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

Simulink allows duplicate names for signals. When duplicate names are present in a model, Simulink code generation adds a suffix with random characters to the name to make the name unique. Using unique names in the model is highly recommended.

Parameters

Parameters are accessible through PMP when a PT.Parameter object is used, A PT.Parameter object can be made via the PmpParameter function. The name of the parameter object in MATLAB is also used as the PMP signal name (details can be found under Parameter).

When a parameter is a array, a PMP signal is created for each element. A PT.Parameter object can contain an array, but it is not possible to make an array of PT.Parameter objects. The name of each element postfixed with an underscore and the index of the element. For example, a array parameter x of size 2 is split into two PMP signals named x_0 and x_1.

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.