The comments from this previous post are still very relevant. It seems you did not address them in your revised model.
Your control strategy appears to be heavily dependent on the three Memory blocks and having the correct initialization conditions when the simulation starts at `t = 0`.
In an offline simulation, this often works well because the controller and plant start simultaneously. However, in a real system (such as a HIL platform), the controller and plant do not necessarily start at the same time. As a result, algorithms that rely heavily on previous-step values can behave very differently than they do in simulation.
Your PV model and MPPT algorithm also have zero filtering. Any noise couples immediately into the controller behavior.
You can test your model in the CodeGen mode. I tried modeling the Controller and Plant in CodeGen mode separately. This reveals that when the Controller is modeled In the CodeGen mode you’ll see it doesn’t work due to the initial conditions issue pointed out previously. The Init_mem2 value is actually 0 when you intend it to be 0.5. The MPPT can’t seem to recover if the Init_mem2 value is 0.
My colleague also suggested a better structure for the integrator initial conditions, where the initial condition is fed into the delay block rather than after the delay block. This holds the integrator value to the desired level in the reset mode. In the original arrangement the sum feeds through when in reset mode so the initial condition for the integrator is based on the input history. This simple change, shown below, helps the offline model work correctly in CodeGen mode. Note I also set the initial condition of the delay block as 0.5 which is relevant for the very first model step.
