Neil,

no there is no way to guarantee that, when the simulation runs in real-time (scaled or not), that's the only thing it cares about. It will pass in any input it gets during a time-step to be used for the next time step, but it won't wait for data.

As you say, the FMI co-simulation approach solves that problem (and removes the overhead of having to pass everything over TCP/IP.

The process would be something like: 1. Initialize simulation 2. Get outputs/set inputs 3. Advance time to tn 4. Repeat from 2.

So no, you wouldn't need to reinitialize the FMU (as long as what you want to change can be exposed as inputs).

Regards, Otto

Otto,

If you use the first approach and I want to send a command to the simulation every millisecond, you say that I can slow down real time and interact with the simulation, is there a way to guaranty that the commands always go into the input at every millisecond of simulation time? (make sure that inputs are not “lost” or doubled up). For example, can I use this approach to "control" a simulation by reading an output, calculate something in MMA and send a new input and guaranty that I do not miss an input?

The second approach seems to solve this problem. Will the FMU approach be controllable as described above? (Have the FMU send an output and then process it and return the new input and run the FMU again) Will there be any speed hit for using an FMU because the simulation must be reinitialized?

Regards,

Neil