Building large, slow models and getting timeouts at 240 seconds

RT Box
1

Hello,

I am making a simplified battery cell simulation for a large pack and running into issues with compilation timing out. The timestep is low in the 1-2ms range. A slightly simpler model is running and only taking a few percentage points of CPU usage, so execution time-wise it should be ok. I believe the primary issue is the high number of internal signals.

In the info.xml file in the coder targets folder, I can see multiple of these 240s timeouts. Is it reasonable for me to extend these or could the timeout be due to something else?

Thanks

2

The reason the build process is stuck at this step is typically due to the large number of switching combinations possible in the model. I suspect between the simpler and more complex model the number of switches is increased.

Refer to the first few pages of the “RT Box: Model Optimizations” tutorial on the Plexim website. for a conceptual description of the problem. The typical solutions to this challenge are:

  • Model splitting, as described in the optimizations tutorial, is one way to reduce the number of switching combinations in the generated code.
  • Use components from the Electrical + Power Modules section of the PLECS library. The tutorial describes how this reduces the number of actual switching combinations for common topologies.
  • Change the switch type from ideal to non-ideal. See this section of the PLECS documentation which describes the differences between the two approaches. Non-ideal switches can work both for CPU and FlexArray based real-time simulation.
  • Use the FlexArray solver if your RT Box hardware supports it. This approach requires the use of non-ideal switches for all devices, resolving the switching combination issue (this is done in the background and issues a warning notification if there is a conflict between the switch model types). Furthermore, the overall step size of the electric circuit model will decrease.

With a model I can give you more direct guidance.

However, I can make some initial guesses as to next steps. Since you’re working with a battery pack, I suspect that each pack may have one or more associated switches for each battery that do not switch very often (e.g. reverse-bias diodes, charge balancing circuits, etc.). These are good candidates for non-ideal switches. If these are switching converters, then naturally you should use the correct real-time optimized implementation from the Power Modules section of the PLECS library. For an integrated battery pack, I suspect there are limited opportunities for model splitting, but perhaps if you have a battery + motor drive, then you could likely decouple the motor drive.

You are welcome to try increasing the timeout value in info.xml. Large compilation times indicate large source files, which in turn indicates large execution times, so you should be prepared to run into other problems.

3

Hi Bryan,

I tested adding +100s (340s) to the info.xml and it is working again. My model is pretty simple with mostly LUT, math, and unit delays (also discrete integration). It does appear that the ideal switches I added to another simplified, separate, parallel model for contactor precharge modelling pushed me over the edge before.

That being said, are there some practical limits here with memory/elf size that you are aware of? The _linked.elf is around 3.4KB. The CPU usage is only in the 6% range for my 2ms timesteps (again super simplified), so not constrained in this dimension.

Thanks for the quick support.

4

Thanks for the update Chris. Glad to hear that solution worked - in your application with a large time step and plenty of CPU cycles to spare it sounds like the right approach. And if the precharge circuit should introduce issues again then the non-ideal switch tip should be useful.

That being said, are there some practical limits here with memory/elf size that you are aware of?

The limit enforced by the software is 200 MB when using the build from PLECS or loading via the web GUI. I’ve seen practical models in the ~15 MB range work fine and I’m sure users have been successful with even larger models, but it all depends on the application and step size requirements.

5

The _linked.elf is around 3.4KB.

If this isn’t a typo then compiling code for 300 seconds just to produce 3.4 KB of object code sounds awfully inefficient. Can you share the model? (Use support@plexim.com if you don’t want to share it publicly).

6

I sent to the support email just now.

Thanks

7

On my machine, the generated C-file is 1.9 MB and the _linked.elf file is 3.4 MB. For files of this size the compilation time sounds about right.

You can simplify the generated code slightly be using only a single task, since you have a lot of signals crossing task boundaries. This will generate a lot of task transition code which maybe can be avoided if you have enough CPU bandwidth left.