This step is also demoed with this video :

(ongoing...)

Step 0b : Calibration of a module

This step in video : https://youtu.be/A23SXOFVLdE (it might be more convenient to copy/paste this link in your usual internet explorer).

In previous steps 0 and 0a, we've seen how to create a module and execute a module.

In this step 0b, we'll see how to calibrate it.

As explained in previous step, a module is a piece of code consisting of a simulink library associated with its calibration script :

Most of the time, modules need variables to be executed. The aim of the calibration script is to assign all the required variables for the module.

Fundamentally, a module is completely independent in terms of :

• 1. Simulink

  2. Variables

In practice, it may not be completely achievable for following reasons :

• • A user may use his own Simulink librairies inside a module

  • To compute variables, some scripts may use external routines

Then, some modules may be fully independent, some may have their Simulink library user dependent, some may have their calibration script user dependent, and some may be user dependent in both ways.

For example :

When a module is user dependent, other users may not be able to correctly use this module.

If users sharing the modules are close, they may use same librairies, or routines.

If it's not the case, for example a colleague from an other department, module may not be able to be executed.

In that case, there are basically two possibilites :

• 1. specific librairies and routines are distributed too

  2. module has to become independent

How a module can become independent? :

• 1. links to specific librairies are broken

  2. calibration script explicitly defines variables

Here is an example of an explicit assignment using equal :

Some variables may also be explicitly assigned using a mat file :

These files must be located in the same folder as the calibration script :

Suppose that module can_BIS_vU0 uses 4 variables :

Simulink tries to resolve (see Simulink documentation) the values by searching in order inside 3 workspaces :

• 1. SubSystem workspace : it is defined by the mask if any

  2. Model workspace

  3. Base workspace

This is the choice of the user to decide which variables are declared in the mask.

Main advantage of using a mask is that a same variable name may be used in different modules without risk of conflicts.

For example, a proportional gain named kp can be used in different modules with different values and the same name : this is very convenient.

Suppose that for module can_BIS_vU0 user decides to define variables offsetCanYawRate and scaleCanYawRate in the mask :

The user adds these variables in the mask in the library of the module :

Remark : if a St parameter exists, if will be assimilated to Sample time value.

This parameter is not specified in the calibration script. It is specified when adding a module into an assembly (see step 1a)..

Calibration script is the start of the calibration process. What is this process?

From the calibration script, process determines 3 categories :

• 1. variables required by the mask found in the calibration script

  2. variables required by the mask but not found in the calibration script

  3. variables assigned during in the calibration script but not required by the mask

Variables from category 1 are written in every mask of can_BIS_vU0 in use.

Variables from category 2 are written as [ ] in every mask of can_BIS_vU0 in use.

Variables from category 3 are written in the WS 'base'. For example :

To do so, the Calibrate button can be used at any time (a module must be selected to be enabled) :

For example, for module can_BIS_vU0, a rank 2 GUI opens and gives status :

The three categories are illustrated through this example.

What happens if a module can_BIS_vU0 is in use in a Simulink model?

To illustrate this, suppose that this model (click to open) uses module can_BIS_vU0. By clicking on the module, mask values appear as 0 :

By calibrating again the module can_BIS_vU0, one can get :

As we can see, a mask in use has been found and has been calibrated accordingly :

Suppose now that a module need variables from other class than classical numeric. As an example, open calibration script of can_BIS_vU3 :

In this case and to avoid confusion, some variables are used to assign the true value. To illustrate this, suppose that this model (click to open) uses module can_BIS_vU3. By calibrating module can_BIS_vU3, you will get :

Note that theoretically, var offsetCanYawRate should be assigned in the mask through via variable can_BIS_vU3_var1. Nevertheless, in case of numeric [1x1], the value is explicitly written in the mask for better readiness (via variables is always available in the WS base).

What happens if an error occurs during the calibration scrip execution?.

For example, if module can_BIS_vUcalError is calibrated, :

the following message is displayed :

In this case, it can be convenient to publish the error message for futher investigations in a second time.

Indeed, by opening the script calibration of can_BIS_vUcalError, the error appears clearly :

At the beginning of this step, we noticed that the dependency of a module to its designer can be among :

MecaTroniX will use the module without restrictions independently of its user dependency, and afterwards Matlab may cause relevant errors while calibrating, or Simulink may cause relevant errors or warning, because of uknown routines or/and unknown Simulink librairies.

In this step 0b, we've seen how to calibrate a module.

Next step 0c deals with the Simulink functionality : insert a module in a Simulink model

Published with MATLAB® R2013a