In as we speak’s put up, I proceed extending the framework launched over the previous few weeks. If you happen to missed the earlier posts on this sequence, listed here are hyperlinks:
To date on this sequence, the framework I launched has been largely targeted on configuring a mannequin, with the mindset of merely “choosing a component” by instantiating a MATLAB object from a library of MATLAB lessons. On this put up, I lengthen the concept of “Unifying MATLAB and Simulink” to managing and post-processing logged knowledge after simulation.
By the tip, I hope you will note how this slPart framework results in totally contained elements that embrace pre-defined parameterizations, variants, and capabilities/strategies to work together with it in MATLAB. Assuming the slPart has been created and validated by a website knowledgeable, it will possibly then be shared with different customers and easily utilized in an easy and straightforward to find method.
A Methodology to Retrieve Logged Information
Once I created the slPart class, I added a BlockPath property, mentioning that it was going to be helpful later. It is now time to make use of it!
classdef slPart < deal with
properties (Hidden = true)
BlockPath char
Log Simulink.SimulationData.Dataset
finish
strategies
operate obj = maskInit(obj,blk)
% See earlier posts
finish
operate obj = getLog(obj,out)
obj.Log = out.logsout.discover(‘-regexp’,‘BlockPath’,[obj.BlockPath ‘(/.*)?$’]);
finish
finish
finish
That method, if I simulate a mannequin with a number of components, every half will be capable of retrieve its personal knowledge.
For instance, let’s put two copies of the spring with variants created within the earlier put up and parameterize them with totally different objects.
Assign objects of various lessons to every of them and simulate. As soon as the simulation is full, every object can retrieve its personal logged knowledge:
mySpring1 = springLib.springN1234;
mySpring2 = springLib.springNonLinearV1;
mySpring1.Log
mySpring2.Log
Defining Customized Submit-Processing and Visualization
matlab.diagram.ClassViewer(‘Folders’,currentProject().RootFolder);
After this reorganization, I added a easy plotPower methodology to the spring class. Since every spring subsystem has two logged indicators, named “velocity” and “pressure”, I multiply them to create a “energy” timeseries and plot it. Here’s what the spring class appears like:
classdef spring < slPart
strategies
operate plotPower(obj)
energy = obj.Log.get(‘velocity’).Values*obj.Log.get(‘pressure’).Values;
energy.Identify = ‘Energy’;
plot(energy)
finish
finish
finish
Utilizing the identical mannequin as above, I can then name this methodology for every object inheriting from the spring class.
mySpring1 = springLib.springN1234;
mySpring2 = springLib.springNonLinearV1;
mySpring2.plotPower;
Now it is your Flip
Now that I lined variants and logging, I hope that the advantages of getting a framework like this one have gotten clearer.
When sharing a element developed on this framework with different customers, what they obtain isn’t just an algorithm carried out in Simulink; in addition they obtain a set of pre-defined parameterizations and a set of capabilities/strategies to work together with it, created and validated by the area knowledgeable who created the element.
Along with that, tab-completion additionally helps discovering what is obtainable with such a element.
What you consider a framework like this one? Do you suppose future variations of Simulink ought to include extra built-in functionalities to facilite such a workflow? Tell us within the feedback under.
