Why does this simulation give completely different results between offline and on-hardware (HIL)?
Attached you will find the model.
Inverter_Double_loop_offline_28069_used.plecs (313.9 KB)
Many thanks.
Hi liuwenj,
It would appear that your control algorithm is extremely sensitive to delays.
While the offline model captures a significant portion of the system delays, one delay that cannot be accurately represented is the controller calculation delay. This delay is highly dependent on the processor and the execution time of the generated code.
With the model as provided, I measured approximately 85% CPU utilization. By simply disabling all scopes, the utilization drops to approximately 60%.
In addition, within the P_F control loop, I removed the computationally expensive mod function and instead enabled wrapping on Discrete Integrator6 with upper and lower limits set to 2*pi and 0, respectively. With this change, the utilization drops further to approximately 52%.
With only these changes and nothing else modified, I can already see a significant difference in the real-time simulation results.
The graph on the left shows the three-phase input currents and voltages using the original model. The middle graph shows the results with only the scopes disabled. The graph on the right shows the results with both the scopes disabled and the integrator optimization applied.
These changes appear to have a significant impact on the behavior of the controller.
I would recommend reviewing the control algorithm and identifying computationally expensive operations that could potentially be reduced or eliminated. Some examples include:
- Excessive saturation and limit-checking blocks
- Park and inverse Park transformations
- Trigonometric operations (
sin,cos, etc.) - Modulus operations (
mod,rem, etc.)
Of course, many of these operations are necessary for the control strategy and cannot be completely removed. However, it is worth carefully considering whether they are all required at their current execution rates.
This becomes particularly important because the F28069 is significantly less capable than newer generations of C2000 devices.
I also suspect that the controller may need to be tuned to be more robust to delays and timing variations.
Another source of delay that may be important is the ADC conversion sequence.
Currently, all 12 channels are being converted using ADC A. A potentially better approach would be to distribute the conversions across both ADC modules:
- 6 channels on ADC A
- 6 channels on ADC B
This would reduce the total ADC conversion time and provide additional time for the control algorithm to complete before the compare-register shadow update event occurs.
You should also consider the ordering of the ADC conversions. In many power electronics applications, it is advantageous to sample currents before voltages, since delays in current measurements can introduce control offsets and phase errors that are difficult to compensate for later.
Hope this helps!