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.
Get the MATLAB code
Published with MATLAB® 7.14
Comments are closed.
6 CommentsOldest to Newest
This is a useful review since related questions pop up all the time on Answers.
@Greg, Would you comment on the performance of these methods?
By performance, I assume you are referring to the execution time required for the Simulink simulation.
Execution performance is difficult to generalize because it is a function of the specific attributes of the simulation.
Hypothetically, if I implemented the same functionality for a GUI using the same methods described above, I would expect that using the SET_PARAM API would have the least impact on simulation execution time.
The reason I believe this is because Simulink does not need to call the MATLAB Interpreter throughout the execution of the simulation. Instead the exchange between Simulink and the MATLAB Interpreter is much more limited. But this also limits you ability to do things like plot signals in the GUI during the course of simulation.
Both the S-function approach and attaching event listeners to the Simulink model require that the MATLAB Interpreter be invoked to execute MATLAB Code throughout the course of the Simulink execution.
This exchange between the Simulink engine and the MATLAB Interpreter can slow things down.
But as with any question about performance, the question really becomes “what is fast enough?” While implementing a given GUI functionality using the three methods described above, each implementation might produce differing performance results. But would you notice the difference? Maybe, maybe not. Again we end up back to the difficulty of generalizing questions regarding performance.
What about changing variables in the model workspace? This is what I’ve always done for this type of application.
Did the event listener method on a large, complex model and it becomes uselessly slow…