Thanks for the clear summary of your issues.
To begin, I would suggest you review the Fixed Step Simulation section of the PLECS manual, including the and the Interpolation of Non-Sampled Switching Events. The documentation explains how the fixed-step solver will detect zero crossing events in between sample times and then perform a linear interpolation scheme to determine when that event occurred. This is an important technique to improve the accuracy of fixed step solvers.
The challenge for real-time execution is that this zero-crossing / linear interpolation step can lead to timing jitter. The generated code (used in the Code Gen simulation) does not include this interpolation technique and always moves forward in time at each simulation step. In the event of say a diode turn off, the diode will only turn off at the start of the next-step for Code Gen. There is no switching sequence that can occur between simulator steps as the next step is based only on the information at the start of the current step. This does introduce error, but when using Code Gen one also combines that with sub-cycle averaging or other techniques which reduce the sensitivity to the non-sampled events.
With that hopefully clear, let’s take a step back and review your goals. What are you trying to do? Presumably you have a model you would like to run in Code Gen mode, whether on the RT Box or for some other purpose and you want to check its accuracy.
Is that correct? If not, can you explain what the purpose of the fixed-step simulation is? I will acknowledge that sometimes in cases of systems with large numbers of switches (such as a shipboard power system) a fixed step solver may prove advantageous in terms of speed.
If my assumption is correct, then the most accurate benchmark isn’t a fixed-step solver - it uses a different solver technique and the model accuracy is closely tied to the fixed step value you have determined to be 2.5 usec. The reason why the Plexim team suggests the variable step solver is that the accuracy of the model is tied to the accuracy of the states, not some time step. Note you can use a variable-step solver with the Code Gen simulation, so your assertion “Because I want to run the model in Codegen (code generation) execution, I am using a fixed-step solver with Tstep = 2.5 us.” isn’t 100% necessary. So the typical benchmark suggested is to use a variable step solver and compare that with Code Gen.
To your questions:
- My understanding was that non-sampled zero-crossing detection is mainly a variable-step solver feature, used to locate switching instants between steps. Why is this evaluation performed in Normal mode under a fixed-step solver?
See Interpolation of Non-Sampled Switching Events.
And does the “increase the refine factor” suggestion actually apply to a fixed-step solver, or only to variable-step? In fixed-step I don’t see how I would increase the number of zero crossings.
Refine factor adds additional “low-computational cost” output values between the defined solver steps. This might help better resolve the moment of the zero crossing, however it isn’t applicable to .
- Since the same circuit runs without error in Codegen at the same step size, does the Normal-mode failure indicate a genuine problem in the circuit, or is it a consequence of how Normal mode resolves ideal-switch states (i.e. the switch manager iterating on a configuration that chatters and never converges within one step, whereas Codegen resolves switch states differently)? I’d like to know whether a clean Codegen run is sufficient evidence that the circuit itself is fine.
I cannot say without a model or more comprehensive understanding of the model. Code Gen simulations may “jump” over the issue that could occur between steps. Again I would suggest using a variable-step solver as the validation method, not a fixed step.
- I want to keep running the model in fixed-step Codegen execution, so “use a variable-step solver” and “reduce the step size” are not the solutions I’m looking for. What are the recommended ways to mitigate this error without changing the effective time step? For example, would enabling non-ideal switch (on-)resistance, or some other setting, suppress the iteration failure?
Again, you can use a subsystem in Code Gen mode but combine with a variable step solver. For example, this will help you get more accurate PWM placement if your PWM generator is outside of the Code Gen subsystem.
If you are determined to use a fixed-step solver then there are other settings to adjust. Most critical is the step size. For the purposes of benchmarking what happens if you set the step size 1) half of its current value and 2) 1/10th of its current value? Does this tell you your current step size appropriate? You can also change some of the solver options - for example setting the “Diode turn-on threshold” to something small like 0.01 might help resolve the chattering. It is possible the other “ZC step size” and tolerance settings could improve things as well.
If you are using Non-Ideal Switches then setting the non-ideal switch resistance is also very important. If you are using ideal switches then it isn’t relevant.
- Is there a way to identify which specific switch or comparator is causing the excessive iterations, so I can target the fix? I suspect one of the PWM-controlled converters is the source, but I have not confirmed which one.
There isn’t an inbuilt diagnostic. This is difficult to say as it might be multiple switches interacting. If possible you can try disabling certain subsystems you suspect are chattering to zero in on the issue.
