Relax real time requirement on Speedgoat on startup

Hello,

We have a model running on our Speedgoat Unit real-time target machine. Our aim is to run the model at a smaller timestep, we are aiming for a timestep of 0.2ms. Currently, the timestep is 0.66667ms.

I have attached an image from the TET Monitor. As can be seen in the image, for the main model BaseRate (0.00066667s), the min/max TETs are 0.112ms/0.213ms.

I appreciate I cannot run the model at 0.2ms, because the maximum TET is 0.213ms. However, when I am viewing the TET during real time operation, it is always much closer to the minimum, i.e. it never goes above 0.15ms.

I guess it only reaches the maximum TET (0.213ms) when the model is starting up in the first few seconds. Is there any way to relax the real time requirement when the model is first loaded to the simulator? For example if the first second actually takes 10 seconds this is fine as long as it then starts running in real time after. Alternatively, is there any other way to deal with this?

Thanks

Answer 1

[Dimitri MANKOV]

Hello Thomas,

Absolutely, this is possible using the SLRT Overload Options block, either via the "Startup duration" setting (if you'd like to tolerate some overloads specifically at startup) or via the "Max Overloads" parameter.

Note that allowing the CPU of the target computer to overload can cause incorrect results, especially for multi-rate models. Use this block only for diagnostics or to monitor sporadic CPU overloads, not as a tool to avoid systematic CPU overloads!

Hope this helps.

Dimitri

[Thomas]

Thanks Dimitri, that worked well. We are also using Simscape so I found "Start simulation from steady state" also worked.

Is there any way for the simulation to catch back up to real-time after an overload?

For example, if we have a timestep of 1s, but at 100s there is an overload and the step execution time is 2s. Then for the subsequent steps the execution time is only 0.5s, the simulation could catch up. At present, after the overload the simulation will always be 1s behind where it would have been had there not been an overload. This is what we would ideally like to happen, but I guess it may not be possible?

• Step: 100, Real-time since start: 100s, Simulation time: 100s, TET: 2s
• Step: 101, Real-time since start: 102s, Simulation time: 101s, TET: 0.5s
• Step: 102, Real-time since start: 102.5s, Simulation time: 102s, TET: 0.5s
• Step: 103, Real-time since start: 103s, Simulation time: 103s, TET: 0.5s
• Step: 104, Real-time since start: 104s, Simulation time: 104s, TET: 0.5s