How do I lower the numerical accuracy of Simevents/Simulink simulation time or the time written from a clock block?

In a SimEvents model set to use variable discrete time steps:

I only want to use the time of the simulation to one decimal place. I write the simulation time to entities at certain times and use that time in an attribute function block.

If the time of an event is set to happened every six steps and I am checking if it is at 6, 12, or 18 etc. I use an equality in the function. Most times the time comes in as 6.000000000000000 but on occasion will be 5.999999999999998 and this causes the conditional check to fail.

Currently I just curTime = round(curTime); in the function but is there a way to lower the number of decimal places used to track the time in the model itself? Is there some other aspect of the this I should be aware of?

How might the absolute tolerance, relative tolerance, and time tolerance affect the time written to an entity from a clock block?

I am looking for ways to change this behavior in the model settings and not by using a rounding block or some other function in the attribute function if it is possible.

Thank you.

Answer 1

[Ryan G]

You want to specify the datatype that suits your use case. If you are using a decimal you could potentially choose fixed point (excessive in this case) or utilize an integer. To do this you can utilize data conversion block. However, this will still have to round to convert to an integer.

Since you cannot set the datatype explicitly inside the clock, you can create your own using a couple blocks. You can see how I created a clock to run at 1hz below:

Note that the sample time in the constant and unit delay blocks is 1.

[Justin]

This is how i am currently reading the time into an entity:

I am using a passing entity to trigger the digital clock subsystem so the model can have large discrete time steps. I don't think the delay block would function the same in there and I was looking for a way to more fundamentally change the model parameters that would affect the time step resolution.

Thank you though, that is an interesting technique.

[Ryan G]

I don't think that does what you think it does. You need a trigger port to actually utilize a triggered subsystem.

You can alter the sample time of the digital clock directly or, as I mentioned, set the sample time directly in the constant and delay blocks as I have shown above for the same effect. You can find out more about sample times here.

[Justin]

I does do what I anticipate. It is a simevents atomic subsystem triggered by a simevents event filter which receives a signal from the passing entity. It also works correctly 99.9% of the time giving me 6, 12, 18, etc. but on occasion will slip and give me 29.999..., 35.999..., 41.9999..., then maybe slip back to 48, 54, etc. The problem may not show up until after 20 or 30 thousand time steps and not correct back for another 20 or 30 thousand.

This simplest fix I have used is to round the input inside the embedded function block but I would like the model or simulink itself to be able to monitor/influence the numerical accuracy or account for less decimal places. For most situations 5.999999999999998 is close enough to 6 but a '>' doesn't think so.

[Ryan G]

What that block is doing, assuming you haven't specifically set the sample time of the block, is inheriting the sample time of the 'event filter'. It's not technically triggering, where it activates based on a change in signal to the trigger.

The reason I used the implementation above is that it allows you to define time using an integer without rounding. What I believe is actually happening with your issue it probably the same as this, where the way the time in the clock block is defined does not match the way the simulink time is defined.