[Example] Creating a counter hold and reset functionality (State chart approach)

In my previous post, I've implemented a counter with hold and reset features. Although the block diagram isn't complicated, the implementation can be greatly simplified. Given that these are temporal functionalities, a state chart approach is much more suitable for the implementation

1) Objective:

Create a counter with an embedded hold functionality, as well as a reset. The reset takes priority over the hold (even if the hold is kept at a True state, the counter will be reset and start counting if the reset signal is True).

2) Model configuration: 

Solver -> discrete, fixed simulation step. Step-size -> 0.01s. We will use MATLAB as the action language of our chart.

3) Principle of operation

We can distinguish 3 operations that our counter does, therefore there will be 3 associated states:

a) Incrementation -> this means that we will just add the value of a simulation step every time the computation reiterates.

b) Hold -> during this state, the counter will not increment. The beauty of state charts is that we can just implement an empty state, it is not mandatory to propagate a value through the computation chain at every step (something like adding 0).

c) Reset -> we just need to set the counter to 0. However, this is where it gets a bit tricky, as we might offset our counter by 1dt if we don't set the instructions right.

4) Solution

I would like to start with some notes: for this example, the input hold and reset signals are already processed outside the chart in order to get their rising edges. These impulses will trigger the transition from one state to another. We could just implement the rising edge detection inside the chart, in a parallel state. However, I've already covered how to get the rising edge here.

Let's look at the first attempt at the implementation. Note its simplicity, when compared to the block diagram approach.

The default state will be Calc, which will increase our counter. There are two possible transitions from this state: towards hold or reset. Note how reset has 1 on the transition, meaning that the condition will be evaluated before the hold condition. This will prevent losing 1dt by transitioning to hold in case both signals become active at the same time. Also note that the Reset state could have been avoided altogether, but I kept it for legibility.

This implementation has one issue. If we get a reset at 2s, we use 1dt to enter the Reset state. The counter itself is set to 0 one dt later, meaning that our counter becomes 0 at 2.01s. This is not ideal.

Let's try another approach, by moving the {counter = 0;} instruction inside the Reset state.

This creates a new issue. Right now, if we get a reset request at 2s, the counter will indeed be reset precisely at that timestamp. However, we will lose a dt to transition towards the Calc state, with no action taken. This means that, instead of incrementing at 2.01s, our counter will increment at 2.02s.

There is one fix that we can implement.

By adding an additional incrementation instruction on the transition exiting from the Reset state, we will compensate that 1dt delay until we enter the Calc state. Therefore, our counter will work accordingly.

As a conclusion, I would say that even though there are some factors that we must take into account in order to properly tune our functionality when implementing it in Stateflow, this is still a much better optimized solution than working with block diagrams for this particular feature.