Unexpected input values on the first call of the function-call subsystem

Hello,

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

Its parameters are fed by values from inports, and all of this runs in the "Function-Call Subsystem".

Edit2: Picture of input signals

I figured out that initial integrator output is different if it is configured from the constant value and if it is fed by the inport.

As this value is taken on the first step of the execution (x0 of the saturation), it showed the following results:

1. Constant value for "Integrator and Filter initial conditions": Works as expected, e.g. const=50, output starts from 50.
2. Variable fed from the InPort for "Integrator and Filter initial conditions": Shows misbehavior. Output starts from the lowest allowed (0 if no output saturation configured).

I've tried to plot this value coming from the inPort, and recording in the scope looks good. Value coming to the inport is as expected from the beginning of the simulation.

1. Missbehavior

2. Expected behavior (but feeding integrator input with const value in this case, which I'm trying to avoid)

Edit1: Scope legend - blue = desired value; yellow = controller output (duty_uint)

Answer 1

[Djordje]

The issue was that pulse generator, which generated function call signal, generated it at the very beginning of the simulation. In the execution order, it was executed before another component which prepares signal (dutyInit) value. Therefore, at that point of time, dutyInit input had value 0.

Answer 2

[Shivam Gothi]

Hello @Djordje,

Based on my understanding, the "PI(z)" controller block functions as expected when initial conditions are provided externally using a "constant" block. However, when you use the variable "dutyInit" to pass the same value, the output differs.

I have a potential workaround to address this issue. You've mentioned that the variables are defined within a subsystem called "Function-Call Subsystem," and you are utilizing "Goto" and "From" tags to transmit these values to the "PI(z)" block, which is located outside the subsystem.

From the screenshot you provided, it appears that the visibility of the "Goto" tag (inside the “Function-call subsystem”) is set to "local." This setting means that the "From" tag for the variable "dutyInit" cannot retrieve the actual value from its corresponding "Goto" block (which resides inside the subsystem), causing the "PI(z)" block to receive an incorrect value, likely defaulting to 0.

To resolve this issue, please open the "Block Parameters" of each "Goto" block and change the "Tag Visibility" field to "global" using the dropdown menu, as illustrated in the figure below:

The block appearance will change and the “[]” brackets will be removed from the variable name as shown in the below figure:

Please refer to the documentation for more clarification:

https://www.mathworks.com/help/simulink/slref/goto.html#mw_9ab21364-2bea-4ce6-957d-a70626e22839

This approach ensures that the proper value is passed to the “PI(z)” block.

I hope it helps !

[Djordje]

Hello @Shivam Gothi,

This variable comes to the subsystem from the parent model (which I should explain better in the description).

It is generated by another model called from the parrent one.

When I checked execution order list, pulse-generator (function trigger) was higher than model which sets the value. After delaying trigger pulse for only one simulation step, everything worked correctly, and PI controller was fed with proper value from the start.

Do you have by the way some proposal how could I proceed further? Is it possible to put Pulse-Generator lower in the execution order list?