PID Controller - non-adjustable parameters

Hello,

I am using PI controller (original library name "PID Controller") component.

Customized, it looks like on the following picture:

Project requirements are that all the "parameters" are customizable, and changeable during the runtime.

Most of them, I succeeded to configure as "inputs", and that works.

Issue comes with certain parameters, which become hardcoded in the model, and therefore hardcoded also in the generated C code. These parameters are: Integrator saturation limits (Upper limit, Lower limit)

Is there a way to feed these parameters also externally? Or, is there a better common practice to handle these situations? Reason for doing so is the project maintenance. Different users could code their parameters in external memory regions, without need to reflash an MCU and touch the control-loop algorithms.

[Aquatris]

Any reason why you should use the build-in PID block? Otherwise you can just create your own PID block with more flexibility.

[Djordje]

Main reason is because built-in block is already developed, tested, customizable in many ways. This time and money someone already put in the efforts and their internal processes, so I though to try to use existing solution as much as possible.

I though on creating my own, and one of options would be doing copy-paste of the built-in one, and doing slight modifications. That is still on the desk, but currently I am trying to avoid it, as it would cost time. That kind of solution is also on the desk.

[Aquatris]

Then my next question is there a specific reasong to set the integrator saturation level independently then the output saturation value?

The output saturation value already disables the integrator via clamping (as selected by the drop down menu). So unless you put an integrator saturation value that is lower than the output saturation value (which I cannot think of a solid reason), the integrator saturation value would not do anything.

[Djordje]

So, you meant to say that in this topology, there is no possibility that integrator part gets winded-up separately?

Is this scenario possible: There is disturbance, and integrator part winds-up. Output is saturated, so everything is in allowed thresholds. Disturbance is there for a some time, and integrator part is growing all the time. Disturbance dissapears. Integrator part starts unwinding, but as it growed, it needs multiple cycles to decrease under output saturation value. Time it is decreasing, our system is still giving saturated output, instead of normal one (has kind of lag).

So, are we sure that with saturating complete output, we prevent also integrator output to grow out of boundaries independently?

Answer 1

[Djordje]

Disabled integrator saturation based on the proposal from @Aquatris.

Keeping output saturation, only. Experiment is performed, in order to ensure that integrator part will not wind-up independently.

If integrator saturation is potentially needed in future, idea to modify built-in component will be the first candidate for the solution.

Answer 2

[Aravind]

Hi @Djordje,

It seems like you want to configure the saturation limits of the integrator externally during code generation. You can accomplish this by setting the storage class of the parameters representing the saturation limits to "ImportedExtern." This approach will make the generated code declare the parameter as a global variable using the "extern" keyword in C. You can then define the value of this variable in a separate header file, allowing users to adjust the parameters without altering the MCU firmware or control algorithms.

To change the storage class of a parameter in Simulink, you can follow these steps:

1. Open your Simulink model, go to the "Modeling" tab, and click on "Model Explorer."
2. In "Model Explorer," navigate to the "Base Workspace" or the specific model workspace. Find and select the parameter you want to modify.
3. Double-click on the parameter to open its properties dialog. Locate the "Storage Class" field and select the needed storage class from the dropdown menu.
4. Click "OK" or "Apply" to save the changes. Update your model by clicking the "Update Model" button or pressing Ctrl+D.
5. Regenerate the code to ensure the changes are applied.

You can also use the "Code Mappings Editor" to achieve this. For more details, you can refer to the documentation here: https://www.mathworks.com/help/releases/R2024a/rtw/ref/codemappingseditorc.html.

Here are some additional resources to help you with choosing storage classes for parameters in your Simulink model:

1. Choosing storage class for controlling data representation in generated code: https://www.mathworks.com/help/releases/R2024a/rtw/ug/choose-a-built-in-storage-class-for-controlling-data-representation-in-the-generated-code.html
2. Configuring parameters for Code generation: https://www.mathworks.com/help/releases/R2024a/rtw/ug/configure-parameters-for-code-generation.html
3. Different storage classes available for code generation: https://www.mathworks.com/help/releases/R2024a/ecoder/ug/storage-classes-for-code-generation-from-matlab-code.html
4. An example on changing storage classes and their effect on the generated code: https://www.mathworks.com/help/releases/R2024a/rtw/ug/configure-model-data-for-c-code-generation.html

I hope this helps resolve your query!