Recently, when we used the RT Box 1 as the controller in our converter experiments, we observed a strange phenomenon. The circuit starts up normally at power-on, but after running for less than about one minute, one part of the system suddenly loses its waveform, which then causes the entire circuit to collapse. However, the RT Box itself does not report any error.
We would like to ask whether you have encountered a similar problem before, or whether you might have any suggestions for troubleshooting or solving it. I have attached the simulation file for your reference. If needed, I can also send the recorded video by email. Thank you very much!
model.plecs (518.3 KB)
Could someone give me some advice? 
Hi pimagine,
Your model is quite involved and only contains the controller, so it is unfortunately not feasible to recreate the issue or run an offline simulation.
A few questions that may help narrow this down:
-
Have you run an offline simulation to determine whether something in the control strategy becomes unstable over time?
-
I’m not entirely sure what you mean by “suddenly loses its waveform.” Could you elaborate on what you are observing?
For example:
- Is the ADC no longer being sampled?
- Is the controller no longer updating its outputs?
- Are the PWM outputs stopping?
- Does the waveform become distorted or simply disappear?
-
Is anything occurring in the system after approximately one minute that does not occur beforehand?
For example:
- a load step
- a mode transition
- a change in operating point
- an enable/disable event
- a parameter saturating → I see a number of integrators that have no saturation defined. Is it possible that these are just integrating to very large numbers and eventually overflowing?
If you have an offline simulation available, I would recommend investigating whether this is related to the control strategy. If feasible, please also provide the plant model, as that would make it much easier to reproduce and debug the issue.
Hope this helps.
Thank you for your reply.
We have carried out offline pure digital simulations, and no instability emerges with extended simulation time. In practical tests, the ADC operates normally, yet one controller suddenly outputs zero entirely, which causes the modulating waveform to vanish. No changes were made to the system during operation.
We can send you a full test video via email if needed, and below is a clipped snippet from the footage.
The faulty controller scope:
Normal operation:
Fault occurs:
System instability occurs:
Due to laboratory regulations, we may need to send our pure digital simulation files to you via email.
Hello, it has been two days since your last reply. Do you have any solutions for this issue? Please advise us promptly once you have any updates, as this is of great importance to us. Thank you.
How, exactly, is anybody supposed to know what happens in your controller from the screenshots that you have provided?
Could you provide your email address? I will send you the video file, from which you can clearly observe how the fault occurs.
We observed an abrupt disappearance of the QPR controller’s output waveform mid-test, crashing the experiment.
You can send additional material to support@plexim.com, referencing this forum post. However, I’m not sure a video will help in debugging. If possible, try to provide a (simplified) model that reproduces the behavior that can be run on an RT Box without additional hardware.
Please also specify which version of PLECS and which version of the Target Support Package for the RT Box you are using.
One obvious point is that your model is too large to run with the specified step size. With TSP 4.0.6 and external mode activated, the cycle time often exceed 30µs, while your base step size is only 25 µs. This can well explain a sudden stop of operation.
The PLECS version we are using is 4.9.8, and the RT Box Target Support Package version is 3.0.6. The additional materials have already been sent to this email address.
We will increase the step size and run the experiment again to see whether the issue still occurs, and we would like to know what step size is appropriate for this version.
You can view the CPU load in the web interface of the RT Box. You can also see log entries for overruns in the “Diagnostics” tab in the web interface.
Another source for potential disaster is that you are using the measured voltage, Udc, as divisor in several places, which will result in inf or nan values if Udc ever becomes 0. This will result in undefined behavior of your controller.
We have taken the case of zero Udc into consideration and implemented corresponding protective processing. Since Udc is obtained via real-time sampling, we initialize it with a preset starting value to avoid division-by-zero errors during calculation.
We have taken the case of zero Udc into consideration and implemented corresponding protective processing.
Good. However, not in the model you posted above (to the contrary, the initial output of the periodic averager after the AnalogIn block is explicitly set to 0). If you have updated your model, please share it, since debugging an outdated model is pointless.
Okay, thanks for your suggestions. We will redo the experiment accordingly and post updates on the forum promptly once we make new progress.
Also note that the lowest of your continuous transfer function in the “control of APD/QPR_246_2” subsystem becomes unstable when used with a fixed step solver of 25 µs (see attached model). You may have to replace it with a discrete transfer function.
InstableTransfer.plecs (4.9 KB)
Hello, recently we redid the experiment and found that the previous program used system resources very heavily during simulation, which caused the experiment to stop after a short time. Later, we removed some unnecessary control programs and oscilloscopes, and now the simulation can run normally with the original step size. Thank you for your help.
