Signal Monitoring and Parameter Tuning
Monitor and Tune action enables Simulink® on your host computer to communicate with the deployed model on your hardware board during runtime.
The Monitor and Tune operation described here applies to the following hardware support packages:
Embedded Coder® Support Package for BeagleBone® Black Hardware
Simulink Coder™ Support Package for NXP™ FRDM-K64F Board
Simulink Support Package for Raspberry Pi® Hardware
Simulink Support Package for Arduino® Hardware
For all other hardware support packages, refer to External Mode Simulations for Parameter Tuning, Signal Monitoring, and Code Execution Profiling (Simulink Coder).
How Monitor and Tune Works
Monitor and Tune action creates a communication service on the host computer and hardware board. The two services establish a communication channel between the Simulink engine and generated code deployed on the hardware board. The communication service isolates the model process on the hardware board from the code and from the transport layer that formats, transmits, and receives the data packets. The communication service on the host computer receives the data packets through the transport layer and updates the Simulink model display. The diagram shows the connection that the external mode communication service creates between Simulink on the host computer and the deployed code on the hardware board.
The task descriptions that follow assume Modeling for Single-Tasking Execution (Simulink Coder). They can also be applied to Modeling for Multitasking Execution (Simulink Coder), where the background task containing the external mode executes with the lowest priority.
As a foreground task called after each execution step model, the Monitor and Tune collects data at the base rate of the model.
This diagram shows the typical execution of the external mode relative to the model code.
Executing after each model time step maintains the integrity of the data logged by the Monitor and Tune from the hardware board.
When model code consumes most of the execution time for each time step, the Monitor and Tune execution overruns into the next time step. This delays the start of the next model execution step and degrades the real-time behavior of the deployed model. The following diagram shows an overrun of the external mode into the next time step due to model code execution time.
As a result of this overrun, in deployed models where data logging takes priority over real-time execution, configure Monitor and Tune to operate as a foreground task.
Monitor and Tune can be configured to operate as a background task on your hardware. As a background task, Monitor and Tune uses the execution time between the model code completing in one time step and starting in the next time step. By not blocking the model step, Monitor and Tune action can be used in systems that require real-time execution. This Monitor and Tune configuration enables direct observation of the deployed model on the hardware board as it would behave in standalone operation.
The following diagram shows the execution of the model and background task.
When model code consumes most of the execution time for each time step, the Monitor and Tune in the background task gets starved for execution time. Without sufficient time to collect and transmit data from the hardware board to the host computer, data packets get dropped by the Monitor and Tune, resulting in gaps in the data logging.
As a result of these potential gaps, in deployed models where real-time execution takes priority over data logging, configure Monitor and Tune to operate as a background task.