Why is there a time difference between the "clock" block and the "elapsed time" block converted to nanoseconds by using the "time stamp delta" block?

I am using real-time Simulink along with a data collection system. The system records some data (e.g. motion capture data, ground reaction force, etc.), and it sends a HIGH signal to the real-time machine while it is recording the data. I would like to sync this data with my Simulink data, so I would like to confirm if the time in Simulink is consistent.

I want to know for the 1:1000 data recorded from Simulink (running at 1kHz), does it precisely correspond to "0.001:0.001:1" seconds in real time?

In order to check if 1 second in the simulation corresponds to 1 second in real time, I included a "clock" block and an "elapsed time" block in the same model. I am converting the elapsed time to nanoseconds by using the "time stamp delta" block and the time instance when the simulation starts. I created a script that calculates the difference between these two times and plots it. I am expecting this difference to be zero. It starts as 0, but then it increases linearly. Why is the difference between the "elapsed time" block and the "clock" block linearly increasing?

Answer 1

[MathWorks Support Team]

The Simulink "clock" block is not measuring the real elapsed time, but it outputs the simulation time purely based on the model's sample time. For example, if we have a model with sample time of 1 ms, the clock will always output: [0ms 1ms 2ms...]. On the other hand, the "elapsed time" block actually measures execution time by polling the real-time operating system's (SLRT kernel) internal clock. The results it returns are as accurate as the real-time kernel's timer interrupt. The real-time operating system does not run on a perfect clock, so 1 second of simulation is not exactly 1 second in the real world, but it is close enough to be considered a real-time operating system. Because of this, synchronizing both models with your current workflow might result in a small margin of error.

Something you could do instead to synchronize your external sensor measurements with your data in Simulink is the following:

You could implement some logic, such that there is a signal which is 0 if the sensor reading flag that you are getting from your data collection system is LOW and 1 if the sensor reading flag is HIGH. You can log this signal and then analyze this logged signal off-line which would tell you exactly when (in Simulink time) the sensor data started to record and when it stopped. Using this information, you could synchronize your sensor data with the data in Simulink.