Creating Simulink dataset with timetable for importing in simulink signal editor

I am creating a Simulink dataset with the variables as timetable programatically.

I am reading excel sheet in which i have steps, based on those steps and the time specified i am creating a timetable variable with time and data format.

Based on the discussion at https://in.mathworks.com/matlabcentral/answers/1842758-matlab-double-addition-format-long, i understand the issue in the understanding of floating point and how actually they are used.

But i have a problem due to this, my timetable needs to have the time which needs to be absolute data. Like 0.1, 0.3, 4 , 5 seconds, so that i can import this in signal editor block and then run the simulation.

The step size of my model is 0.1, so while calcuating the timestep to insert in the time table, i am coming across the issue of adding current time(14.1) and the next step time(0.1). It is not exactly taking at 14.2 and because of this the data is not taken in simulink at exactly the 14.2 time step.

Can you please help on how to overcome this situation ? Maybe tell simulink to use same precision as matlab ? because when i view the data with short format it shows the value as 14.2 and i want simulink signal editor to also do the same.

Answer 1

[Eric Sofen]

We're aware of this issue and have been working to reconcile it. The time vectors in Simulink and timetable are constructed in basically the same way, but as you point out, at different precision (seconds versus milliseconds).

One possible workaround relies on the fact that Simulink looks for the nearest timestep that must be less than the Simulink time value. So try subtracting a small amount off the row times of the timetable before passing it into Simulink: tt.Time = tt.Time - seconds(1e-12).

Another step to try, although I acknowledge this is probably even more unsatisfying given that your data is coming from a spreadsheet, is to overwrite tt.Time with a new time vector constructing in milliseconds: e.g. tt.Time = milliseconds(0:100:15000) so that at least there isn't floating point creeping in during the construction of the time vector.