[Example] Creating a counter hold and reset functionality (Block diagram approach)

In one of my previous posts, I've written about how to implement a counter in Simulink. While this is a neat features, a counter is rarely a standalone feature.

Maybe we need to count the number of km a vehicle has traveled, or just the time the vehicle was in motion. While the vehicle is stationary, we should stop the count. Maybe if we engage the reverse gear, a new count must be triggered. Since we engage reverse while stationary, chances are that the counter was already held before, so we need to reset it while in a held state.

In this post, I am going these features in a Simulink block diagram. 

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

Basically, while a signal is true, the counter will no longer increase. I am also going to implement a reset, that will restart the count based on the rising edge of a signal. Furthermore, in order to increase the complexity, the reset will also override an existing hold (even if the hold is set to True, the reset is going to ignore it and just start the counter all over again).

4) Solution

Let's start by implementing the hold functionality. This one's very easy, we just need a switch that lets us chose between adding the simulation step or 0, while our control signal is true.

The reset works in a similar fashion. We just need to add a rising edge detection to our control signal and implement a second switch instead of the unit delay, so that both the increment and the current value get set to 0 when our reset signal is sent.

The question is: how to implement both? We can see that the diagrams are relatively similar. We could implement a logical OR between the reset and hold signal acting on the upper switch, right? Well, not really. If both the hold and reset would be active, the reset would set our counter to 0, but it wouldn't start rising until the hold signal would fall. We need a different approach.

The hold has two states. If it rises, we are sure it is set to True, whereas if it falls, we are sure it is set to False. No intermediate states exist, so we don't really need the signal itself to control our switch. Therefore, we are going to SET the hold when on its rising edge and RESET the hold on its falling edge or on a rising edge of the reset signal. We will do this using a flip-flop. All this will act on the upper switch. But this upper switch also needs to select 0 when we reset our signal, so the output of the flip-flop will be passed through a logical OR block, along with the reset. It might sound a bit complicated, but it really isn't, once you see the figure below.

In this example, I've tested a standalone reset, a reset that overrides a hold and a standalone hold, in order to ensure that all the functionalities have been validated. 

- The first reset takes place at 2s. 

- At 4, the counter is frozen due to the hold signal. Even though the hold is kept up to 8s, it is not fully taken into consideration as a new reset signal is sent at 7s. 

- A final hold command is requested between 15 and 16s.

NOTE: to simplify the diagram, I've used some subsystems for the rising edge and falling edge functionalities. The content of the subsystems is exactly what's been presented in the previous tutorials on these features.