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.