In order to run with Simulink Compiler, the model must be able to run in Rapid Accelerator mode. Some special I/O blocks do not support running in Rapid Accelerator mode. Some examples of blocks that might not support Rapid Accelerator mode:
- Hardware specific I/O blocks (TCP Send block, TCP Receive block, UDP Send block, UDP Receive block)
- MATLAB Function blocks calling "extrinsic" MATLAB code
- Some 3rd party blocks
- Some S-function blocks (depending on the code being called)
- Some C-Caller or C-Function blocks (depending on the code being called)
- "disp" statements or fprintf/sprintf statements
Because of this, a more robust way to design your model for deployment is to make the model "purely algorithmic", meaning the model takes its inputs through basic source and sink blocks such as input and output ports, and any special handling of inputs and outputs is handled with the Simulink Compiler callback functions:
These callbacks can execute any code that is supported by MATLAB Compiler. In most cases, it will be easier to add special handling for inputs and outputs in these MATLAB callbacks than trying to inline this logic into blocks in the model itself. Additionally, the callbacks give you access to data such as simulation time and also decimation options. A basic sketch of this approach is outlined below.
An additional benefit of designing models to be purely algorithmic is that it allows easy reuse across workflows. For example, if you wanted to use this model with Simulink Realtime, you could quickly use the same model as a model reference in a harness model that contains the required target specific blocks. In this way we can easily reuse the same model across both Simulink Compiler and other workflows.
