Is there a generic pattern for deny/allow type situations for actions?

Through trial and error I've created a motor class for a centrifugal pump that has the concept of a on/off 'required' state and an 'actual' on/off state. The required state is set by the user or a timer.

The actual state can only be set to 'on' if the required state is 'on' and a series of blocking conditions are false. For example, water level is too low, keep alive timeout, level sensor fails sanity check, restart delay timeout, motor has been running for too long, case temperature too high.

The sequence in the main loop is:

  • Gather sensor data.
  • Ascertain that sensors aren't in a fault condition.
  • Count the number of blocking conditions.
  • if no blocking conditions exist, check to see if the required and actual state are in sync, if not switch on/off accordingly.
  • If there are blocking conditions set the actual state to off, but don't change the required state.

Is there a generic or better way?

What you have proposed sounds logical.

Are the sensor conditions and the blocking conditions the same thing?

...R

Robin2:
Are the sensor conditions and the blocking conditions the same thing?

A sensor can either be a fault state meaning that its output cannot be trusted, or it can be in a non-fault state but the value it is reporting is outside the allowable range that will allow the motor to start.

For example I have a level sensor that has a string of float switches at different heights. By definition, if any float switch in the series is detecting water then all the float switches below it should also be detecting water, if not then something is clearly wrong and the level sensor output as a whole cannot be trusted, which would generate a blocking condition.

If the level sensor passes the sanity check and is reporting the water level to be below some threshold, that would generate a 'low water' blocking condition.

OK. That makes sense. I wondered, from your Original Post, if you were checking the same thing twice but it seems not.

...R

I’d add error states (values) to the actual state, so that you can find out easily whether the pump is in the desired or an error state. A “blocked” field would be fine, with every blocking condition mapped to a distinct bit. This field woud be nonzero in case of any blocking condition.