Changing the actions of a descendant of the process component
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".
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.
The control component follows the last command from the Supervisor.
Example 1: Reboot
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.
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.
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”.
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.