Changing the actions of a descendant of the process component

Introduction

You can change the actions of your control component to fit with the overall design of your control system. It is done through the instance constants "Control_@_power_up" and "Operator_error_confirmation".

You can change the constants at the component instance level, and you can’t alter them run-time.

Control_@_power_up

Your first option is Control_mode. It is an enum with 5 options.

Control_mode

No change
This is the default setting and it shows that a control component keeps its current control mode after a reset.

For example, if the component was in manual mode before a power cut, it will be in manual mode after the power comes back.

To auto, To manual, To manual feedback, To disabled:
Your component will start-up into the control mode you choose after a reset.

In Man or Man FB modes

This constant applies to the control modes – manual and manual feedback – as the name states. It decides whether the component should reuse the supervisor data after a power cycle.

Use previous data
This is the default setting. The control component starts up with invalid Supervisor data, and hence it awaits a command from its supervisor.

Invalidate data
The control component follows the last command from the Supervisor.

Examples

Example 1: Reboot

You want to be able to get your system back to an automatic state on power-up to get rid of any control mode changes a user has made earlier.

How to
Control_@_power_up.Control_mode = To_auto
Control_@_power_up.In_Man_or_ManFB_modes = Invalidate_data

Example 2: Keep field modules running while you wait for service

Control system characteristics
First, you know that your sensor(s) can break down.

Second, you don’t have easy access to replace equipment.

Third, you know that your system shuts down every night.

Desired behavior
When a sensor breaks down, your program should no longer use the actual readings from the sensor.

So you should now use the view to put your sensor into manual feedback. After, you can set the sensor to a sensible value.

Until you can send a technician to replace the broken sensor, the system should remember the manual override and the value. Even after the system shuts down.

How to
Control_@_power_up.Control_mode = No_change
Control_@_power_up.In_Man_or_ManFB_modes = Use_previous_data

Example 3: Ensure that your control component can only be in “auto”

First, you have written a main control component that you inherited from the process component.

Second, you want to use the supervisor-servant functionality.

Third, you want to use the standard views for the process component.

Last, you don’t want users to be able to change the control mode away from auto, because it is designed to always be in “auto”.

 

How to
Override the set-method of the control-mode and delete “INHERITED”.

Control_@_power_up.Control_mode = To_auto
Control_@_power_up.In_Man_or_ManFB_modes = Invalidate_data

Operator_error_confirmation

The second option is Operator_error_confirmation. It is an array of 3 Yes_no_def’s. It means that all of the options can be either yes, no, or Invalid.

By default, the operator doesn’t need to do anything when he or she fix the error.

If you want the operator to do something, you can use this structure to decide the specific action(s).

When the process powers up, you can set the confirmation after power-up to yes. Then, the operator should confirm that he has seen it.  

If you want the operator to acknowledge an error, set wait for acknowledge to yes.

In the case that the operator should restart the current process when there is an error, you can choose wait for restart.

In all of the cases, you can see a symbol on the view until the operator has done the correct action.