Greg's picks this week are
Often those who run simulations want to change a few inputs and parameters and see how the model responds without needing to understand the intricacies of the model itself. Providing a graphical user interface (GUI) to the model is a common approach to meet the desire to abstract the model’s internal structure for an end user of the simulation.
As a field engineer, I work a great deal with a number of our customers who use Simulink, and I often get questions about how to provide a GUI for a Simulink model. So I set about searching the File Exchange for a good example, but instead I found three.
Each of the File Exchange entries approach adding a GUI to Simulink model differently. Each of the chosen File Exchange entries provides relatively simple examples along with documentation.
Fundamentally the strategy that Will Campbell takes is to change properties and parameters of the various blocks in the Simulink model using the SET_PARAM application programming interface (API) for Simulink.
For example, in the callback function for the slider bar that appears in the GUI, the value of the Gain block in the model is updated using:
% Update the model's gain value set_param([bdroot '/Gain'],'Gain',value)
The control of the model execution is performed using SET_PARAM in conjunction with the model’s simulation status.
Finally, the synchronization from the model to the GUI during model open, simulation start, etc. is handled using callback functions for the model and blocks within the Simulink diagram.
The way this example is constructed, the GUI and the Simulink model execute in an asynchronous fashion. The elements that Will includes in this example are an effort to enable handshaking between the GUI and the Simulink model in order to maintain synchronicity between GUI elements and Simulink model parameters.
Nitin Skandan approaches the GUI attachment to the model by using GUIs as Sink and Source blocks. That is, as blocks to either provide input to, or display outputs from, a Simulink model.
This means that the execution of the GUI code occurs during the process of model simulation and therefore less handshaking is required between the GUI and the model because of their inherent relationship using this method.
In order to create the sink block that displays the signal in a plot inside a figure window as shown in the example above, Nitin uses a MATLAB S-Function.
Nitin also provides some nice documentation to describe what was required to create this type of GUI via custom Simulink blocks.
The most sophisticated approach is to listen for events generated by the Simulink model during various phases of editing and execution.
This is the approach that Phil Goddard takes.
In some ways it is similar to the approach that Will took. But instead of using the Model and Block callback functions to maintain synchronicity between the model and the GUI, Phil creates event listeners that execute a function when a particular event occurs in the Simulink model.
Using this method allows for a very tight integration between the model and the GUI without the need to populate model callback functions. Therefore the code for the GUI can be maintained completely independently of the model, and won’t interfere with using the model for other applications such as manual simulations without the GUI or model referencing.
In summary, how do the methods addressed in the three File Exchange entries above compare?
|Block||Model Callback||Signal Access||Difficulty|
- Block - requires adding a block to the model to enable the GUI
- Model Callback - requires populating the callback properties of the model or blocks in the model
- Signal Access - able to access signal values during simulation
- Difficulty - relative difficulty of creating these types of GUI implementations
If you would like to leave any comments regarding this post, please click here.
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.