EPICS Record Reference Manual
LANSCE Division Automation and Controls Group (LANSCE-8)
Los Alamos National Laboratory
This chapter covers the general functionality that is found in all database records. The topics covered are I/O scanning, I/O address specification, data conversions, alarms, database monitoring, and continuous control:
PHASE
mechanism. For event scanning, the user can control the priority at
which a record will process. In addition to the scan and the phase
mechanisms, there are data links and forward processing links that can
be used to cause processing in other records. This section explains
these concepts.
10 second
5 second
2 second
1 second
.5 second
.2 second
.1 second
For a record to scan periodically, a valid choice must be entered in its
SCAN
field. Actually, the available choices depend on the
configuration of the menuScan.dbd
file. As with most other
fields which consists of a menu of choices, the choices available for
the SCAN field can be changed by editing the appropriate .dbd
(database definition) file. dbd
files are ASCII files that
are used to generate header files that are, in turn, are used to
compile the database code. Many dbd
files can be used to
configure other things besides the choices of menu fields.
Here is an example of a menuScan.dbd
file, which has the
default menu choices for all periods listed above as well as choices for
event scanning, passive scanning, and I/O interrupt scanning:
menu(menuScan) { choice(menuScanPassive,"Passive") choice(menuScanEvent,"Event") choice(menuScanI_O_Intr,"I/O Intr") choice(menuScan10_second,"10 second") choice(menuScan5_second,"5 second") choice(menuScan2_second,"2 second") choice(menuScan1_second,"1 second") choice(menuScan_5_second,".5 second") choice(menuScan_2_second,".2 second") choice(menuScan_1_second,".1 second") }It's not recommended that any of the above choices be deleted. To add more scan periods, such as one for 20 seconds, follow the above format. For example, to add a choice for 0.019 seconds, add the following line after the 0.1 second choice:
choice(menuScan_019_second, " .019 second")The range of values for scan periods can be from one clock tick, 0.015 seconds (60 Hz clock), to the maximum number of ticks available on the system. Note, however, that the order of the choices is essential. The first three choices must appear in the above order. Then the remaining choices should follow in descending order, the biggest time period first and the smallest last.
LOW
, MEDIUM
,
or HIGH
. A low priority event has a priority a little
higher than Channel Access. A medium priority event has a priority about
equal to the median of periodic scanning tasks. A high priority event
has a priority equal to the event scanning task.I/O Intr
.post_event()
database access routine. Two records,
the event record and the timer record, are also used to post events. For
example, there is the timing output, generated when the process is in a
state where a control can be safely changed. Timing outputs are
controlled through Timer records, which have the ability to generate
interrupts. Consider a case where the timer record is scanned on I/O
interrupt and the timer record's event field (EVNT) contains an event
number. When the record is scanned, the user-defined event will be
posted. When the event is posted, all records will be processed whose
SCAN field specifies event and whose event number is the same as the
generated event. User-defined events can also be generated through
software. Event numbers are configurable and should be controlled
through the project engineer. They only need to be unique per IOC
because they only trigger processing for records in the same IOC.
All records that use the user-defined event mechanism must specify Event
in their SCAN field and an event number in their EVNT field.
Passive
. In case 1, an operator might change the
value of a record field using the operator interface, after which the
record would process and perform any operations on the data. In case 2,
an analog input might retrieve its input from another record. In order
for the analog input to retrieve current data, the other record must
process its data before the analog input retrieves the data from it. If
the other record is a passive record, the analog input record will cause
it to process. In case 2, the link field, the INP field in the analog
input record for example, must specify process passive (PP
).
Thus, two conditions must be true in case 2:
Passive
in its SCAN
field.
PP
or process passive.
NPP
.
All input links, on the other hand, have the process passive
attribute which can be PP
(process passive True) or NPP
(no process passive, False). For input links such as INP or DOL
(desired output location), if they specify PP
, they will
cause the record whose address they contain to process when the records
containing them are processed (When we say a record is specified in the
link, we mean an address to a field in that record. When no field is
specified in any link, by default the value field VAL
is
accessed. See Section 2, Address
Specification for more information on how to specify links
between records.). This means that the value will be retrieved from the
specified record only after the record has processed its data.For example, Figure 1 presents a Capfast schematic of two records, Record_1 and Record_2. Record_1 is an analog output record. Most output records have a DOL or Desired Output Link, from which they can retrieve the value that they output. Thus, the DOL link is an input link which can be process passive. The blue line connecting the records is a data link. In this case it means that the DOL link is connected to the VAL field of Record_2. In other words, Record_1 retrieves its value, the value that it outputs, from Record_2. When Record_1 begins processing, it will first retrieve the value from the field connected to DOL, which, in this case, is the VAL field of Record_2. If DOL is process passive, it will cause Record_1 to be processed when the value is retrieved. Record_2 will then process. After Record_1 finishes processing, the value from its VAL field will be retrieved by DOL. Record_1 will then finish its processing.
If NPP is specified as an input link's attribute, the value is retrieved as is from the other record without causing the other record to process. So in the above example, if DOL didn't specify process passive, record 1 would not cause record 2 to process.
Let's consider a few more examples of passive scanning.
Consider a case where an analog output is controlled only by the operator. There is no reason to process this record until the operator changes the desired output. (This is done by writing to the VAL field.) If this record is passive, the database access routine that places the new desired output into the record will cause it to be processed immediately.
A more complex use of passive scanning causes passive records to inherit the scan traits of the records to which they are connected. Let's look at the simple case (Figure 2) where two analog input records (AI) get their input from the VAL field of a calculation record (CALC). Each analog input has a forward link (FLNK) to the calculation record. In Capfast, FLNKs connect to the SLNK field of another record. However, this is just a way to specify the record. In EPICS, there are no SLNK records; a FLNK merely contains the name of another record.
The calculation record's SCAN field specifies Passive
, the
SCAN field of the first analog input record specifies 2 second
,
and the SCAN field of the second analog input specifies I/O Intr
.
In this example the calculation will be processed every two seconds and
whenever the I/O card interrupts. Thus, the calculation inherits the
periodic scanning trait of the first analog input record and the I/O
event scanning trait of the second. Each time the calc record is
processed, it will retrieve values from the locations specified in its
input links and perform its calculation.
Next, let's look at a continuous control loop (Figure 3). In this case the analog input, which is scanned every 0.1 seconds, has a forward link to the calculation record, and the calculation record, in turn, has a forward link to the analog output. Every 0.1 seconds the analog input will process, converting its value and causing the calc record to process. The calc record will make its calculation, causing the analog output record to process. The analog output will then write its output after fetching, if necessary, its desired output. If the operator changes a value in the calculation, this will also cause the calc record to perform its calculation and the analog output to write its output, since the calc and the analog output record are passive.
Let's consider a case (Figure 4)
where values are fetched from other records via input links. When a
record fetches a value from another record, the other record is first
processed, only if the other record is passive and only if the link
specifies process passive or PP
. As an example, suppose a
calculation record has two input links, each of which specifies an
analog input record and each of which specifies process passive (PP
).
Suppose also that the calculation record specifies 1 second
in its SCAN field, meaning that it is scanned every second. Every
second, the calc record will cause each analog input to process before
fetching the values, provided that each analog input specifies Passive
in its SCAN field.
In a variation of this example (Figure 5),
suppose one of the analog inputs specifies 2 second
in its
SCAN field which means it would no longer be a passive record. Thus,
the periodically scanned analog input will not be processed
every time the calculation is processed. Its current value will simply
be fetched as is; then the other analog input will be processed and the
calculation performed. The same thing would occur if the calculation's
INPB link specified NPP or no process passive. In this case, even if the
analog input's SCAN field specified Passive
, the value
would be fetched as is without causing the analog input to process.
Channel Access links, be they between records located in different IOCs or between records located in the same IOC, cannot be process passive, e.g., they cannot cause the record they specify to process when written to or read from.
To illustrate this we will look at an example from the previous section,
with the records, however, being scanned periodically instead of
passively (Figure 6). In this example
each of these records specifies .1 second
; thus, the
records are synchronous. The phase sequence is used to assure that the
analog input is processed first, meaning that it fetches its value from
the specified location and places it in the VAL field (after any
conversions). Next, the calc record will be processed, retrieving its
value from the analog input and performing its calculation. Lastly, the
analog output will be processed, retrieving its desired output value
from the calc record's VAL field (the VAL field contains the result of
the calc record's calculations) and writing that value to the location
specified it its OUT link. In order for this to occur, the PHAS field of
the analog input record must specify 0, the PHAS field of the
calculation record must specify 1, and the analog output's PHAS field
must specify 2.
It is important to understand that in the above example, no record causes another to be processed. The phase mechanism instead causes each to process in sequence.
We discussed forward links in the section on passive processing (Chapter 1, 1.3). To reiterate, this field causes the record that it specifies to be scanned when the record that contains the forward link is scanned. It is thus used to cause related records to process. (For more on specifying records in link fields, see Address Specification, Chapter 1, 2).
If a forward link references the PROC field of a record in another IOC, a Channel Access " put" request is directed to the specified record, causing it to process.
One record type exists solely to propagate forward processing: the fanout record. The fanout record is used when there is more than one record which needs to be processed as a result of another record being processed. It can specify as many as six forward links. Let's look at an example where an analog input's value is used in two different calculations (Figure 7). Because there is only one forward processing link in the analog input record, it is used to process the fanout record. Here two of the fanout records forward links are used to link to two calculation records. In the example, when the I/O interrupt occurs, the analog input is processed, then the fanout record is processed, causing each of the calculation records to be processed. Note that the fanout record simply causes the specified records to process. It does not send values to other records. The data fanout record, on the other hand, does send values to other records. Refer to Chapter 13, Fanout, and Chapter 11, dfanout, for more information on the fanout and data fanout records.
There are three basic types of address specifications which can appear in these fields: hardware addresses, database addresses, and constants.
Note: Not all links support all three types, though some do. However, this doesn't hold true for algorithmic records, which cannot specify hardware addresses. Algorithm records are records like the Calculation, PID, and Select records. These records are used to process values retrieved from other records. Consult the documentation for each record consult. |
<RecordName>.<FieldName>where
RecordName
is simply the name of the record being
referenced and FieldName
is the name of the field within
the record.The record name and field name specification are case sensitive. The record name entered in Capfast (or whatever other configuration tool) can be a mix of upper and lower case letters. The field name is always upper case. If no field name is specified as part of an address, the value field (VAL) of the record is assumed. Forward processing links do not need to include the field name because no value is returned when a forward processing link is used; therefore, a forward processing link need only specify a record name.
For inputs and desired output links, the specified record is processed before the value has been read, and for output links the specified record is processed after the value has been written. In the case of the forward processing link, the record being referenced is processed after the record making the link is processed.
Remember that input links such as INP and DOL (desired output location),
can specify process passive (PP
) or no process passive (NPP
).
When a record's input link specifies a database address, the record
specified by the address will process only if the input link specifies
process passive and only if the addressed record specifies Passive
in its SCAN field. If the input link specifies no process passive
(NPP), the addressed record will not be processed even if it is a
passive record. Because output links such as OUT are always process
passive, they always cause the specified record to be processed,
provided that the specified record's SCAN field is configured as Passive
.
Basic typecast conversions are made automatically when a value is retrieved from another record--integers are converted to floating point numbers and floating point numbers are converted to integers. For example, a calculation record which uses the value field of a binary input will get a floating point 1 or 0 to use in the calculation, because a calculation record's value fields are floating point numbers. If the value of the calculation record is used as the desired output of a multi-bit binary output, the floating point result is converted to an integer, because multi-bit binary outputs use integers.
Be aware that other types of conversions may not be made when a value is
retrieved from another record. Whether it does or doesn't depends on
the record and the device support routine which the record specifies.
Most records must specify a device support routine in their DTYP field.
Device support routines take care of the specifics of input and output.
For such records, there are device support routines for hardware I/O,
and other routines for I/O between records. For example, the analog
input has many device support routines for input from hardware, and two
routines specific for retrieving input from other records: Soft
Channel
and Raw Soft Channel
. Raw Soft Channel
retrieves the input value and performs the specified linear conversions
on the value (that is, if the record is configured to perform linear
conversions). The Soft Channel
device support routine, on
the other hand, reads the value directly into the VAL field and doesn't
perform any linear conversions on the value.
Records that use soft device support routines or have no hardware device support routines are called soft records. See the chapter on each record for information about that record's device support.
Note: Link fields can reference
records in a different database, that is, a database that resides in a
different IOC. Records residing on different IOCs connect through
channel access, so any link that refers to a record in another IOC is
called a channel access link. The format of a channel access link does
not differ from that of a regular database link. Channel access links are created when the database is initialized. When the initialization routines cannot find the link in the local database, a channel access link is created. |
As of Release 3.13.0, input and output links can also be forced to be Channel Access links, even when they are located in the same IOC. Input links can specify either CA, CP, or CPP. Specifying CA forces the input link to be a Channel Access link. When an input link becomes a Channel Access link, a Channel Access monitor is established on the field and a buffer is allocated for the field using the field type and the element count of the field. In addition to the value of the input link, the alarm status of the link is monitored. Specifying CP or CPP also forces the input link to be a Channel Access link, but in addition, CP or CPP will force the record that contains the link to be processed when a monitor occurs, that is, if the record is process passive.
Output links can also specify CA, in which case they will be forced to be Channel Access links. When an output link becomes a Channel Access link, a buffer is allocated the first time a "put" operation occurs on the record containing the link. Each time a "put" occurs for the record, the data is retrieved from the buffer. And the buffer is updated. The CP and CPP options are not available for output links.
Forward links can also be Channel Access links, either when they specify a record located in another IOC or when they specify the CA attributes. However, forward links will only be made Channel Access links if they specify the PROC field of another record.
Because of the nature of Channel Access links, they cannot be process passive. For example, if an input link that specifies another record in another IOC but also specifies PP, the PP attribute will be ignored. Another aspect of Channel Access links is that they are never placed in the same lock set as the records they link to.
When nothing is specified in a link field, it is a NULL link. Before Release 3.13, the value fields associated with the NULL link were initialized with the value of zero. As of Release 3.13, the value fields associated with the links are not initialized
A constant may also be used in the desired output location or DOL field
of an output record. In such a case, the initial desired output value
(VAL) will be that constant. Any specified conversions are performed on
the value before it is written as long as the device support module
supports conversions (the Soft Channel
device support
routine does not perform conversions). The desired output value can be
changed by an operator at run-time by writing to the value field.
A constant can be used in an output link field, but no output will be written if this is the case. Be aware that this is not considered an error by the database checking utilities.
The following sections discuss these types of conversions. The actual field names appear in capital letters.
On
,
the zero state. The level being low drives the device on, so that a
broken cable will drive the device to a safe state. In this example the
database parameters are entered as follows:
A more complex example involving discrete values is one that has many states such as a multi-bit binary output record. Consider a motor which has four states--off, low, medium, and high. A device of this type may have three control lines and three more monitor lines. Each line represents one of the on states (low, medium, or high). The bit pattern for each control state is entered into the database with the string that describes that state. The database parameters for the monitor would be entered as follows:
0100
(4), the three value is
the corresponding value, and the device would be set to state 3 which
drives the device to its high level. The value can be displayed as an
integer, in which case the value would be 3, or as a string, in which
case the value would be 'High'.
If the bit pattern is not found, the device is in an unknown state. For
instance, if the three monitor bits read equal 0111
(7) and
there are no equivalent values, then the value is set to -1, the
condition of the record is set to UNKNOWN alarm, and the alarm severity
is set to whatever alarm severity is configured for the unknown state
(see Alarm Specification, Chapter 1, 4).
In addition, the DOL fields of binary output records (bo and mbbo) will
accept values in strings. When they retrieve the string or when the
value field is given a string via put_enum_strs
, a match is
sought with one of the states. If a match is found, the value for that
state is written.
eng. units = (new eng units * (1 - smoothing) + (prev. eng units * smoothing))
The analog conversions from raw values to engineering units can be either linear or breakpoint conversions.
Whether an analog record performs linear conversions, breakpoint conversions, or no conversions at all depends on how the record's LINR field is configured. The possible choices for the LINR field are as follows:
The engineering units full scale and low scale are specified in the EGUF and EGUL fields, respectively. The values of the EGUF and EGUL fields correspond to the maximum and minimum values of the transducer, respectively. Thus, the value of these fields is device dependent. For example, if the transducer has a range of -10 to +10 volts, then the EGUF field should be 10 and the EGUL field should be -10.
In the following examples the determination of engineering units full scale and low scale is shown. The conversion to engineering units is also shown to familiarize the reader with the signal conversions from signal source to database engineering units.
Note: The engineering units field (EGU) in an analog record has nothing to do with the conversions. The EGU field simply contains a string that should describe the engineering units used by the record, such as PSI for an analog input that reads values from a device that transmits pressure. Thus, the EGU field is meant for the operator's sake. |
The transducer transmits pressure: 0 PSI at 0 Volts and 175 PSI at 10 Volts. The engineering units full scale and low scale are determined as follows:
eng. units full scale = 17.5 X 10.0 eng. units low scale = 17.5 X 0.0The field entries in an analog input record to convert this pressure will be as follows:
When the pressure is 175 PSI, 10 Volts is sent to the I/O module. At 10 Volts the signal is read as 4095. When this is plugged into the conversion, the value is 175 PSI.
In this example the transducer is producing 0 Volts at 0 PSI and 5 Volts at 175 PSI. The engineering units full scale and low scale are determined as follows:
eng. units low scale = 35 X 10 eng. units full scale = 35 X 0The field entries in an analog record to convert this pressure will be as follows:
Notice that at full scale the transducer will generate 5 Volts to represent 175 PSI. This is only half of what the input card accepts; input is 2048. Let's plug in the numbers to see the result:
(2048 / 4095) * (350 - 0) + 0 = 175In this example we had to adjust the engineering units full scale to compensate for the difference between the transmitter and the analog input card.
In this example the transducer is producing 0 Volts at 0 PSI and 10 Volts at 175 PSI. The input module has a different range of voltages and the engineering units full scale and low scale are determined as follows:
eng. units full scale = 17.5 X 10 eng. units low scale = 17.5 X (-10)The database entries to convert this pressure will be as follows:
Notice that at low scale the transducer will generate 0 Volts to represent 0 PSI. Because this is half of what the input card accepts, it is input as 2048. Let's plug in the numbers to see the result:
(2048 / 4095) * (175 - -175) - 175 = 0In this example we had to adjust the engineering units low scale to compensate for the difference between the unipolar transmitter and the bipolar analog input card.
At 0 PSI the transducer transmits 0 Volts. This is amplified to 0 Volts. At half scale, it is read as 2048. At 175 PSI, full scale, the transducer transmits 2 Volts, which is amplified to 4 Volts. The analog input card sees 4 Volts as 70 percent of range or 2867 counts. The engineering units full scale and low scale are determined as follows:
eng units full scale = 43.75 * 10 eng units low scale = 43.75 * (-10)(175 / 4 = 43.75) The record's field entries to convert this pressure will be as follows:
Notice that at low scale the transducer will generate 0 Volts to represent 0 PSI. Because this is half of what the input card accepts, it is input as 2048. Let's plug in the numbers to see the result:
(2048 / 4095) * (437.5 - -437.5) - 437.5 = 0Notice that at full scale the transducer will generate 2 volts which represents 175 PSI. The amplifier will change the 2 Volts to 4 Volts. 4 Volts is 14/20 or 70 percent of the I/O card's scale. The input from the I/O card is therefore 2866 (i.e., 0.7 * 4095). Let's plug in the numbers to see the result:
(2866 / 4095) * (437.5 - -437.5) - 437.5 = 175 PSIWe had to adjust the engineering units full scale to adjust for the difference between the transducer with the amplifier affects and the range of the I/O card. We also adjusted the low scale to compensate for the difference between the unipolar transmitter/amplifier and the bipolar analog input card.
The transducer is transmitting temperature. The database entries in the analog input record that are needed to convert this temperature will be as follows:
final value = eng. units + (raw value - beginning point) X slopeThere are currently lookup tables for the J and K thermocouples in degrees F and degrees C.
Other applications for a lookup table are the remainder of the thermocouples, logarithmic output controllers, and exponential transducers. We have chosen the piece-wise linearization of the signals to perform the conversion, as they provide a mechanism for conversion that minimizes the amount of floating point arithmetic required to convert non-linear signals. Additional breakpoint tables can be added to the existing breakpoints.
There are two ways to create a new breakpoint table:
(1) Simply type in the beginning point for each segment and the corresponding engineering units at that point in the following format.
breaktable(<tablename>) { <beginning point> <eng units> ibid. }where the <
tablename
> is the name of the table, such
as typeKdegC, and <beginningpoint
> is the value of
the beginning point for each line segment, and <eng units
>
is the corresponding engineering units. The slope is calculated by the
software and should not be specified.(2) Create a file consisting of a table of an arbitrary number of values in engineering units and use the utility called makeBpt to convert the table into a breakpoint table. As an example, the contents data file to create the typeJdegC breakpoint table look like this:
!header "typeJdegC" 0 0 700 4095 .5 -210 760 1 !data -8.096 -8.076 -8.057 many more numbersThe file must have the extension
.data
. The file must first
have a header specifying these nine things:
typeJdegC.data
,
and can be converted to a breakpoint table with the makeBpt
utility as follows:
%makeBpt TypeJdegC.data
For limit alarms and state alarms, the severity can be configured by the user to be MAJOR or MINOR for the a specified state. For instance, an analog record can be configured to trigger a MAJOR alarm when its value exceeds 175.0. In addition to the MAJOR and MINOR severities, the user can choose the NO_ALARM severity, in which case no alarm is generated for that state.
For the other alarm types (i.e., scan, read/write), the severity is always INVALID and not configurable by the user. An INVALID alarm
There are two limits at each end--two low values and two high values--so that a warning can be set off before the value goes into a dangerous condition.
Analog records also contain a hysteresis field, which is also used when determining limit violations. The hysteresis field is the deadband around the alarm limits. The deadband keeps a signal that is hovering at the limit from generating too many alarms. Let's take an example (Figure 8) where the range is -100 to 100 volts, the high alarm limit is 30 Volts, and the hysteresis is 10 Volts. If the value is normal and approaches the HIGH alarm limit, an alarm is generated when the value reaches 30 Volts. This will only go to normal if the value drops below the limit by more than the hysteresis. For instance, if the value changes from 30 to 28 this record will remain in HIGH alarm. Only when the value drops to 20 will this record return to normal state.
Discrete records also have a field in which the user can specify the severity of an unknown state to NO_ALARM, MINOR or MAJOR. Thus, the unknown state alarm is not automatic.
Discrete records also have a field which can specify an alarm when the record's state changes. Thus, an operator can know when the record's alarm state has changed. If this field specifies NO_ALARM, then a change of state will not trigger a change of state alarm. However, if it specifies either MINOR or MAJOR, a change of state will trigger an alarm with the corresponding severity.
In addition, the get_alarm_double()
routine can be called
to format an alarm message and send it to an alarm handler. The alarm
conditions may be monitored by the operator interface by explicitly
monitoring the STAT and SEVR fields. All values monitored by the
operator interface are returned from the database access with current
status information.
To implement the deadbands, each record that has deadbands for the value field or fields (not all records have deadbands for value fields) will have fields that contain the value for the monitored field from the last time the record was processed. For instance, an analog output has the ALST and MLST fields. The first implements the deadband for the archivers; the second, for all other monitors on the value field. Each time the record is processed, the last value is compared to the current value, and if the change is greater than the deadband, monitors for the field are sent.
if ((current value - last value) > deadband) send monitorsOf course, the formula is a little bit more complicated in order to deal with negative numbers and other subtleties, but the basic idea is the same.
closed_loop or supervisory
. When the closed loop
mode is chosen, the desired output is retrieved from the location
specified by the DOL field and placed into the VAL field. When the
supervisory mode is chosen, the desired output value is simply taken
from VAL and is not retrieved from DOL. In the supervisory mode, VAL can
be changed externally via the database access routines.The DOL field, like most other link fields, can be a link or a constant. When a constant, the VAL field is initialized to its value. Thus, if the desired output of the record is to be controlled externally by the operator, the DOL field can be given a value with which the VAL field will be initialized.
When an output record is set to closed loop mode, new desired outputs can be retrieved from algorithm records so that the output required can achieve a desired affect. Using this capability, closed control loops can be implemented. A closed control loop usually consists of an input record which retrieves a value from a process variable, an algorithm record which retrieves its value from the input record and manipulates the data in some way, and then an output record which retrieves the changed value from the algorithm record and sends out to a controller that will determine the input. This section will look at an example of closed loop control.
For a closed control loop, closed_loop
should be chosen in
the analog output's OMSL field, in which case the desired output is
retrieved from the DOL field which should specify the DM field of the
PID record. The PID record determines the difference between the desired
value and the current process value gotten from the analog input, and
also determines how the output should change to get the process value to
the desired value. The result of the PID calculation is an output
delta. The analog output needs to be configured to accept incremental
changes when tied to a PID that calculates change only. This can be done
in the OIF field, which has two choices: Full
or Incremental
.
The analog output record, like most output records, can be taken out of
the closed control loop by changing closed_loop
to supervisory
in its OMSL field, which is accessible and modifiable at run-time.
Doing this, of course, suspends the closed control loop until the OMSL
field is set back to supervisory
,
Figure 9
Generated with Harlequin WebMaker