Simulink Coder error: Cannot generate code for models with more than 32 switch elements in one physical domain

I'm using PLECS Blockset for a rather complex converter system that currently includes 72 switches and can go up to much more than that. I want to build this model and run it on a real-time simulation on OPAL-RT. However, when I try and build the model offline in Simulink I get this code generation error related to the number of switches:

..........................Code generation for circuit 'two_cell_rt/sm_computation/Circuit' aborted due to an error: Cannot generate code for models with more than 32 switch elements in one physical domain.

### Build procedure for model: 'two_cell_rt' aborted due to an error.

Error:Error: Simulink Coder Error in block: "two_cell_rt/sm_computation/Circuit/ S-Function ", block type "S-Function": Cannot generate code for models with more than 32 switch elements in one physical domain.

I find it strange because it sounds too me like it's a processing power/memory limitation of some sort. I mean, the OPAL-RT is definitely equipped with enough processing power to handle this and this code generation is done offline anyway, so I don't understand why it's being limited like that. Is there any way to circumvent this?

Answer 1

[Grégoire (Greg) Le Goff, PhD]

Hi, I have just encountered the same exact problem: Using the PLECS Blockset in Simulink to emulate my power converter and then compile it for an "asynchronous simulation" using Opal-RT. And I have no clue how to deal with this problem in first place.

I agree with you that in the case where you aren't in "synchronous simulation" (meaning real-time), the Opal-RT HIL box should be able to use as much time as needed to do all the computations when having any number of switches.

But, you know, the limit number "32" makes me think about something.. Wouldn't it be a limit linked to the fact that the Opal-RT box is using a 32-bit based CPU ? Knowing that the switches states are 0 or 1, they would have thought of using an entire 32-bit string to pass the switch states to the CPU within the HIL box for the simulation ? ..Meaning that this limitation would be a "hard" constraint coming from how the HIL box computation hardware was designed.

Could a solution to the problem be to split our converters in several "physical domains", meaning several PLECS yellow blocks in our Simulink ? (I don't like this solution since it means changing the entire circuit diagram in PLECS, but could it at least work ?)

PS: When I read "rather complex converter system that currently includes 72 switches and can go up to much more than that" it makes me feel like our converters could be the same, are you trying to model a CHB or a MMC ?