FC 123 - Device Driver

Function code 123 interfaces the control system to a field device. It provides control and accepts feedback from its assigned control device. It normally receives a control input from the sequencing logic and sets the control output equal to the control input when the block is in auto. The control output then goes to the associated device.

 

The device driver also accepts up to two feedback inputs from the field that define the actual status of the device. The control output status represents the status of the device, determined from the feedback inputs as good, bad, or waiting. A waiting output is generated when the feedback waiting time has not elapsed after a state change. The device driver generates an exception report indicating output and alarm when:

 

• The device driver output changes or

• The device driver generates an alarm or

• The Tmax for exception reporting is exceeded.

 

Device drivers can be used in batch and continuous control systems to control and observe a device. Any boolean signal can drive a device driver. It also can be operated from a console, or an output can be unconditionally set with interlock logic.

 

 

Outputs:

Blk

Type

Description

N

B

Control output

N+1

R

Control output status:

0.0 = good

1.0 = bad

2.0 = waiting

 

 

Specifications:

Spec

Tune

Default

Type

Range

Description

S1

N

0

I

Note 1

Block address of control input

S2

N

0

I

Note 1

Block address of feedback input 1

S3

N

0

I

Note 1

Block address of feedback input 2

S4

Y

0

I

0 - 101

Control output status override signal

S5

N

1

I

Note 1

Block address of output override permissive

S6

N

0

I

Note 1

Block address of override output

S7

Y

0

I

0 - 11

Feedback status mask output = 0

S8

Y

0

I

0 - 11

Feedback status mask output = 1

S9

Y

0.000

R

Full

Feedback waiting time (secs)

S10

N

0

I

0 - 255

Device driver display type

 

NOTES:

1. Maximum values are: 9,998 for the BRC-100, IMMFP11/12 and 31,998 for the HAC

 

 

123.1    Explanation

 

The device driver, used with the other batch processing blocks, implements batch control. Normally, a sequence generator drives a device driver block by setting S1 to the output block address of the sequence generator block. The device driver may be controlled manually (from the console) or unconditionally set. The states of the output override and permissive specifications indicate whether manual control from the console or remote control using unconditional logic is permitted.

 

Table 123-1 identifies the permitted control modes for various states of the override specifications S4 through S6.

 

                          

 

When the output of the block specified in S5 is one and S6 is zero, manual override from the console is permitted.  Specification S6 unconditionally sets the output of the device driver when S6 is configured to any block address greater than zero. The boolean output of the block referenced by S6 sets the output of the device driver. This feature precludes manual override of the device from the operator console. When S5 equals zero, only automatic control is permitted.  The control output status is dependent on the feedback inputs, feedback waiting time, and the feedback status masks.  Feedback status masks provide signals defining the normal states of the feedback inputs corresponding to the control outputs of zero (S7) and one (S8). If the values of the feedback signals do not match those of the feedback status masks for a given control output, an exception report generates and goes to the console. The exception report contains the value of the control output (zero or one) and an alarm indicator. When an operator command or logic overrides the control output status, the control output status goes to zero. This allows sequence logic to proceed normally. However, alarms still generate, exception report, and display on the console.

 

For example, when the device driver controlling an on/off valve generates an alarm, the sequence monitor block executes a fault step (e.g., shutdown). If the operator determines that the valve is working correctly, but the position feedback is not correct for some reason, the fault status can be overridden from the console by tuning the ones digit of S4 to a value of one.  This overrides the control status output of the device driver and the sequence monitor block operates as if the device is acting correctly. The block address value specified by S6 determines whether control is set unconditionally or whether the operator has control. An external alarm message will still be transmitted to the console to indicate to the operator that the device is malfunctioning, but the sequence can be restarted or used repeatedly. The console can be used to configure both dynamic graphic displays and faceplate displays that allow access to all of the analog controllers, push button stations and device drivers in the system.

 

 

123.1.1   Specifications

 

S1 - C1

(Block address of control input) A sequence generator block outputs up to eight boolean values for each step in a process. This output is called a mask. It represents the states of eight devices for each step of the process. Each of those eight values can be the control input for a different device driver block. The values are output from the sequence generator block in blocks N through N+7. The device driver block accesses the values if S1 is the block number of the sequence generator output defined for control of the associated device.

 

A block address of zero (default) for S1 configures the function code for Batch language only.

 

S2 - FEED1

(Block address of feedback input 1) Signals from the field that define the actual state of the device. The values of the

feedback inputs are compared with feedback status masks to determine the control output status. If the feedback inputs do

not match the feedback status masks for a given control output, an alarm is generated and the control output status is set to

1.0 (bad).

 

S3 - FEED2

(Block address of feedback input 2) Signals from the field that define the actual state of the device. The values of the feedback inputs are compared with feedback status masks to determine the control output status. If the feedback inputs do not match the feedback status masks for a given control output, an alarm is generated and the control output status is set to 1.0 (bad).

 

S4 - COSOV

(Control output status override) Refer to Table 123-1. When the hundreds digit equals one, the control output status is good as soon as the feedbacks match the feedback status mask.

 

                                               

NOTE: Early recognition of feedback cancels the feedback waiting time (S16) once feedback conditions have been met. This can result in bad status and alarm prior to feedback waiting time time-out.

 

S5 - OOPER

(Block address of output override permissive) When the output override permissive input value is a logic 1, the device driver control output can be controlled by a console (manual mode) or by external logic (remote mode) referenced by S6. When the output override permissive input is a logic 0, the device driver control output is controlled by the control input (automatic mode) referenced by S1. Refer to Tables 123-1 and 123-2 for more information.

 

S6 - OVOLIT

(Block address of override input) Determines whether the override state selected is manual or remote.

S6 = 0 and <S5> = 1,               permitted control mode is auto or manual.

S6 not equal 0 and <S5> = 1,  permitted control mode is remote.

 

S7 - FDMSK0

(Feedback status mask output for control output of zero) The value found in this block defines the normal state of the

feedback inputs corresponding to a control output of zero. If control output is a zero and the feedback inputs to the device

driver do not agree with S7, an exception report with alarm is generated. The ones digit is feedback input one and the tens

digit is feedback input two.

S8 - FDMSK1

(Feedback status mask output for control output of 1) Defines the normal state of the feedback inputs corresponding to a control output of one. If control output is a one and the feedback inputs to the device driver do not agree with S8, an exception report with alarm is generated. The ones digit is feedback input one and the tens digit is feedback input two.

S9 - FDWAIT

(Feedback waiting time) Defines the time in seconds that the device driver waits before comparing the feedback inputs with the feedback status masks after a change of state. For example, if the device driver controls a valve, feedback waiting time is the valve stroke time. This insures that measurements taken when the device is changing position or starting up are not used for control or indication.

 

S10 - DISPLAY

(Device driver display type) The console provides the capacity to create dynamic graphic and faceplate displays. This specification defines the display type used to represent this particular device. There is a special faceplate display created especially for the device driver block called the device driver mimic. Refer to the console instruction for display types.

0 = output and feedback indicators

 

 

123.1.2  Outputs

 

N

(Control output) Drives the device associated with the device driver block. The control output is normally the control (auto) input received from a sequence generator block. Control outputs can be overridden by inputs from the console (manual) or unconditionally set to a value with interlock logic (remote). Specifications S4 through S6 define the override state, as shown in Table 123-1.

 

N+1

(Control output status) Output from the device driver to a device monitor block to inform the control system of the current state of the driven device.

0.0 = good

1.0 = bad

2.0 = waiting

 

A good output means that the feedback waiting time has elapsed and the inputs from the field agree with the feedback status masks defined in S7 and S8 as the normal states for a particular control output.

 

A bad output means that the feedback waiting time has elapsed and the inputs from the field do not agree with the feedback status masks for a particular control output.

 

A waiting output means that the feedback waiting time has not elapsed, and no comparisons between inputs from the field and feedback status masks has been made yet.

 

Control output status can be overridden and forced good when S4 equals XX1. If a device driver mimic display is configured in the console, it indicates an override state with OVR in the center of the bottom line of the display.

 

123.2   Applications

 

Device driver blocks can be used in batch and continuous processes to control a piece of equipment from the console or to receive feedback on the state of the equipment. The following example shows a device driver used in a typical batch application. The example illustrates how all the batch function blocks interact in a batch process. These blocks can also be used for sequential control.

 

To be effective, a distributed batch control system should be partitioned for grfroup control of interdependent unit operations.  All interdependent unit operations should be controlled from a single module. Each independent unit operation should be located in a separate controller. This method maximizes system reliability and insures control system integrity.

 

Figure 123-1 shows a simple process requiring batch control capabilities. Reactants drawn from several storage tanks go into two batch chemical reactors. After the batch reaction is complete, the products transfer from the reactors to an intermediate storage tank, process through a liquid/liquid extractor, and then purify in a distillation column. This process is characterized by several interconnected unit operations, all of which must function properly in the proper sequence for the process to operate.

 

 

Figure 123-2 shows typical partitioning of the example batch control system. Separate controllers are provided for each reactor, for reactant distribution, for liquid/liquid extraction, and for distillation. With the partitioning shown, if the control system for one of the batch reactors stops operation, the other reactor operates and the rest of the process continues to operate until immediate storage depletes, allowing time for the replacement of the malfunctioning component. If using a single controller for the entire process, the process would shut down abruptly, perhaps unsafely. It would stay shut down until the malfunction could be diagnosed and corrected.

 

 

Once the control system is effectively partitioned, each batch operation can be defined by identifying the devices used, the steps required for the batch sequence, the recipe parameters used, and the emergency actions required.

 

The basic approach to batch control is to create sequence control logic that generates a unique output state pattern for each step in a sequence. This logic must automatically and continuously verify that all of the devices are operating as directed. In this way, the process divides into a series of easy to construct auxiliary logics linked together through the sequence control logic.

 

To develop batch control logic:

 

1. The devices associated with control of the batch reactor must be identified. These devices include analog measurement sensors, modulating control valves, and discrete devices such as motors and on/off valves. Discrete device status feedback, such as motor starter holding contacts and valve limit switches, should also be considered. The analog and discrete devices associated with the example batch reactor are shown in Figure 123-3.

 

 

2. A written description of the batch sequence must be prepared. This description should divide the sequence into a series of steps and fully describe both the actions taken during each step and the feedback required before the sequence can proceed. Use the following steps for the example batch sequence:

 

 

Step 1

Clean reactor. Open FV4, start M1 and P1, and set TIC-2 set point equal to recipe parameter A. Go to Step 2 when reactor is 80 percent full.

 

Step 2

Empty reactor. Open FV5. When reactor is less than five percent full, start ten minute timer. When timer times out, go to Step 3.

 

Step 3

Feed component A. Close FV5 and open FV1. Set FIC-1 set point equal to recipe parameter B. Integrate flow until the total amount added is greater than the amount indicated by recipe parameter C. Go to Step 4.

 

Step 4

Feed component B. Close FV1 and open FV2. Set TIC-2 set point equal to recipe parameter D. Integrate flow until total amount added is greater than the amount indicated by recipe parameter E. Go to Step 5.

 

Step 5

Feed component C. Close FV2 and open FV3. Integrate flow until total amount added is greater than the amount indicated by recipe parameter F. Go to Step 6.

 

Step 6

Cook reactants. Close FV3. Ramp reactor temperature up to recipe parameter G at a constant rate. When TT-2 is greater than recipe parameter G, go to Step 7.

 

Step 7

Empty reactor. Open FV5. When reactor level is below five percent, start ten minute timer. When timer times out, go to Step 8.

 

Step 8

Cue operator to review and print out batch report. After operator acknowledges that he has done this, go to Step 1.

 

NOTE: The process is not a continuous batch sequence. The process ends at Step 8, and requires operator action to restart the batch sequence.

 

3. The recipe parameters must be defined. These parameters should be selected to allow variations in time, temperature and relative amounts of reactants from recipe to recipe. The example batch reactor has seven recipe parameters:

 

1 - starting reactor temperature

2 - rate of addition of components to reactor (set point of FIC-1)

3 - amount of component A to add to reactor

4 - reactor temperature for the addition of components B and C

5 - amount of component B to add to reactor

6 - amount of component C to add to reactor

7 - reaction temperature

 

4. The actions required upon device failure must be defined. One emergency action may be defined for a device failure in any step, or separate emergency actions may be defined for device failures in each step. For this example, a general fail safe condition exists for response to any device failure

 

 

 

Step 0

E-STOP (executed stop). P1 and M1 are left running, and all valves are set to fail safe position. This step executes when the operator manually initiates an E-STOP, or the controller detects a device failure.

Figures 123-4 through 123-10 show the configuration used to achieve the control. Figure 123-4 shows the logic that controls the discrete devices. Figures 123-5 through 123-10 show the auxiliary logic required to implement each step. Cross referencing between the sequence definition and these figures provides a good indication of the flexibility and options available for implementing batch control.

 

In Figure 123-4, the device drivers control and monitor the discrete control devices used in the example.

 

 

The example batch reactor has five on/off valves, a pump and an agitator. The on/off valves have two limit switches and require a maximum of five seconds for full travel. The states of the limit switches are used as the feedback indicators, and feedback waiting time is five seconds to insure that the valve has finished changing positions before the feedback values confirm valve operation. The pump and agitator motor have only one feedback signal, and require a maximum of two seconds to confirm operation. The feedback waiting time for those devices will be defined as two seconds.

 

NOTE: Output N is Step 0 indicator. Input S1 to BMUX is Step 0 trigger.

 

The device driver has two outputs, a boolean output that drives the field device, and a real output that indicates if the field device is in the correct state based on the input and feedback values. The real output goes to a device monitor block that collects the outputs from all the device driver blocks and outputs a combined status for the process.  All device driver blocks connect to a device monitor block. Each device monitor block monitors the status of up to eight device driver blocks. It is, in effect, a specialized logic OR block. If any input to the device monitor block is bad or waiting, then the output is bad or waiting.

 

The output of the device monitor block is the control output status for the whole process. That value (good, bad or waiting) goes to a sequence monitor block. The sequence monitor block controls step execution. It determines which steps are to be executed and when. It selects the next step to be executed based on the value from the device monitor and a step trigger value. The sequence monitor block can be configured to act on either or both inputs. Each step is defined by three specifications: the next normal step, the next fault step, and a stop type. If the input from the device monitor block is bad (any field device not in proper state), the sequence monitor block will select a fault step (Step 0 in the example) to be executed next. If the input is good, the step chosen depends on the three specifications and the step selection configuration.

 

The number of the next step to be executed and a boolean step trigger are sent from the sequence monitor block to a sequence generator block. Each sequence generator block includes an array of up to eight outputs that can be used to control device driver blocks. The sequence monitor block (in its most commonly used form), with step type 00, initiates execution of the next step when the step trigger is on and the status of all devices for the batch unit is good.

 

The sequence monitor and sequence generator blocks are also used to control and monitor the auxiliary logics that must be executed with each step. In the sample configuration, when the sequence generator block initiates a step, the output mask for that step goes to the device driver blocks, and the step number goes to a real signal demultiplexer block. The real signal demultiplexer block converts the real step number value to a series of boolean outputs which are used to select the auxiliary logic corresponding to the current step. If the real input is a one, then outputs zero and two through seven will be zeros, and output one will be a one. Thus, the auxiliary logic corresponding to Step 1 will be initiated.

 

Figure 123-5 illustrates the auxiliary logic for Step 1. Step 1 includes opening FV4, starting M1 and P1, setting TIC-2 set point equal to recipe parameter A, and going to Step 2 when the reactor is 80 percent full. The output mask controls FV4,

 

M1 and P1; the auxiliary logic controls the set point and reactor level measurements.

 

The step number (one) goes to a real signal multiplexer, which outputs input value number one. Input value number one is a recipe value A, the starting reactor temperature. That value goes through a rate limiter and the rate the temperature ramps up (defined using an adapt block). The output rate then goes to a manual/auto station as the set point, and PID control is performed based on that set point and the current temperature read from a temperature indicator (TT-2).

 

The digital timer block shown at the bottom of Figure 123-5 serves two purposes. When a step requiring a change in reactor temperature executes, the time insures that the controller is in automatic, and it forces the manual/auto station to track the temperature value from the real signal multiplexer block. This drives the current set point to the correct value for each step. The digital timer is configured as a pulse to put the controller into auto and then to go off. This removes a lock in auto condition and allows putting the controller into manual from keyboard.

 

The logic at the top of Figure 123-5 illustrates the step trigger which signals the completion of Step 1. A tank level value goes to a high/low compare block. When the tank level exceeds the high limit (in this case 80 percent) the high alarm output goes to one. This value is ANDed with the Step 1 indicator from the real signal demultiplexer to create a step trigger. When the high alarm output goes to one, the output of the AND block goes to one also. That zero to one transition of the output of the AND block is the step trigger shown in Figure 123-4 signaling the completion of the auxiliary logic for Step 1.

 

The values of all the completion step triggers go to a boolean signal multiplexer block that selects one of ten input signals and provides it as the output. The signal is selected with an input select signal. Figure 123-4 illustrates that the input select signal is the step number output from the sequence generator block (in this example one). Therefore, the value output from the boolean signal multiplexer block is the value of the completion flag for Step 1. The output of the boolean signal multiplexer block is the step trigger input for the sequence monitor block. When that value makes a zero to one transition, the sequence monitor selects the next step in the process. This arrangement insures that the current step runs to completion before the next step is initiated.

 

NOTE: All step logics have the same structure. They are triggered by a step indicator and when the step logic is complete a step trigger generates. All device checking (to insure correct operation) is done automatically via the device drivers through the device monitors by the sequence monitor.

 

Figures 123-6 through 123-10 illustrate the auxiliary logics associated with Steps 2 through 8 in the example process.

 

NOTE: Although not specifically shown in the drawings, all integrators have a default value of block address five for S3. This means the integrators track zero when not active. When active, they start from an initial value of zero.

 

Recipe values A through G are selected from seven real recipe table blocks as shown in Figure 123-10. A remote manual set constant block is used by the operator to select one of ten real values for each recipe value, enabling the operator to fine tune a recipe and create several products with one set of equipment.

 

 

 

 

 

 

 

 

123.3   Distributed Recipe Handling

 

Depending on the memory requirements for the actual batch control configuration, recipes can be stored in the same module as the control configuration, or in another module located either on the same Controlway/module bus or in a different process control unit on the communications highway.

 

This distributed recipe handling capability generally eliminates the requirement for a centralized computer to store batch recipes, and its associated costs, project complications, and operational unreliabilities. Further, recipe storage can be expanded incrementally as the need arises by simply adding another module to the control system.

 

 

123.3.1  Storing Recipe Data

 

A specialized function block has been provided in the module to simplify recipe handling. The real recipe table function block (RECIPR, function code 118) stores up to ten values of one recipe parameter. The output of the RECIPR block corresponds to the parameter value for the recipe number input to the RECIPR block. The RECIPR block can be used to change the value of any variable parameter from recipe to recipe. Further, the RECIPR block can change which steps are used for preparation of a batch, and the order that the steps are executed.

 

RECIPR blocks can be linked together in parallel (each block receives the recipe number as an input), with each block storing up to ten values for each of the recipe parameters. If more than ten values are required for each parameter, the RECIPR blocks can be linked together in series to provide the necessary number of values for each parameter (the second block is slaved to the first, the third is slaved to the second, etc.). Consequently, a batch process requiring eight recipes, each with five parameters, requires five RECIPR blocks to store the recipe data. A batch process requiring 28 recipes each with five parameters, requires 15 RECIPR blocks (two slave blocks connected to each of five master blocks).

 

 

 

123.4    Recipe Handling for a Fixed Batch Sequence

 

In a fixed batch sequence, the order in which the steps are accomplished remains fixed from recipe to recipe, but the amounts of ingredients and the conditions they are added in may vary. The following lube oil blending example illustrates how fixed-sequence recipes can be edited. Table 123-2 shows the contents of a series of recipes.

 

                                            

 

Each of these parameters is stored in a RECIPR block. The recipe is stored in ten RECIPR blocks tied together in parallel.

The module configuration logic required to manipulate and store this recipe is shown in Figure 123-11.

 

NOTES:

  1. Each RECIPR block contains one of the recipe parameters.

  2. REMSET blocks load the new values into the RECIPR function blocks. These blocks show the current value of the recipe parameter before any changes are entered.

  3. The recipe being selected for use is from the REMSET at block address 1000.

  4. The RCM at block address 907 is used to write the new values into the RECIPR blocks through REMSETs at block addresses 908 through 917.

  5. In this configuration, both the REMSET that selects the recipe parameter for editing and RCM that writes the new parameter value to the RECIPR block are interlocked to allow editing of the recipe only during Step 1 of the batch sequence. Without this interlock, the recipe can be edited at any time during the execution of the batch.

  6. After the recipe is edited, it can be downloaded to the RECIPR blocks by triggering the RCM at block address 907 from the console.