From 8a39ca74891e327f051f091030aa4bcbf7d126ff Mon Sep 17 00:00:00 2001 From: Joao Paulo Martins Date: Tue, 3 Sep 2019 14:20:24 +0200 Subject: [PATCH 01/28] Preparing the waveform record DBD-POD file; Creation of the menuFtype DBD-POD file --- .../db/{menuFtype.dbd => menuFtype.dbd.pod} | 9 + src/std/rec/waveformRecord.dbd.pod | 517 +++++++++++++++++- 2 files changed, 499 insertions(+), 27 deletions(-) rename src/ioc/db/{menuFtype.dbd => menuFtype.dbd.pod} (88%) diff --git a/src/ioc/db/menuFtype.dbd b/src/ioc/db/menuFtype.dbd.pod similarity index 88% rename from src/ioc/db/menuFtype.dbd rename to src/ioc/db/menuFtype.dbd.pod index ff20e0ca4..fd643f625 100644 --- a/src/ioc/db/menuFtype.dbd +++ b/src/ioc/db/menuFtype.dbd.pod @@ -7,6 +7,15 @@ # and higher are distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=head1 Menu menuFtype + +This menu is used for the C field of all record types. + +=menu menuFtype + +=cut + menu(menuFtype) { choice(menuFtypeSTRING,"STRING") choice(menuFtypeCHAR,"CHAR") diff --git a/src/std/rec/waveformRecord.dbd.pod b/src/std/rec/waveformRecord.dbd.pod index db2fa05fb..e40aa2a21 100644 --- a/src/std/rec/waveformRecord.dbd.pod +++ b/src/std/rec/waveformRecord.dbd.pod @@ -1,35 +1,13 @@ -#************************************************************************* -# Copyright (c) 2002 The University of Chicago, as Operator of Argonne -# National Laboratory. -# Copyright (c) 2002 The Regents of the University of California, as -# Operator of Los Alamos National Laboratory. -# EPICS BASE is distributed subject to a Software License Agreement found -# in file LICENSE that is included with this distribution. -#************************************************************************* +=pod =title Waveform Record (waveform) -... - -=head2 Record-specific Menus - -=head3 Menu waveformPOST - -The MPST and APST fields use this menu to determine when to post new value -and archive monitors respectively. - -=menu waveformPOST - -... - -=head2 Parameter Fields - -The record-specific fields are described below. +The waveform record type is used to interface waveform digitizers. The record +stores its data in arrays. The array can contain any of the supported data +types. =recordtype waveform -... - =cut menu(waveformPOST) { @@ -39,7 +17,492 @@ menu(waveformPOST) { recordtype(waveform) { -=fields VAL, FTVL, MPST, APST +=pod + +=head1 Contents + +=over + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=back + +=back + +=begin html + +
+ +=end html + +=head2 Parameter Fields + +The waveform's fields fall into the following categories: + +=over + +=item * L; + +=item * L; + +=item * L; + +=item * L; + +=back + +=head3 Scan Parameters + +The waveform record has the standard fields for specifying under what +circumstances the record will be processed. These fields are listed in L. In addition, L explains how these fields are +used. Note that I/O event scanning is only supported for those card types that +interrupt. + +=head3 Read Parameters + +These fields are configurable by the user to specify how and from where the +record reads its data. How the INP field is configured determines where the +waveform gets its input. It can be a hardware address, a channel access or +database link, or a constant. Only in records that use soft device support can +the INP field be a channel access link, a database link, or a constant. +Otherwise, the INP field must be a hardware address. See L
for information on the format of hardware addresses and database +links. + +=head4 Fields related to waveform reading + +=fields DTYP, INP, NELM, FTVL, RARM + +The DTYP field must contain the name of the appropriate device support module. +The values retrieved from the input link are placed in an array referenced by +VAL. (If the INP link is a constant, elements can be placed in the array via +dbPuts.) NELM specifies the number of elements that the array will hold, while +FTVL specifies the data type of the elements. +The RARM field causes the device to re-arm when this field is set to 1. + +=head4 Possible data types for FTVL + +=begin html + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IndexIdentifierChoice String
0menuFtypeSTRINGSTRING
1menuFtypeCHARCHAR
2menuFtypeUCHARUCHAR
3menuFtypeSHORTSHORT
4menuFtypeUSHORTUSHORT
5menuFtypeLONGLONG
6menuFtypeULONGULONG
7menuFtypeFLOATFLOAT
8menuFtypeDOUBLEDOUBLE
9menuFtypeENUMENUM
+ + +=end html + +=head3 Operator Display Parameters + +These parameters are used to present meaningful data to the operator. They +display the value and other parameters of the waveform either textually or +graphically. + +=head4 Fields related to I + +=fields EGU, HOPR, LOPR, PREC, NAME, DESC + +EGU is a string of up to 16 characters describing the units that the waveform +measures. It is retrieved by the C<<< get_units >>> record support routine. + +The HOPR and LOPR fields set the upper and lower display limits for array +elements referenced by the VAL field. Both the C<<< get_graphic_double >>> and +C<<< get_control_double >>> record support routines retrieve these fields. + +The PREC field determines the floating point precision with which to display the +array values. It is used whenever the C<<< get_precision >>> record support +routine is called. + +See L for more on the record name (NAME) and +description (DESC) fields. + + +=head3 Alarm Parameters + +The waveform record has the alarm parameters common to all record types. L lists other fields related to a alarms that are common to all record +types. + +=head3 Monitor Parameters + +These parameters are used to determine when to send monitors placed on the VAL +field. The APST and MPST fields are a menu with choices "Always" and "On +Change". The default is "Always", thus monitors will normally be sent every time +the record processes. Selecting "On Change" causes a 32-bit hash of the VAL +field buffer to be calculated and compared with the previous hash value every +time the record processes; the monitor will only be sent if the hash is +different, indicating that the buffer has changed. Note that there is a small +chance that two different value buffers might result in the same hash value, so +for critical systems "Always" may be a better choice, even though it re-sends +duplicate data. + +=head4 Record fields related to I + +=fields APST, MPST, HASH + +=head4 Menu choices for C and C fields + +=menu waveformPOST + +=head3 Run-time Parameters + +These parameters are used by the run-time code for processing the waveform. They +are not configured using a configuration tool. Only the VAL field is modifiable +at run-time. + +VAL references the array where the waveform stores its data. The BPTR field +holds the address of the array. + +The NORD field holds a counter of the number of elements that have been read +into the array. It is reset to 0 when the device is rearmed. The BUSY field +indicates if the device is armed but has not yet been digitized. + +=fields VAL, BPTR, NORD, BUSY + +The following fields are used to operate the waveform in the simulation mode. +See L for more information on the simulation mode fields. + +=fields SIOL, SIML, SIMM, SIMS + +=begin html + +
+
+
+ +=end html + +=head2 Record Support + +=head3 Record Support Routines + +=head4 init_record + + static long init_record(waveformRecord *prec, int pass) + +Using NELM and FTVL space for the array is allocated. The array address is +stored in the record. + +This routine initializes SIMM with the value of SIML if SIML type is CONSTANT +link or creates a channel access link if SIML type is PV_LINK. VAL is likewise +initialized if SIOL is CONSTANT or PV_LINK. + +This routine next checks to see that device support is available and a device +support read routine is defined. If either does not exist, an error message is +issued and processing is terminated + +If device support includes C, it is called. + +=head4 process + + static long process(waveformRecord *prec) + +See L section below. + +=head4 cvt_dbaddr + + static long cvt_dbaddr(DBADDR *paddr) + +This is called by dbNameToAddr. It makes the dbAddr structure refer to the +actual buffer holding the result. + +=head4 get_array_info + + static long get_array_info(DBADDR *paddr, long *no_elements, long *offset) + +Obtains values from the array referenced by VAL. + +=head4 put_array_info + + static long put_array_info(DBADDR *paddr, long nNew) + +Writes values into the array referenced by VAL. + +=head4 get_units + + static long get_units(DBADDR *paddr, char *units) + +Retrieves EGU. + +=head4 get_prec + + static long get_precision(DBADDR *paddr, long *precision) + +Retrieves PREC if field is VAL field. Otherwise, calls C<<< recGblGetPrec() >>>. + +=head4 get_graphic_double + + static long get_graphic_double(DBADDR *paddr, struct dbr_grDouble *pgd) + +Sets the upper display and lower display limits for a field. If the field is VAL +the limits are set to HOPR and LOPR, else if the field has upper and lower +limits defined they will be used, else the upper and lower maximum values for +the field type will be used. + +Sets the following values: + + upper_disp_limit = HOPR + lower_disp_limit = LOPR + +=head4 get_control_double + + static long get_control_double(DBADDR *paddr, struct dbr_ctrlDouble *pcd) + +Sets the upper control and the lower control limits for a field. If the field is +VAL the limits are set to HOPR and LOPR, else if the field has upper and lower +limits defined they will be used, else the upper and lower maximum values for +the field type will be used. + +Sets the following values + + upper_ctrl_limit = HOPR + lower_ctrl_limit = LOPR + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +Check to see that the appropriate device support module exists. If it doesn't, +an error message is issued and processing is terminated with the PACT field +still set to TRUE. This ensures that processes will no longer be called for this +record. Thus error storms will not occur. + +=item 2. + +Call device support read routine. + +=item 3. + +If PACT has been changed to TRUE, the device support read routine has started +but has not completed writing the new value. In this case, the processing +routine merely returns, leaving PACT TRUE. + +=item 4. + +Check to see if monitors should be invoked. + +=over + +=item * + +Alarm monitors are invoked if the alarm status or severity has changed. + +=item * + +Archive and value change monitors are invoked if APST or MPST are Always or if +the result of the hash calculation is different. + +=item * + +NSEV and NSTA are reset to 0. + +=back + +=item 5. + +Scan forward link if necessary, set PACT FALSE, and return. + +=back + +=begin html + +
+
+
+ +=end html + +=head2 Device Support + +=head3 Fields Of Interest To Device Support + +Each waveform record must have an associated set of device support routines. The +primary responsibility of the device support routines is to obtain a new array +value whenever read_wf is called. The device support routines are primarily +interested in the following fields: + +=fields PACT, DPVT, NSEV, NSTA, INP, NELM, FTVL, RARM, BPTR, NORD, BUSY + +=head3 Device Support Routines + +Device support consists of the following routines: + +=head4 long report(int level) + +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. + +=head4 long init(int after) + +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. + +=head4 init_record + + init_record(precord) + +This routine is optional. If provided, it is called by the record support +C routine. + +=head4 get_ioint_info + + get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt) + +This routine is called by the ioEventScan system each time the record is added +or deleted from an I/O event scan list. cmd has the value (0,1) if the +record is being (added to, deleted from) an I/O event list. It must be +provided for any device type that can use the ioEvent scanner. + +=head4 read_wf + + read_wf(precord) + +This routine must provide a new input value. It returns the following values: + +=over + +=item * + +0: Success. + +=item * + +Other: Error. + +=back + +=head3 Device Support For Soft Records + +The C<<< Soft Channel >>> device support module is provided to read values from +other records and store them in arrays. If INP is a constant link, then read_wf +does nothing. In this case, the record can be used to hold arrays written via +dbPuts. If INP is a database or channel access link, the new array value is read +from the link. NORD is set. + +This module places a value directly in VAL. + +If the INP link type is constant, then NORD is set to zero. If the INP link type +is PV_LINK, then dbCaAddInlink is called by C. + +read_wf calls recGblGetLinkValue which performs the following steps: + +=over + +=item * + +If the INP link type is CONSTANT recGblGetLinkValue does nothing. + +=item * + +If the INP link type is DB_LINK, then dbGetLink is called to obtain a new input +value. If dbGetLink returns an error, a LINK_ALARM with a severity of +INVALID_ALARM is raised. + +=item * + +If the INP link type is CA_LINK, then dbCaGetLink is called to obtain a new +input value. If dbCaGetLink returns an error, a LINK_ALARM with a severity of +INVALID_ALARM is raised. + +=item * + +NORD is set to the number of values returned and read_wf returns. + +=back =cut From 67583b4bda38190952a9cb3e76ace2a4eb0b40af Mon Sep 17 00:00:00 2001 From: Saeed Haghtalab Date: Wed, 4 Sep 2019 10:58:20 +0200 Subject: [PATCH 02/28] Update compressRecord.dbd.pod based on Wiki + Content update --- src/std/rec/Makefile | 6 + src/std/rec/compressRecord.dbd.pod | 386 +++++++++++++++++++++++++++-- src/std/rec/image/compress-1.jpg | Bin 0 -> 16781 bytes src/std/rec/image/compress-2.gif | Bin 0 -> 4136 bytes 4 files changed, 371 insertions(+), 21 deletions(-) create mode 100644 src/std/rec/image/compress-1.jpg create mode 100644 src/std/rec/image/compress-2.gif diff --git a/src/std/rec/Makefile b/src/std/rec/Makefile index 7515d769c..307662ebb 100644 --- a/src/std/rec/Makefile +++ b/src/std/rec/Makefile @@ -53,3 +53,9 @@ stdRecords_DBD = $(patsubst %,%.dbd,$(stdRecords)) dbRecStd_SRCS += $(patsubst %,%.c,$(stdRecords)) HTMLS += $(patsubst %.dbd.pod,%.html,$(notdir $(wildcard ../rec/*Record.dbd.pod))) + +vpath %.jpg $(USR_VPATH) .. $(SRC_DIRS) ../rec/image +vpath %.gif $(USR_VPATH) .. $(SRC_DIRS) ../rec/image + +HTMLS += compress-1.jpg +HTMLS += compress-2.gif diff --git a/src/std/rec/compressRecord.dbd.pod b/src/std/rec/compressRecord.dbd.pod index a67e12d3c..90cacb77d 100644 --- a/src/std/rec/compressRecord.dbd.pod +++ b/src/std/rec/compressRecord.dbd.pod @@ -7,43 +7,387 @@ # in file LICENSE that is included with this distribution. #************************************************************************* -=title Compress Record (compress) +=title Compression Record (compress) -... +The data compression record is used to collect and compress data from arrays. +When the INP field references a data array field, it immediately compresses the +entire array into an element of an array using one of several algorithms, +overwriting the previous element. If the INP field obtains its value from a +scalar-value field, the compression record will collect a new sample each time +the record is processed and add it to the compressed data array as a circular +buffer. -=head2 Record-specific Menus - -=head3 Menu compressALG - -The ALG field which uses this menu controls the compression algorithm used. - -... - -=menu compressALG - -... - -=head2 Parameter Fields - -The record-specific fields are described below. +The INP link can also specify a constant; however, if this is the case, the +compression algorithms are ignored, and the record support routines merely +return after checking the FLNK field. =recordtype compress -... - =cut menu(compressALG) { choice(compressALG_N_to_1_Low_Value,"N to 1 Low Value") choice(compressALG_N_to_1_High_Value,"N to 1 High Value") choice(compressALG_N_to_1_Average,"N to 1 Average") + choice(compressALG_N_to_1_Median,"N to 1 Median") choice(compressALG_Average,"Average") choice(compressALG_Circular_Buffer,"Circular Buffer") - choice(compressALG_N_to_1_Median,"N to 1 Median") } recordtype(compress) { -=fields VAL +=head2 Contents + +=over + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=back + +=back + +=begin html + +
+
+
+ +=end html + +=head2 Parameter Fields + +=head3 Scanning Parameters + +The compression record has the standard fields for specifying under what +circumstances the record will be processed. These fields are listed in +L. In addition, +L +explains how these fields are used. Since the compression record supports no +direct interfaces to hardware, its SCAN field cannot specify C<<< I/O Intr >>>. + +=head3 Algorithms and Related Parameters + +The user specifies the algorithm to be used in the ALG field. There are six possible +algorithms which can be specified as follows: + +=head4 Menu compressALG + +=menu compressALG + +The following fields determine what channel to read and how to compress the data: + +=fields ALG, INP, NSAM, N, ILIL, IHIL, OFF, RES + +As stated above, the ALG field specifies which algorithm to be performed on the data. + +The INP should be a database or channel access link. Though INP can be a constant, +the data compression algorithms are supported only when INP is a database link. See +L
+for information on specifying links. + + +IHIL and ILIL can be set to provide an initial value filter on the input array. +If ILIL E IHIL, the input elements will be skipped until a value is found +that is in the range of ILIL to IHIL. Note that ILIL and IHIL are used only in +C<<< N to 1 >>> algorithms. + +OFF provides the offset to the current beginning of the array data. +Note that OFF is used only in C<<< N to 1 >>> algorithms. + +The RES field can be accessed at run time to cause the algorithm to reset +itself before the maximum number of samples are reached. + +=head4 Algorithms + +B algorithm keeps a circular buffer of length NSAM. +Each time the record is processed, it gets the data referenced by INP and puts +it into the circular buffer referenced by VAL. The INP can refer to both scalar or +array data and VAL is just a time ordered circular buffer of values obtained +from INP. +Note that N, ILIL, IHIL and OFF are not used in C<<< Circular Buffer >>> algorithm. + +B takes an average of every element of the array obtained from +INP over time; that is, the entire array referenced by INP is retrieved, and for +each element, the new average is calculated and placed in the corresponding +element of the value buffer. The retrieved array is truncated to be of length +NSAM. N successive arrays are averaged and placed in the buffer. Thus, VAL[0] +holds the average of the first element of INP over N samples, VAL[1] holds the +average of the next element of INP over N samples, and so on. The following +shows the equation: + +=begin html + + + +=end html + +B If any of the C<<< N to 1 >>> algorithms are chosen, then VAL is a circular +buffer of NSAM samples. +The actual algorithm depends on whether INP references a scalar or an array. + +If INP refers to a scalar, then N successive time ordered samples of INP are taken. +After the Nth sample is obtained, a new value determined by the algorithm +(Lowest, Highest, or Average), is written to the circular buffer referenced by +VAL. If C<<< Low Value >>> the lowest value of all the samples is written; if +C<<< High Value >>> the highest value is written; and if C<<< Average >>>, the +average of all the samples are written. The C<<< Median >>> setting behaves +like C<<< Average >>> with scalar input data. + +If INP refers to an array, then the following applies: + +=over + +=item C<<< N to 1 Low Value >>> + +Compress N to 1 samples, keeping the lowest value. + +=item C<<< N to 1 High Value >>> + +Compress N to 1 samples, keeping the highest value. + +=item C<<< N to 1 Average >>> + +Compress N to 1 samples, taking the average value. + +=item C<<< N to 1 Median >>> + +Compress N to 1 samples, taking the median value. + +=back + +The compression record keeps NSAM data samples. + +The field N determines the number of elements to compress into each result. + +Thus, if NSAM was 3, and N was also equal to 3, then the algorithms would work +as in the following diagram: + +=begin html + + + +=end html + + +=head3 Operator Display Parameters + +These parameters are used to present meaningful data to the operator. They +display the value and other parameters of the record either textually or +graphically. + +=fields EGU, HOPR, LOPR, PREC, NAME, DESC + +The EGU field should be given a string that describes the value of VAL, but is +used whenever the C<<< get_units >>> record support routine is called. + +The HOPR and LOPR fields only specify the upper and lower display limits for +VAL, HIHI, HIGH, LOLO and LOW fields. + +PREC controls the floating-point precision whenever C<<< get_precision >>> is +called, and the field being referenced is the VAL field (i.e., one of the values +contained in the circular buffer). + +See L +for more on the record name (NAME) and description (DESC) fields. + + +=head3 Alarm Parameters + +The compression record has the alarm parameters common to all record types described in +L. + +=head3 Run-time Parameters + +These parameters are used by the run-time code for processing the data +compression algorithm. They are not configurable by the user, though some are +accessible at run-time. They can represent the current state of the waveform or +of the record whose field is referenced by the INP field. + +=fields NUSE, OUSE, BPTR, SPTR, WPTR, CVB, INPN, INX + +NUSE and OUSE hold the current and previous number of elements stored in VAL. + +BPTR is a pointer that refers to the buffer referenced by VAL. + +SPTR points to an array that is used for array averages. + +WPTR is used by the dbGetlinks routines. + +=begin html + +
+
+
+ +=end html + +=head2 Record Support + +=head3 Record Support Routines (compressRecord.c) + +=head4 init_record + + static long init_record(compressRecord *prec, int pass) + +Space for all necessary arrays is allocated. The addresses are stored in the +appropriate fields in the record. + +=head4 process + + static long process(compressRecord *prec) + +See L + +=head4 special + + static long special(DBADDR *paddr, int after) + +This routine is called when RSET, ALG, or N are set. It performs a reset. + +=head4 cvt_dbaddr + + static long cvt_dbaddr(DBADDR *paddr) + +This is called by dbNameToAddr. It makes the dbAddr structure refer to the +actual buffer holding the result. + +=head4 get_array_info + + static long get_array_info(DBADDR *paddr, long *no_elements, long *offset) + +Obtains values from the circular buffer referenced by VAL. + +=head4 put_array_info + + static long put_array_info(DBADDR *paddr, long nNew) + +Writes values into the circular buffer referenced by VAL. + +=head4 get_units + + static long get_units(DBADDR *paddr, char *units) + +Retrieves EGU. + +=head4 get_precision + + static long get_precision(DBADDR *paddr, long *precision) + +Retrieves PREC. + +=head4 get_graphic_double + + static long get_graphic_double(DBADDR *paddr, struct dbr_grDouble *pgd) + +Sets the upper display and lower display limits for a field. If the field is +VAL, the limits are set to HOPR and LOPR, else if the field has upper and lower +limits defined they will be used, else the upper and lower maximum values for +the field type will be used. + +=head4 get_control_double + + static long get_control_double(DBADDR *paddr, struct dbr_ctrlDouble *pcd) + +Sets the upper control and the lower control limits for a field. If the field is +VAL, the limits are set to HOPR and LOPR, else if the field has upper and lower +limits defined they will be used, else the upper and lower maximum values for +the field type will be used. + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +If INP is not a database link, check monitors and the forward link and return. + +=item 2. + +Get the current data referenced by INP. + +=item 3. + +Perform the appropriate algorithm: + +=over + +=item * + +Average: Read N successive instances of INP and perform an element by element +average. Until N instances have been obtained it just return without checking +monitors or the forward link. When N instances have been obtained complete the +algorithm, store the result in the VAL array, check monitors and the forward +link, and return. + +=item * + +Circular Buffer: Write the values obtained from INP into the VAL array as a +circular buffer, check monitors and the forward link, and return. + +=item * + +N to 1 xxx when INP refers to a scalar: Obtain N successive values from INP and +apply the N to 1 xxx algorithm to these values. Until N values are obtained +monitors and forward links are not triggered. When N successive values have been +obtained, complete the algorithm, check monitors and trigger the forward link, +and return. + +=item * + +N to 1 xxx when INP refers to an array: The ILIL and IHIL are honored if ILIL +E IHIL. The input array is divided into subarrays of length N. The specified +N to 1 xxx compression algorithm is applied to each sub-array and the result +stored in the array referenced by VAL. The monitors and forward link are +checked. + +=back + +=item 4. + +If success, set UDF to FALSE. + +=item 5. + +Check to see if monitors should be invoked: + +=over + +=item * + +Alarm monitors are invoked if the alarm status or severity has changed. + +=item * + +NSEV and NSTA are reset to 0. + +=back + +=item 6. + +Scan forward link if necessary, set PACT FALSE, and return. + +=back =cut diff --git a/src/std/rec/image/compress-1.jpg b/src/std/rec/image/compress-1.jpg new file mode 100644 index 0000000000000000000000000000000000000000..9ce8f4145887e0361016b4cf3c7543d00d83cbc5 GIT binary patch literal 16781 zcmeHt2RvL|yYFT&`Vd{TC?VQJ5+VshB!~zig6PqW(Mt@5(M2Z`LJ}euxPfnNyxLf{tyzYzF^z<);s46N<#?S!sbJ39GT zyI9+h*~7oF1zMM%i2Py;{~gE0FPncM@C$)o2>e3e7Xp8afB|3)*pq*DWY@wqa@rAa z0({7K7qXDq1KCGG@8sm;<8cuRb@P_BwsW_!m$h|wg(9szpmMUOp@5PK(!<&oVecbk zWA6xeQx@N-Z4eiN+bN41%j=xh@wj5|1iu#GWp5Cmd)qbuVSB+&Tm{BNuY|maboFqx z_pug2y1KY|UqmVk|5p1&a{A|Es4z^)%g*8At*aV;lpyDnh5u-apP!$s-&t9AFGr}{ zg$oy;r_VsooRJ}ykn#3+^RY(CxOt2GQNdMvZ(A?8hY#G{P3UKZ);8|GKFY$rzHqyX z4%QCxHg5FBSeZy8b_d>)%+Ty&IV-`jI&yX&kr$fT^izsHwm-)HJkUFfBbR1DRvc zb3j-aS-ClQdAK>axsD5npE%Ah#?QqqEGsM~aY{;BidP7F7Akp0TvAH%XC)M1T3UKK zdUgf|c1b>NKFPm)ks1M3TA+mTI*39Tpk$>0u~Lv)0YS1ajhY<0`x(Cb{9KO-)4(+))IP-vd;v)W=T9U8Z5vw+0J)vY!b}$)y!hD{tbs z)r%E9YvUD0N6*Q{&BH5pQe5JcLsr^cGMHuSwc*``WZQgs#4ggQVi2f}aPnU2#>Fe}Y|KmHPh?p-`mC z3ah_2d`|mNg?Wr{2TQQ8GLyNrus+X4w3Hq*G8Z(L5DbMqS`U^QNY}&$mleJrlX*R# z3Y*bYF?}_CBydSEIzZ!*CwB^$Ug8D){fUSBl{;NIOc2OwTCf=QD6RY@?9i+;?M}C6 zR>yY%NZ@h)vuB|+P6E=I zpY&Ll%bh9PMyC^99x`e$8$b71@{(#nJAX#Ho^xktLNIz<;Y*d&J(OeWAm|0PUnJ zJ%?M9AyB+AM!X$*+_c+s2F-vEAYSsLlciIOh>wr10pr@-(ak1@YUrNm91<|qMs8f@ z{_0FYQW;DD+0JA%?vvJie?z9JF-_Q?psBxM<+IFNmG=IHnR9^oswdo+`@t#pITmyY zfb2)s?nW3&qrka$0~A#X#t>k0d>gK~#pCVRaOn0SlHL9#=h-@E;!Upz+EcX!Qk^GAjdeG1YiZwL}e>A)G1u#Mk0}aWOeKXC)PrD^LhT8yWxmO+>BaF z%80fGr|yVdQ^P`Bbky3dF%cmhwMnt&unAF6wGxZ+<(;z2N16FkSm#mX(Zt*;2}p80 z=mD4LtFr@tO;9_Bs;IMXdI@4AfKEK3BwH_S5_7)GT_p06`O)Ut_^5Whk3bNEI&%02 z33!ROy@Q24D>GZ}B>`?DmE+$nl;StR>t0%o_ClEaKpBADID~-0>P5|2NcL;?=IXH_ z!wu;8TkXSHf)7uBqn$H;jTdhW5DeLltmrA>1uB0K+2q6TY#E*xuSSAdfqOr@fzMvd6bdSyvQT1rL4DTb{mLq zVyWblj89!QXGHVW^L_deGkfQAF~_N0la^!3G+(ltYr7f|{uE0$!}pE9HdL&=6>k@S zK5Tz^Edp^okXe4AohA*K{g6zMxLu&- zFQ}VI0t`RI_VrOui1sTQ>aXjVmg>#wh0NmPW;lBm2Sne{*ge+ab)OI9=lp#I=p4|W4wZjixa0bdm~JP%DE#)X^7?tu487htjKJ641FIpUYkLsui;Y4 z<;@my#uf;cA4EE~?ACK&+oGZi(h-5&SFd&NJ>l2d6F*sx!aqY$1`ok_=#CXU+to~U zYG2smvpbxId9QP=Z`bGuGE^Ul zkDJyOyboik>4U1h7}=6>qg~)poj$t6x@<+idQq7KM9YttKySyCY`Dyy5h zG*=`X&u5%L{1S=5+xj9TPOMd((vQwgY^+~VST>^)0JC#6p=uX~m zp%BupI-f|_j#M%40r#^TN1;IYnz6MHc$Kze4~L|O?cY{l-B{5fi}+!|`v<&x7XgXa zuIOe{uGp)B*kpLQRnXJ&h|X(rsRLoOO|x~+XU?}IFv}hw@w5_D|(RdR)2)Qgu&hs*?pGX;mJf#t&u3)lk;6 z`!}5J?rW64=aFRSN`};f=T!x-IAtzm&ngS^>uF{bynO;QPhe};Wrlp3X6;;;w9qyv z@7-Q5+c7IFkrA@!(>WVyC@?ozG)EN0Gehs!v$`?|sc8caS`oc3iN@vT@rglBlncd} zY-Xo=!FR*ZDly{MTA|CH?rh&gJ4Nqmybb_;y$f&P3+7)r$gh7^fRFxK`#xEn-Qm-W zpPVA-s&w-O2r>@?+};D2mWrmrd}OQ0N-Rbs#)$ooYp z@y`2uF(41d-bJ|JhAjH}L2SLlQQo$8Ha+t2DsDHC{@erMPoLXQCOzst{M<2P`Lz^( z(APa9T7SCo?yCHQF6ZaP*DVIdkBK_hSJ5L>qn#fRudGp2px0sYR3 z_6m)rltz2&p76FFigQkO?7JKDnd8UA8mEas0!p;NuwM{Kxz(l?{HV};9`A2SsLstx~m5n zcytIk;#Uak=bigZRzXYX6zlW26=awO`)ZcfJE}U+;cMj6*=Ag9Ca@D1{JEm8wqBpK- zZm)Z$CWeK`k@pO>Dy(e!u{OGfp|U5R`rj@Q37Y~GuvogeVa+_PS30>STBR+Fys2t0 z7bLhVL@>#8YgXcTwpp46e@udAyPqX^fM8$rKqS`8DD~4DgX~9!HYh%i3w(|PnLC1b zOG`3M%Y)8B4p-1b%^ZkpUY$0PD?Nb(EXCo&i3emmQkFB|yLJ#q`OeM01Ua1gMFVx#h+IdeaaHbp6j4jG107W0}P3e#5kn%af!N#apLBw!;aMPeAk{o4;hwXhiU{V^2z8(7E=)5oE~^SkqfT3~RJSIG z5Lp>X06eDYmiHTR+y)7-<>|%`Pj=PX>_47Jdg6X#_%VS4Z>dB#vpXPfe++SuJmq_0 zuC*YAo9H-jB-Kx5dw+0%vJ5oBeV-0*MXdQw?koM_e#0&3nkxx7p~64{hL2|-(O(1( z&TEi>WTxn&Kut0ikDY-DlYlO5yf+E3zCZ%DwMsYs=kIfvL73s@;wNSecs&AV8TEWE zU0GiBOeo*}Y9a>Tpklfa%!D$mCNs2Nrd3hXwFjZTESRtSR7J`V&k-WWvUJgkA$bi5 zqwN%~zm3nG4lghs}H9Ly7@BhIo}Jkk~{% zg)LQD${n6WcY<22cDA^PVTe(JCkYUy`A7opE|X0*DLZzQCUa}AIZOQAqZhX`k-eGc zB^ue4qWHqsB|uA3tA`e6nh_IfvzHJ~EOix~Be(SjQmrnaPW3qAHac|7W_ic!Ol3X} zl(|ZUDJ|2EWuyl4aYCkN@;5&7_P0k z+>M=_6dUK$7c#uO1Wezg8X!-GGyl=rRG*N3q)h@oAQqvcengEj-XI$i&@-O{$#Zvi z-Cn&QyJ3Il?tS}-T6D}>=ull;n-v#I-yX--LgeoyC`hkWne^MYzc?$3<80wbFq4~h z+}QddH7eEW`h>^^8Ef`O51Aq@TWsb$DpHab7K!^g5Vx`?FmdwO7)2T!ebzhT-PwMI z8pWv)bw4*}ubZNmhI1eBGLP0)ZO?v1@zg9)j5Z2{g(%;uH^zTzBn}7&0%2Fv08I5p@iG&r zWl^=?u9CO?RbesTi_D16QmqQ1Rd*yX@mr~>=G1#Xa5EMLw_WuN2kS2T7hVD*-j^AF zk-o?m!QJ6v%U=i@Twxfmc`YpqmE{&S!o4l+c%z?6DE_L~SWMZP#D|>FK!S|91^1bY z&4asnsrPu(V^L;7JcqsCSFW#2SxxkSZLuW4^dnBNrIz2(z+-DlQ?!Mii`L{FBSgIo z+3};61c(?Xz{=4}Uc(Je2l8dnD0#&5<)*fhgqkRsMVTrM8a;1I(4j2ZD>8`Ddu?^V z_m*N?XJ_mVe2**DlfON@c>0=Xy2cHo`3cC z{Ezn{-pMN4nTcboMuP<`CSw|QkGgYyC~GZI12%*!xb-L4z2-{iu~hKGc^TKx{eo0J ziQRQQYfD3{apOT!tnYrXIDXY<&rjD%H}>+Lrrufp5IzY)kkm8m?z30K9umMdWjQSD zq$HCM8(I72(Q<(`d?LvR_B6n_zg(S<<;Bgs4nAiNRt?I~M#>PupYA?Oz39pZs(m_Crf8U zuc3Y~_$<~k3DeEo^?Vg~Nv-vaHYk1SZV0xF$#5;V9%+Eyc0y!BU5} zO_T2XcDlGd-<*3>Rg&L2q{&IS90So8oG3=SltdjZRRMJz?FwhZF(p1(!WEx4RRhBYV`kZs ztcd)$koNKtE$kTP_7kJ}zQr_TZbiRKK5LjoBc%~vt*vN?TH;g8 z$scKN@Ws0izcgyO&jiWbVSe8Is6ypLINkszV=+F3-)pSrtIbk$o!qZFo+=e-kzA^w zg(*c#0^83{j+sH3Ovb)n>(ge+(^y{=dn`niYNbN_+^{K+>|f;~M#}_2nC7?+&||KA zT@0^A4zDpPYXp$pr8^v3|84>60r#FChFceWx72C9hdWoY{d1{os;59)^x;LvpiD|E z+N(bd72Z+|ojUh;KTMLblJEUA^WgeHLIm&23~%dubYUweqf`s1iWvpayz>MmY-RHl z=YwXZmJ_9B8nnZWak(gnK%EaJ4Ku?ASMJH=>FXq zp$FXO^BXz-Ns#|zIb(N5ZRt4NUg-QwO;em61BwdA6}E$TcBRFNHQ~ju`3>gS3hD3* zO-!fw^-OnHBtR-x-VVI>x$nC3QODP8ush@4yJmoZ+oV)&#FRLZmDnLu^@et2l!dVi zA2P){lh2wfKlmPHE|`uu-QngvR##OILKsi6NTbZkko!AQt6G>;;$>~l`76ocE;ahY z)d9Pi|Iir*6q&wDDnN|6WCm9{a;&|mnPU9>-V7`vvTE#<14)HR;Y}ft4Qwv*Nzrfg zz@vA~4)5Pi*Y;d+S@BYlg-W@H|_9SoN%TDZfYL`RD}c<8-_lv*L~_l zBZB+J;yV_S)O$rD(WCxWo=4Px-v`<7e5AJ?=S7YPPR`so+PgZ%sRKs{wcp7(Md>QL z%jW5;H?`050m?ckKiu$aKOSS|dR+Z!0!_Q#!&kE_m)o~io>wng86m4% zkvoweJJ^)t@-CJ6ewOkGoHkBFw@4yIh+*~QgID8y75rDg9~^~tazBRGY%zqPJkZaOhK5+lGH4OKpRd1;(JK| zcli)T74osvXM>yM^NI=wWtmY9liku5&LE|!keLpLlLe=cEt5eA6TQvi+av@tV zwIp?Z_CSC-i0$yCdIDSPt*x)E+H1|JM+nEis}NC-55x{@;t>TFqf5qI)vObr#8S#c zHSVf5f}9K60N?F@FiU>U9*1S3K;PRET@s+*|Kq{&uj(xm-{@pc@t@IJ8}TVR$POo{ zlpx*(d@IQ}o3t7|W#;cdU043}XfmVQ>x`6hEMQk?7m6_&F}WTED&R-7Dal~jS}hp{ zOMM|sC=G>F3(wORB|9q^7pcy@@Kr{P7v?Y?G56mp?>kXFv?D+0ZVa;@8>ag*ILvpOnf18=wES~6Fh(uGyOdhBX@@puGVyl&xt-|f6Pgl8(TLaCPH+&*F! z2g*vs6ZQ6~rOh5Ot1(r~Xj)FJjye6`30tQ;7EZGbq0!2JEy%a>ITy)bHZc0`DD#sM zcnS{M5e~WF9yVHsU8pSWgaz4}ey9QS--NXtalS(N<581PEOPK%VfXG(QpVb-BAmsm z6H>+_fSLT@9(mDySFbsV*^~vuz&(dT`$u62tEH=|0zp{ES$aHqD8BjXg*i0p;M^x zd@~xl)PM{JCYu!|gD+6W#ve>Y*U9c0F$lL-k2Q^~-!0`E{%m4@ zDeId4V+@Zdr4wb_AAIqj7H;<>p2mB_F}BjC?X@NO5k#uX-J|%wIoe_)Cw1KI9_YqW3F8+x`BQ87Kr;H!(=E`Pa0_zq5 zo18dd7ZW=3Fj-akgFsbo?$U0(K#z-09NC@XP#$_W&YwEAu<;wfLy$cBGq6U{LC_>m z8%^MoZkBk=_b}wl*IJ;%c$^`5+XZqZGH&ksY^x)Hl(#cyk z@7_7w3`W__?OyIKrD3uq+^c;;AQy^5z5!y3GXXeY|I;B6-DL-=B0Jy}B9NMLw8ZAo#!b!*}yu>mmX4 zhaCxTQy%qtLHZYSsL1ZEe!(NQZUGW7ok{{KOKY2hPg!xoD<);*UON%Z>#b6Y$M%n% z2i6%=;LahK7=ai#m%UFpiXN^*AJCRTkMbMl63o%VKLih0%Wn3e=NRls zfF+Jxzi^1mZ=sLB9OV47@BU(N^gsNL;tM{hDFvV2I!5!#7lmud(;cRBE)Nq+j;Fkn z1#EXDe|4Ju-5o?4{TE^RBvAkW literal 0 HcmV?d00001 diff --git a/src/std/rec/image/compress-2.gif b/src/std/rec/image/compress-2.gif new file mode 100644 index 0000000000000000000000000000000000000000..e4cbf62a7f500e418fe548c9785fa24831703ac6 GIT binary patch literal 4136 zcmeH``9BkmqjSBh8Vk z8k?(JIlt237$H|k=KJ{k5#L`vkMHvzcs-u4$Kz=Uu`n?7__lBVzF85Gy}dn=|L4Ex zfxSK9f051qxr*}kfqfz(6cMfeEd8em5ecD)zT`=8WnLRrLRQ0-SDF7l@tBGg6#Qvse)UKZX6_so*k9>8Q0g{5@YAuzVziTH z&C!O`IlpqQ?c%)p(sF1eqp9>n<=6MP(RV$aTY=v?UZ_~QT^p(T(M7y6>`Kk9nfaJ! zmZarsuw-A(bSQh+(@?uGTkC@WI)|dlwzEc>9Q-B+>NA!qOu~HViycikBt-N@EoPC!EDx5te@V^LPc?jom0~8tXC)Y%D#_2V){(rC zY$XR_Wt|g^JezgRew&$d|AOFLu0|~IY!1|D)HCaX7^EoOo524{Hf-3=rvl#@7Lsl= z@d`2FL3mY~QWXDO-q|)2UVQ87sfcv;_WsQI#K$?9iy z`x4Zh0cwuQFYmYODlcm}>%UO+$+SK%reg-^K`=P*p}l1P+Xc+QS9d0L}uFBc-ztIh!2SN7ol`_~BCqHyR;* zF^C>&Q=uFEPq)hRkX5dk^!hp((TkcAtpNn}p-+E&vI$QsL-$-tmELKaage&aHG9}! zdjnj3@yhQZQARl(shy_vhHFRgU+xw-W>=dRY{uhb4wf@^V>Yh;*;u|i*vSz6I;?e| zx&*_KnIdY{o!>9@3*)dlMKu^XFQRRURXN}xt_uEF!s1T+^|2iCt*xto1bo7ivmUR5 ziN<1jT^QkT|L4PS0LcCLN=#el8EJULb)nJ<)+~@IEepQB_h5zapqnYT>%av?tt34< z!UB9`eYi|sN%pnzjE=i6BP->l5mXL7iO}i552mLeyIH3;c^#&IR?=c#OZzVIJOdA(#S~7~cX?!Oie*d+e;sSF}suWh%4l*xB| zIS+S!e$%k=GI+ND8fpL8CufZoQOiHMVCC3kzoCNMEwdCw-H%(U)h$p?g4Hrdnoh*4 z7ejcCZiEqzu3i=G=}#EY_zj=_x;nW>%NrE%5AP79`f$p37b`{Q!WZGSMe4#Nuh&L0 zLo?>DU!ntpYzF|Nt2u8T{?i2y>l$nSmc!w|lS43+J40f;%gu|R&|;JV3nX6|Z(b4Z zY3(L(l=q^i_&YU~P5dCs*B7BHZqm9Y)ufSv$(pzOtn5G>Zo`KIS72f@(>j#MCdAcwA?c{6m!!*3B}{3B zGVN-w`@B{qn)b?O@!G817m`Y(9h|y5;d4!zoQIiQrkiEV?c0OW1H`)TN}6~iHq`fD z>O&Mr2F_Uq6!e|(Lzw;pI$`@gYmg%Mge`s4*U{5($Q;coz9Q;x^xk>sjrK;NeAB!O zg4``r688A=*`EV4e38>I8DRv2FWv z1gbfiF6C3u=pRtx5~)A;?|US0bTNXZTq z{Wk2ge^=ts8*+xqAs%d znp?5b*nE(11?pp%X^nb3Xl8Q5Fb(cyuN8H*5w*dDn~dR`kq1uIW6@e$IintPKi zPnS(%5{<{FzUOYAY|(4WXM|L0wzL=q3G>y3EJTKr;tCEFJ%4$5<*!l8dz@4KqM6+j zg6iqtGc)0wn!TY53rL}|SVOO7MWoP$&TjKYif%<|OdEE$yVJ}glHBMOTVeGVb;Eh#m@@2W>mWX-zJ78`cQ2tr)uksT5G z#oR?%EO7!BJrsewq>p;WLj?UBEd=5e2w(t?XeHYbmokS-;NfbW;u*6*1QC+!i<^|Q zqSV1iBN(Oup#T|vy3Wh3Bf)($ycidI9!F62MXPVc-|GlhQ44$dAX=53#CZ@`Bazf- z5cP_OYMCRH_$I;h6S%x2zFKULTGD%7a_wC5fJ90MIK?k9<$)7nVkBj9D`g6h`pqEq z2ivYsEqPc1+xFl|JubD1i2cZpJ$4_X?VG%2;P*=+$XG3ch6L>TVy4xg>vQsZYJU5- zQx4*7#G&BBqbZV*7e`CL$Dsu2QTc!PFXGvEWl0f02viAwUl9mVE&-^FV&whgRn^l^ z``M`T!RJfxnubCf5I=ozJwwqT^DHoP6Y$~>(N+%+zD~mZE5IAo$C?2#29OMM^+anR z7!nDw+y>t*K{}AE?n_!ak)ol7Ko^L$8!2k2>b3{ad$27N5}xSkm;-}Y>@&=HY>0S* z&-pQz+;2tlsUmna7&ewQFdY-imnAtp(Z@ajZ^ zj@&vml9+&q_92<$NQX*DX%JHM4-!M2jP=XO7GzRKbIbUsylrBs9~pIvd~B5L?oH85 zq=XhyEVz`>-{f1+%xXhQGsKdMmuL(zrpO0nmVEa`bx9ibTg|BfQ z5on}7bqsHPtRqobKkOlZ&hn$_eMSj#DaSf!mN>*t1ohl+x^o1LL8K0!gY9dlf7_&N zl8~)F?!W8kqVu$7-4OLzMyq&^Zjn4HHg6VB{Vth54GsAv8FrkE7n1Tn;PSgR-UC`bVD&^y;x3_Efb?a4I-0Fplm_|J9&(a JQaC1J{J)wmzxn_G literal 0 HcmV?d00001 From 128d2a93c8bbadc5df148c8c1284923daa2fa9a7 Mon Sep 17 00:00:00 2001 From: Joao Paulo Martins Date: Wed, 4 Sep 2019 17:25:28 +0200 Subject: [PATCH 03/28] Fixing waveform record documentation after review --- src/ioc/db/menuFtype.dbd.pod | 2 +- src/std/rec/waveformRecord.dbd.pod | 70 +++++------------------------- 2 files changed, 12 insertions(+), 60 deletions(-) diff --git a/src/ioc/db/menuFtype.dbd.pod b/src/ioc/db/menuFtype.dbd.pod index fd643f625..6b783dfec 100644 --- a/src/ioc/db/menuFtype.dbd.pod +++ b/src/ioc/db/menuFtype.dbd.pod @@ -10,7 +10,7 @@ =head1 Menu menuFtype -This menu is used for the C field of all record types. +This menu is used for the C and similar fields of many record types. =menu menuFtype diff --git a/src/std/rec/waveformRecord.dbd.pod b/src/std/rec/waveformRecord.dbd.pod index e40aa2a21..ca48e4792 100644 --- a/src/std/rec/waveformRecord.dbd.pod +++ b/src/std/rec/waveformRecord.dbd.pod @@ -1,4 +1,11 @@ -=pod +#************************************************************************* +# Copyright (c) 2002 The University of Chicago, as Operator of Argonne +# National Laboratory. +# Copyright (c) 2002 The Regents of the University of California, as +# Operator of Los Alamos National Laboratory. +# EPICS BASE is distributed subject to a Software License Agreement found +# in file LICENSE that is included with this distribution. +#************************************************************************* =title Waveform Record (waveform) @@ -10,6 +17,8 @@ types. =cut +include "menuFtype.dbd" + menu(waveformPOST) { choice(waveformPOST_Always,"Always") choice(waveformPOST_OnChange,"On Change") @@ -115,64 +124,7 @@ The RARM field causes the device to re-arm when this field is set to 1. =head4 Possible data types for FTVL -=begin html - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IndexIdentifierChoice String
0menuFtypeSTRINGSTRING
1menuFtypeCHARCHAR
2menuFtypeUCHARUCHAR
3menuFtypeSHORTSHORT
4menuFtypeUSHORTUSHORT
5menuFtypeLONGLONG
6menuFtypeULONGULONG
7menuFtypeFLOATFLOAT
8menuFtypeDOUBLEDOUBLE
9menuFtypeENUMENUM
- - -=end html +=menu menuFtype =head3 Operator Display Parameters From 31811e53b33f944ef5fbba52c3b0a5c6d81f721f Mon Sep 17 00:00:00 2001 From: Saeed Haghtalab Date: Wed, 4 Sep 2019 21:14:11 +0200 Subject: [PATCH 04/28] Compress record pod update after review - Revert "N to 1 Median" choice entry place - Convert images to PNG and update Makefile - Update record support routins definition based on epics7 recSup.h --- src/std/rec/Makefile | 8 +++----- src/std/rec/compressRecord.dbd.pod | 28 +++++++++++++++------------- src/std/rec/image/compress-1.jpg | Bin 16781 -> 0 bytes src/std/rec/image/compress-1.png | Bin 0 -> 2126 bytes src/std/rec/image/compress-2.gif | Bin 4136 -> 0 bytes src/std/rec/image/compress-2.png | Bin 0 -> 7608 bytes 6 files changed, 18 insertions(+), 18 deletions(-) delete mode 100644 src/std/rec/image/compress-1.jpg create mode 100644 src/std/rec/image/compress-1.png delete mode 100644 src/std/rec/image/compress-2.gif create mode 100644 src/std/rec/image/compress-2.png diff --git a/src/std/rec/Makefile b/src/std/rec/Makefile index 307662ebb..3f9c763b5 100644 --- a/src/std/rec/Makefile +++ b/src/std/rec/Makefile @@ -54,8 +54,6 @@ dbRecStd_SRCS += $(patsubst %,%.c,$(stdRecords)) HTMLS += $(patsubst %.dbd.pod,%.html,$(notdir $(wildcard ../rec/*Record.dbd.pod))) -vpath %.jpg $(USR_VPATH) .. $(SRC_DIRS) ../rec/image -vpath %.gif $(USR_VPATH) .. $(SRC_DIRS) ../rec/image - -HTMLS += compress-1.jpg -HTMLS += compress-2.gif +vpath %.png $(SRC_DIRS) +HTMLS += image/compress-1.png +HTMLS += image/compress-2.png diff --git a/src/std/rec/compressRecord.dbd.pod b/src/std/rec/compressRecord.dbd.pod index 90cacb77d..f0a586baa 100644 --- a/src/std/rec/compressRecord.dbd.pod +++ b/src/std/rec/compressRecord.dbd.pod @@ -29,9 +29,9 @@ menu(compressALG) { choice(compressALG_N_to_1_Low_Value,"N to 1 Low Value") choice(compressALG_N_to_1_High_Value,"N to 1 High Value") choice(compressALG_N_to_1_Average,"N to 1 Average") - choice(compressALG_N_to_1_Median,"N to 1 Median") choice(compressALG_Average,"Average") choice(compressALG_Circular_Buffer,"Circular Buffer") + choice(compressALG_N_to_1_Median,"N to 1 Median") } recordtype(compress) { @@ -134,9 +134,11 @@ holds the average of the first element of INP over N samples, VAL[1] holds the average of the next element of INP over N samples, and so on. The following shows the equation: +=for comment Latex form of equation bellow : VAL[i] \leftarrow \frac{1}{N}\sum_{n=1}^NINP_{n}[i] + =begin html - + =end html @@ -183,7 +185,7 @@ as in the following diagram: =begin html - + =end html @@ -246,57 +248,57 @@ WPTR is used by the dbGetlinks routines. =head4 init_record - static long init_record(compressRecord *prec, int pass) + long (*init_record)(struct dbCommon *precord, int pass) Space for all necessary arrays is allocated. The addresses are stored in the appropriate fields in the record. =head4 process - static long process(compressRecord *prec) + long (*process)(struct dbCommon *precord) See L =head4 special - static long special(DBADDR *paddr, int after) + long (*special)(struct dbAddr *paddr, int after) This routine is called when RSET, ALG, or N are set. It performs a reset. =head4 cvt_dbaddr - static long cvt_dbaddr(DBADDR *paddr) + long (*cvt_dbaddr)(struct dbAddr *paddr) This is called by dbNameToAddr. It makes the dbAddr structure refer to the actual buffer holding the result. =head4 get_array_info - static long get_array_info(DBADDR *paddr, long *no_elements, long *offset) + long (*get_array_info)(struct dbAddr *paddr, long *no_elements, long *offset) Obtains values from the circular buffer referenced by VAL. =head4 put_array_info - static long put_array_info(DBADDR *paddr, long nNew) + long (*put_array_info)(struct dbAddr *paddr, long nNew); Writes values into the circular buffer referenced by VAL. =head4 get_units - static long get_units(DBADDR *paddr, char *units) + long (*get_units)(struct dbAddr *paddr, char *units); Retrieves EGU. =head4 get_precision - static long get_precision(DBADDR *paddr, long *precision) + long (*get_precision)(const struct dbAddr *paddr, long *precision); Retrieves PREC. =head4 get_graphic_double - static long get_graphic_double(DBADDR *paddr, struct dbr_grDouble *pgd) + long (*get_graphic_double)(struct dbAddr *paddr, struct dbr_grDouble *p); Sets the upper display and lower display limits for a field. If the field is VAL, the limits are set to HOPR and LOPR, else if the field has upper and lower @@ -305,7 +307,7 @@ the field type will be used. =head4 get_control_double - static long get_control_double(DBADDR *paddr, struct dbr_ctrlDouble *pcd) + long (*get_control_double)(struct dbAddr *paddr, struct dbr_ctrlDouble *p); Sets the upper control and the lower control limits for a field. If the field is VAL, the limits are set to HOPR and LOPR, else if the field has upper and lower diff --git a/src/std/rec/image/compress-1.jpg b/src/std/rec/image/compress-1.jpg deleted file mode 100644 index 9ce8f4145887e0361016b4cf3c7543d00d83cbc5..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 16781 zcmeHt2RvL|yYFT&`Vd{TC?VQJ5+VshB!~zig6PqW(Mt@5(M2Z`LJ}euxPfnNyxLf{tyzYzF^z<);s46N<#?S!sbJ39GT zyI9+h*~7oF1zMM%i2Py;{~gE0FPncM@C$)o2>e3e7Xp8afB|3)*pq*DWY@wqa@rAa z0({7K7qXDq1KCGG@8sm;<8cuRb@P_BwsW_!m$h|wg(9szpmMUOp@5PK(!<&oVecbk zWA6xeQx@N-Z4eiN+bN41%j=xh@wj5|1iu#GWp5Cmd)qbuVSB+&Tm{BNuY|maboFqx z_pug2y1KY|UqmVk|5p1&a{A|Es4z^)%g*8At*aV;lpyDnh5u-apP!$s-&t9AFGr}{ zg$oy;r_VsooRJ}ykn#3+^RY(CxOt2GQNdMvZ(A?8hY#G{P3UKZ);8|GKFY$rzHqyX z4%QCxHg5FBSeZy8b_d>)%+Ty&IV-`jI&yX&kr$fT^izsHwm-)HJkUFfBbR1DRvc zb3j-aS-ClQdAK>axsD5npE%Ah#?QqqEGsM~aY{;BidP7F7Akp0TvAH%XC)M1T3UKK zdUgf|c1b>NKFPm)ks1M3TA+mTI*39Tpk$>0u~Lv)0YS1ajhY<0`x(Cb{9KO-)4(+))IP-vd;v)W=T9U8Z5vw+0J)vY!b}$)y!hD{tbs z)r%E9YvUD0N6*Q{&BH5pQe5JcLsr^cGMHuSwc*``WZQgs#4ggQVi2f}aPnU2#>Fe}Y|KmHPh?p-`mC z3ah_2d`|mNg?Wr{2TQQ8GLyNrus+X4w3Hq*G8Z(L5DbMqS`U^QNY}&$mleJrlX*R# z3Y*bYF?}_CBydSEIzZ!*CwB^$Ug8D){fUSBl{;NIOc2OwTCf=QD6RY@?9i+;?M}C6 zR>yY%NZ@h)vuB|+P6E=I zpY&Ll%bh9PMyC^99x`e$8$b71@{(#nJAX#Ho^xktLNIz<;Y*d&J(OeWAm|0PUnJ zJ%?M9AyB+AM!X$*+_c+s2F-vEAYSsLlciIOh>wr10pr@-(ak1@YUrNm91<|qMs8f@ z{_0FYQW;DD+0JA%?vvJie?z9JF-_Q?psBxM<+IFNmG=IHnR9^oswdo+`@t#pITmyY zfb2)s?nW3&qrka$0~A#X#t>k0d>gK~#pCVRaOn0SlHL9#=h-@E;!Upz+EcX!Qk^GAjdeG1YiZwL}e>A)G1u#Mk0}aWOeKXC)PrD^LhT8yWxmO+>BaF z%80fGr|yVdQ^P`Bbky3dF%cmhwMnt&unAF6wGxZ+<(;z2N16FkSm#mX(Zt*;2}p80 z=mD4LtFr@tO;9_Bs;IMXdI@4AfKEK3BwH_S5_7)GT_p06`O)Ut_^5Whk3bNEI&%02 z33!ROy@Q24D>GZ}B>`?DmE+$nl;StR>t0%o_ClEaKpBADID~-0>P5|2NcL;?=IXH_ z!wu;8TkXSHf)7uBqn$H;jTdhW5DeLltmrA>1uB0K+2q6TY#E*xuSSAdfqOr@fzMvd6bdSyvQT1rL4DTb{mLq zVyWblj89!QXGHVW^L_deGkfQAF~_N0la^!3G+(ltYr7f|{uE0$!}pE9HdL&=6>k@S zK5Tz^Edp^okXe4AohA*K{g6zMxLu&- zFQ}VI0t`RI_VrOui1sTQ>aXjVmg>#wh0NmPW;lBm2Sne{*ge+ab)OI9=lp#I=p4|W4wZjixa0bdm~JP%DE#)X^7?tu487htjKJ641FIpUYkLsui;Y4 z<;@my#uf;cA4EE~?ACK&+oGZi(h-5&SFd&NJ>l2d6F*sx!aqY$1`ok_=#CXU+to~U zYG2smvpbxId9QP=Z`bGuGE^Ul zkDJyOyboik>4U1h7}=6>qg~)poj$t6x@<+idQq7KM9YttKySyCY`Dyy5h zG*=`X&u5%L{1S=5+xj9TPOMd((vQwgY^+~VST>^)0JC#6p=uX~m zp%BupI-f|_j#M%40r#^TN1;IYnz6MHc$Kze4~L|O?cY{l-B{5fi}+!|`v<&x7XgXa zuIOe{uGp)B*kpLQRnXJ&h|X(rsRLoOO|x~+XU?}IFv}hw@w5_D|(RdR)2)Qgu&hs*?pGX;mJf#t&u3)lk;6 z`!}5J?rW64=aFRSN`};f=T!x-IAtzm&ngS^>uF{bynO;QPhe};Wrlp3X6;;;w9qyv z@7-Q5+c7IFkrA@!(>WVyC@?ozG)EN0Gehs!v$`?|sc8caS`oc3iN@vT@rglBlncd} zY-Xo=!FR*ZDly{MTA|CH?rh&gJ4Nqmybb_;y$f&P3+7)r$gh7^fRFxK`#xEn-Qm-W zpPVA-s&w-O2r>@?+};D2mWrmrd}OQ0N-Rbs#)$ooYp z@y`2uF(41d-bJ|JhAjH}L2SLlQQo$8Ha+t2DsDHC{@erMPoLXQCOzst{M<2P`Lz^( z(APa9T7SCo?yCHQF6ZaP*DVIdkBK_hSJ5L>qn#fRudGp2px0sYR3 z_6m)rltz2&p76FFigQkO?7JKDnd8UA8mEas0!p;NuwM{Kxz(l?{HV};9`A2SsLstx~m5n zcytIk;#Uak=bigZRzXYX6zlW26=awO`)ZcfJE}U+;cMj6*=Ag9Ca@D1{JEm8wqBpK- zZm)Z$CWeK`k@pO>Dy(e!u{OGfp|U5R`rj@Q37Y~GuvogeVa+_PS30>STBR+Fys2t0 z7bLhVL@>#8YgXcTwpp46e@udAyPqX^fM8$rKqS`8DD~4DgX~9!HYh%i3w(|PnLC1b zOG`3M%Y)8B4p-1b%^ZkpUY$0PD?Nb(EXCo&i3emmQkFB|yLJ#q`OeM01Ua1gMFVx#h+IdeaaHbp6j4jG107W0}P3e#5kn%af!N#apLBw!;aMPeAk{o4;hwXhiU{V^2z8(7E=)5oE~^SkqfT3~RJSIG z5Lp>X06eDYmiHTR+y)7-<>|%`Pj=PX>_47Jdg6X#_%VS4Z>dB#vpXPfe++SuJmq_0 zuC*YAo9H-jB-Kx5dw+0%vJ5oBeV-0*MXdQw?koM_e#0&3nkxx7p~64{hL2|-(O(1( z&TEi>WTxn&Kut0ikDY-DlYlO5yf+E3zCZ%DwMsYs=kIfvL73s@;wNSecs&AV8TEWE zU0GiBOeo*}Y9a>Tpklfa%!D$mCNs2Nrd3hXwFjZTESRtSR7J`V&k-WWvUJgkA$bi5 zqwN%~zm3nG4lghs}H9Ly7@BhIo}Jkk~{% zg)LQD${n6WcY<22cDA^PVTe(JCkYUy`A7opE|X0*DLZzQCUa}AIZOQAqZhX`k-eGc zB^ue4qWHqsB|uA3tA`e6nh_IfvzHJ~EOix~Be(SjQmrnaPW3qAHac|7W_ic!Ol3X} zl(|ZUDJ|2EWuyl4aYCkN@;5&7_P0k z+>M=_6dUK$7c#uO1Wezg8X!-GGyl=rRG*N3q)h@oAQqvcengEj-XI$i&@-O{$#Zvi z-Cn&QyJ3Il?tS}-T6D}>=ull;n-v#I-yX--LgeoyC`hkWne^MYzc?$3<80wbFq4~h z+}QddH7eEW`h>^^8Ef`O51Aq@TWsb$DpHab7K!^g5Vx`?FmdwO7)2T!ebzhT-PwMI z8pWv)bw4*}ubZNmhI1eBGLP0)ZO?v1@zg9)j5Z2{g(%;uH^zTzBn}7&0%2Fv08I5p@iG&r zWl^=?u9CO?RbesTi_D16QmqQ1Rd*yX@mr~>=G1#Xa5EMLw_WuN2kS2T7hVD*-j^AF zk-o?m!QJ6v%U=i@Twxfmc`YpqmE{&S!o4l+c%z?6DE_L~SWMZP#D|>FK!S|91^1bY z&4asnsrPu(V^L;7JcqsCSFW#2SxxkSZLuW4^dnBNrIz2(z+-DlQ?!Mii`L{FBSgIo z+3};61c(?Xz{=4}Uc(Je2l8dnD0#&5<)*fhgqkRsMVTrM8a;1I(4j2ZD>8`Ddu?^V z_m*N?XJ_mVe2**DlfON@c>0=Xy2cHo`3cC z{Ezn{-pMN4nTcboMuP<`CSw|QkGgYyC~GZI12%*!xb-L4z2-{iu~hKGc^TKx{eo0J ziQRQQYfD3{apOT!tnYrXIDXY<&rjD%H}>+Lrrufp5IzY)kkm8m?z30K9umMdWjQSD zq$HCM8(I72(Q<(`d?LvR_B6n_zg(S<<;Bgs4nAiNRt?I~M#>PupYA?Oz39pZs(m_Crf8U zuc3Y~_$<~k3DeEo^?Vg~Nv-vaHYk1SZV0xF$#5;V9%+Eyc0y!BU5} zO_T2XcDlGd-<*3>Rg&L2q{&IS90So8oG3=SltdjZRRMJz?FwhZF(p1(!WEx4RRhBYV`kZs ztcd)$koNKtE$kTP_7kJ}zQr_TZbiRKK5LjoBc%~vt*vN?TH;g8 z$scKN@Ws0izcgyO&jiWbVSe8Is6ypLINkszV=+F3-)pSrtIbk$o!qZFo+=e-kzA^w zg(*c#0^83{j+sH3Ovb)n>(ge+(^y{=dn`niYNbN_+^{K+>|f;~M#}_2nC7?+&||KA zT@0^A4zDpPYXp$pr8^v3|84>60r#FChFceWx72C9hdWoY{d1{os;59)^x;LvpiD|E z+N(bd72Z+|ojUh;KTMLblJEUA^WgeHLIm&23~%dubYUweqf`s1iWvpayz>MmY-RHl z=YwXZmJ_9B8nnZWak(gnK%EaJ4Ku?ASMJH=>FXq zp$FXO^BXz-Ns#|zIb(N5ZRt4NUg-QwO;em61BwdA6}E$TcBRFNHQ~ju`3>gS3hD3* zO-!fw^-OnHBtR-x-VVI>x$nC3QODP8ush@4yJmoZ+oV)&#FRLZmDnLu^@et2l!dVi zA2P){lh2wfKlmPHE|`uu-QngvR##OILKsi6NTbZkko!AQt6G>;;$>~l`76ocE;ahY z)d9Pi|Iir*6q&wDDnN|6WCm9{a;&|mnPU9>-V7`vvTE#<14)HR;Y}ft4Qwv*Nzrfg zz@vA~4)5Pi*Y;d+S@BYlg-W@H|_9SoN%TDZfYL`RD}c<8-_lv*L~_l zBZB+J;yV_S)O$rD(WCxWo=4Px-v`<7e5AJ?=S7YPPR`so+PgZ%sRKs{wcp7(Md>QL z%jW5;H?`050m?ckKiu$aKOSS|dR+Z!0!_Q#!&kE_m)o~io>wng86m4% zkvoweJJ^)t@-CJ6ewOkGoHkBFw@4yIh+*~QgID8y75rDg9~^~tazBRGY%zqPJkZaOhK5+lGH4OKpRd1;(JK| zcli)T74osvXM>yM^NI=wWtmY9liku5&LE|!keLpLlLe=cEt5eA6TQvi+av@tV zwIp?Z_CSC-i0$yCdIDSPt*x)E+H1|JM+nEis}NC-55x{@;t>TFqf5qI)vObr#8S#c zHSVf5f}9K60N?F@FiU>U9*1S3K;PRET@s+*|Kq{&uj(xm-{@pc@t@IJ8}TVR$POo{ zlpx*(d@IQ}o3t7|W#;cdU043}XfmVQ>x`6hEMQk?7m6_&F}WTED&R-7Dal~jS}hp{ zOMM|sC=G>F3(wORB|9q^7pcy@@Kr{P7v?Y?G56mp?>kXFv?D+0ZVa;@8>ag*ILvpOnf18=wES~6Fh(uGyOdhBX@@puGVyl&xt-|f6Pgl8(TLaCPH+&*F! z2g*vs6ZQ6~rOh5Ot1(r~Xj)FJjye6`30tQ;7EZGbq0!2JEy%a>ITy)bHZc0`DD#sM zcnS{M5e~WF9yVHsU8pSWgaz4}ey9QS--NXtalS(N<581PEOPK%VfXG(QpVb-BAmsm z6H>+_fSLT@9(mDySFbsV*^~vuz&(dT`$u62tEH=|0zp{ES$aHqD8BjXg*i0p;M^x zd@~xl)PM{JCYu!|gD+6W#ve>Y*U9c0F$lL-k2Q^~-!0`E{%m4@ zDeId4V+@Zdr4wb_AAIqj7H;<>p2mB_F}BjC?X@NO5k#uX-J|%wIoe_)Cw1KI9_YqW3F8+x`BQ87Kr;H!(=E`Pa0_zq5 zo18dd7ZW=3Fj-akgFsbo?$U0(K#z-09NC@XP#$_W&YwEAu<;wfLy$cBGq6U{LC_>m z8%^MoZkBk=_b}wl*IJ;%c$^`5+XZqZGH&ksY^x)Hl(#cyk z@7_7w3`W__?OyIKrD3uq+^c;;AQy^5z5!y3GXXeY|I;B6-DL-=B0Jy}B9NMLw8ZAo#!b!*}yu>mmX4 zhaCxTQy%qtLHZYSsL1ZEe!(NQZUGW7ok{{KOKY2hPg!xoD<);*UON%Z>#b6Y$M%n% z2i6%=;LahK7=ai#m%UFpiXN^*AJCRTkMbMl63o%VKLih0%Wn3e=NRls zfF+Jxzi^1mZ=sLB9OV47@BU(N^gsNL;tM{hDFvV2I!5!#7lmud(;cRBE)Nq+j;Fkn z1#EXDe|4Ju-5o?4{TE^RBvAkW diff --git a/src/std/rec/image/compress-1.png b/src/std/rec/image/compress-1.png new file mode 100644 index 0000000000000000000000000000000000000000..3001ce9f548d1c1761ddb5e3aa9d7bff8951ac90 GIT binary patch literal 2126 zcmV-U2(kBxP)KaTLv5q{=E;Kw8Ub%ei<@GBRLG1q}05ho(d{BndJ{`=Dyb0w^X-yeZh zlT|YE+y9@&n2V8{%Bo3-SeV8Be<~MUmEiyN~_}cL@_DAOb7iP7ppWvoRkFMjl;744!MOPG`V{ zl`sis^UF|2|4*PB!U}?s5_$%J(Gjoq{^wnhd#teg9oXGseT|~U8DNKb?6I-ZL_yqG z=hAp$GtpkjyR-$!Hb=gES5Q4xwhyQ6lR~LfPdqf1%w{29@*icSE-=#YJY!p!Ut#>? ziR#RxyPMIm2Z=KqcZ9q~MAa&n{OO-rac;3s3MRBz5v7)B8a~o6Dn(o>*keUx7G@ds zyTUV0RASA70CW{3F3_!M5*DF$wa`w@tIlaEFjG@_g+^)|Hb_#{dEe;#go;CHop3 zua?cRC~<#f?6=sb8kZyUeZ_^1nahVSRU|?h;*AB`S;Wif zYve{yjs}dfO0(dXhIgP}$Y*wPdUxnQ#)5Fgep6#V($B=r^~tuw=g2rS5s(hAkUSK$ zqMd0s`JA>-DnJFJE3x9j(y^qYU{^-{bRK;Y%e@OS_Us})g5KCiYNC_KsCP-cB_7$nZT6`dk_5HJ zw`i>l5X-%{{X^nlRHwKLNXkJ<@dW#TtL>z>i%WtLM zW}ifwIq;!E5*&es=1MZSF%AvW@=sjKQwI_F&i&H$Oig6Or7gM9a7LJC(!L9f39A4` z_(*DFPakJwXVi;$*idO~Mafno*jFxhq`f&Fwm_X~Ty38(!%8FGso@wwoYYG7X5!O| zgOM=kd2*ZqgKh1b?hO4K-EI0w6G_Pp|8)DTa+iinoP5?mP-g@QCOy!VKJ@;Tm{}v$jX4U1uOYhIUrmnXC4xkA`u`E;1es{Z@0U?_i%r?$B`Ri&&^L z!YsL&+&d!x3=21{Ci+##_fv$q!fl1gjKwUE8`nE(Cob{ie!L4&h}uhLB;FMy_+J0b zLcXnokvnh)`@Ahtn5;mED7#Lphc((a?OfHEAgE7mbvNeiVdl)D!Qh!yBdnOSARtz> zm9!ZIPCeO!Q9p&p!~WMI!^%tulaU3_%neVj2DQrce%?jcM>xnqxLj2Wb~zl^YlL!2x7OJmF; zy~7hdIx)sP7**0ocWn$B)=l|D)5-Z@7x;mA|Ociy#zllG3Lc!-)mtS^I}+- z#!SMV6<3o_Tu)vEAnbe|YGE2P34%m895BU$CBDa>eQ~hF0ZuQJ4yPQ07Z#>53n0SyldSk^pROa`(l1MLuq$iK2K4Kc2qHpE zyqg;Zy9)VOn8r+i0P`C|xV5a9rPXf+{n`alBL3_$n?e2sgQV5yZ9L070000vbVXQn zY+-a|cmP&GOj~JPAY5!^W^`e4a&LDaTxN1%V|y`udro~^b9HTBdu}~3eO^vUPEcQa zZhc#6UHK97cmMzZ4s=CWbaG{LZ)|mRX>V=-F*PuXMnC2N000bhMObuWZ)|UJ05C8x zFfcH}pZ1{u000(rMObuGZ)S9NVRB^vY+-a|crtKqXD(xJZAt~H3IG5A07*qoM6N<$ Ef^+cjn*aa+ literal 0 HcmV?d00001 diff --git a/src/std/rec/image/compress-2.gif b/src/std/rec/image/compress-2.gif deleted file mode 100644 index e4cbf62a7f500e418fe548c9785fa24831703ac6..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4136 zcmeH``9BkmqjSBh8Vk z8k?(JIlt237$H|k=KJ{k5#L`vkMHvzcs-u4$Kz=Uu`n?7__lBVzF85Gy}dn=|L4Ex zfxSK9f051qxr*}kfqfz(6cMfeEd8em5ecD)zT`=8WnLRrLRQ0-SDF7l@tBGg6#Qvse)UKZX6_so*k9>8Q0g{5@YAuzVziTH z&C!O`IlpqQ?c%)p(sF1eqp9>n<=6MP(RV$aTY=v?UZ_~QT^p(T(M7y6>`Kk9nfaJ! zmZarsuw-A(bSQh+(@?uGTkC@WI)|dlwzEc>9Q-B+>NA!qOu~HViycikBt-N@EoPC!EDx5te@V^LPc?jom0~8tXC)Y%D#_2V){(rC zY$XR_Wt|g^JezgRew&$d|AOFLu0|~IY!1|D)HCaX7^EoOo524{Hf-3=rvl#@7Lsl= z@d`2FL3mY~QWXDO-q|)2UVQ87sfcv;_WsQI#K$?9iy z`x4Zh0cwuQFYmYODlcm}>%UO+$+SK%reg-^K`=P*p}l1P+Xc+QS9d0L}uFBc-ztIh!2SN7ol`_~BCqHyR;* zF^C>&Q=uFEPq)hRkX5dk^!hp((TkcAtpNn}p-+E&vI$QsL-$-tmELKaage&aHG9}! zdjnj3@yhQZQARl(shy_vhHFRgU+xw-W>=dRY{uhb4wf@^V>Yh;*;u|i*vSz6I;?e| zx&*_KnIdY{o!>9@3*)dlMKu^XFQRRURXN}xt_uEF!s1T+^|2iCt*xto1bo7ivmUR5 ziN<1jT^QkT|L4PS0LcCLN=#el8EJULb)nJ<)+~@IEepQB_h5zapqnYT>%av?tt34< z!UB9`eYi|sN%pnzjE=i6BP->l5mXL7iO}i552mLeyIH3;c^#&IR?=c#OZzVIJOdA(#S~7~cX?!Oie*d+e;sSF}suWh%4l*xB| zIS+S!e$%k=GI+ND8fpL8CufZoQOiHMVCC3kzoCNMEwdCw-H%(U)h$p?g4Hrdnoh*4 z7ejcCZiEqzu3i=G=}#EY_zj=_x;nW>%NrE%5AP79`f$p37b`{Q!WZGSMe4#Nuh&L0 zLo?>DU!ntpYzF|Nt2u8T{?i2y>l$nSmc!w|lS43+J40f;%gu|R&|;JV3nX6|Z(b4Z zY3(L(l=q^i_&YU~P5dCs*B7BHZqm9Y)ufSv$(pzOtn5G>Zo`KIS72f@(>j#MCdAcwA?c{6m!!*3B}{3B zGVN-w`@B{qn)b?O@!G817m`Y(9h|y5;d4!zoQIiQrkiEV?c0OW1H`)TN}6~iHq`fD z>O&Mr2F_Uq6!e|(Lzw;pI$`@gYmg%Mge`s4*U{5($Q;coz9Q;x^xk>sjrK;NeAB!O zg4``r688A=*`EV4e38>I8DRv2FWv z1gbfiF6C3u=pRtx5~)A;?|US0bTNXZTq z{Wk2ge^=ts8*+xqAs%d znp?5b*nE(11?pp%X^nb3Xl8Q5Fb(cyuN8H*5w*dDn~dR`kq1uIW6@e$IintPKi zPnS(%5{<{FzUOYAY|(4WXM|L0wzL=q3G>y3EJTKr;tCEFJ%4$5<*!l8dz@4KqM6+j zg6iqtGc)0wn!TY53rL}|SVOO7MWoP$&TjKYif%<|OdEE$yVJ}glHBMOTVeGVb;Eh#m@@2W>mWX-zJ78`cQ2tr)uksT5G z#oR?%EO7!BJrsewq>p;WLj?UBEd=5e2w(t?XeHYbmokS-;NfbW;u*6*1QC+!i<^|Q zqSV1iBN(Oup#T|vy3Wh3Bf)($ycidI9!F62MXPVc-|GlhQ44$dAX=53#CZ@`Bazf- z5cP_OYMCRH_$I;h6S%x2zFKULTGD%7a_wC5fJ90MIK?k9<$)7nVkBj9D`g6h`pqEq z2ivYsEqPc1+xFl|JubD1i2cZpJ$4_X?VG%2;P*=+$XG3ch6L>TVy4xg>vQsZYJU5- zQx4*7#G&BBqbZV*7e`CL$Dsu2QTc!PFXGvEWl0f02viAwUl9mVE&-^FV&whgRn^l^ z``M`T!RJfxnubCf5I=ozJwwqT^DHoP6Y$~>(N+%+zD~mZE5IAo$C?2#29OMM^+anR z7!nDw+y>t*K{}AE?n_!ak)ol7Ko^L$8!2k2>b3{ad$27N5}xSkm;-}Y>@&=HY>0S* z&-pQz+;2tlsUmna7&ewQFdY-imnAtp(Z@ajZ^ zj@&vml9+&q_92<$NQX*DX%JHM4-!M2jP=XO7GzRKbIbUsylrBs9~pIvd~B5L?oH85 zq=XhyEVz`>-{f1+%xXhQGsKdMmuL(zrpO0nmVEa`bx9ibTg|BfQ z5on}7bqsHPtRqobKkOlZ&hn$_eMSj#DaSf!mN>*t1ohl+x^o1LL8K0!gY9dlf7_&N zl8~)F?!W8kqVu$7-4OLzMyq&^Zjn4HHg6VB{Vth54GsAv8FrkE7n1Tn;PSgR-UC`bVD&^y;x3_Efb?a4I-0Fplm_|J9&(a JQaC1J{J)wmzxn_G diff --git a/src/std/rec/image/compress-2.png b/src/std/rec/image/compress-2.png new file mode 100644 index 0000000000000000000000000000000000000000..5ce46e0413c9c606467ac552a9b7a07630dc0113 GIT binary patch literal 7608 zcmbVRc{tSH_a93ll(A$9lcu6%Uz4>o%48Qcm>AhbL$*Q4HW;*63R#luCS_-=W67>; zA!_VR2s3v2y+@z#^L&5L@A*By<&Syheeaxe&%Nh;&g*sVnJ7bj9rj}a$3P$u`^_8L z#vl+K3HUHDGXXP;t4G5?Afcd}+FGW*$fegy6|WW9v|nrnEqIq23tR;S-T0uh(VL;j zYmv0sk;0I6RwL*)D?LXri19Qi#EJ2-zQwC>5fB}-CWxM6D+Fx9_|H#KjMAj2-**N6 ziUxyC7&toM-!tGp=kGq=`6^Q+zrl9hpu^(C{qzJ-q-6fXx9lN*m<5^qHQI9*)%W+v z4({v0>~zeGoQ+t9ADja849s=>tLTcAk@~jueDzrV_v}f*jrD+$z;cIq7Y;H0)zU7q zE%~#REUXS@^*%-$_(>b}>>{HubHcI*e#E5>8GGtGM{pyEo^KV@afvQOlU`zOhpN7P z>sdO7*vTxB-`c^~bgVQ_D}_7Z(n z*2HGgQvt?{%!7QZe&zvtl@z<;=yUw^bj-fMhSi)nS?O(A5)PinJzuQfpM}`^G&ysO zrh#B}esu2x4}J9#4uYn4Wegqq&e{{$)ZCHAjlUyFI-IX$kXhuRk9z=Psl1@^zoTm4 zSk-%Xg$~`SC>jiQM}k}-hod>b^8A{E*WvR2gE6!#o#mfnO{0m}{vDSl zij@}{Hw%9R%s}V@jzWbI<$SA#6PK9in9rUL2HO&^by0$#2lEhigM;n$`4fqj$IqFr zU0zcTy0B`5dbDOV@aukdUMeRvT%aZ$9~l(w>1bkRi8DA~T3}5)Qh$-16NIKd@?Xsx3CBh?OQD4o{7`X z6=oSy&031pHDJopJYObT8igCRy!$bAA&^0L+nVS#t6(9AcCDcen$Ebd8nSp zjdpAuKE@g>U0?!cQ%_}yfMAvbH+Tf{e%7`zK=fW;L0voXd`mhKaLcejMRz+^1_j^0 zA#YS(Tj-)*0Lk3?O>r2qCi0b5g9Yem-&p~V^>Xq(bzCLhd{qehPioeGE&8^i=VZsX z2Gddh(tC;9x-^;HGy!R{!k5pCjGs>TxP0oKyJS)=VK?R8_R#NAbrP<>pfX>_Y4%xP z{`TsWi`8a|W4zllM7eDAaOd;*Tr--pzC>oXy^P&*H5-9>r8vdsZ*=>~cKZwBtIDrh zj`;8V84kb*>?n*V>0LsUD-KkyA`yNw(^*5W{mDY;w`RpS-LbOa)$#58*y+HM5>?6S z)pmRLt8{NG);D8Yu&fi#r-*9Z<8{dC7A%>y?zWtJu`~%&Tm)fTUbiT3$CAr{H?2&K zYsSiu{y>@#!VMMOvGrZf58C)vcSW$n$Dqp(zS+*(5KHT1NFlJjjXT9K)H2pZY+qp7 zhIq2L3R*JK*@9Iot4WtSP$M-^Td?CUHFiue)ebD&=j6EoX%c7F)JQSRb?6vP)R~Ax z*bt|HI9pQqCfm}A?W=w2`GZ`UXd!%eW1>e@Xh!sl^Ml@EcGB_vgA4nZ{Y6%{a|3m_ zQIkR>%-!{pm#0!gQqB5sXBQS)<~(!>A&w7-Q&yY*S#xk*DPVs1DaiO|e+AhMwwC~l z-==ow%lyu(a^HfJ6H7GsclSf}V<=5UF7UU>@r;Oerpk9h$=4pdFSmgMwcuJ;aBn9JGEpq6r9Ufib0Q@-(0 z1<+?jZ+|oWiMUQnjJRJ6Iiq~&kf*vW#t#-GeB^Ral$w$^Uq8)FnD=q7wC z+V!}->5RAfZ&FqaHX$jJvg%lqgMRW4XgNX@lJWVs-1;3? z_2zM}NC13$m!a#HIxW9x@bKqUsR)w^4LFOmgGEa>bCKft;#Iu3JBHlGPe6?C092GA zWgWqSPqg-+ID$3l=>g5O%v-i5s_KGbLX71BsKw3e=C*H>3?M_Jcb##AYf(8Fmuif! z=|{vp`iI)Q>G?`ui-1r6CAx0_2)jMH6-L8nI_6OTpuHo?!M-{sa9vwLjMIW)>JiM) zb5xojfa7Ur<)hI>YGzlZPDD?mGDnn$i)Lt=HKEW8e(-9Mr(Pm`^Q~9fV=GP-#RQA=$N;_joAG= zNoQ8|-)i3=t6-cKjXIeKx?xq403!;Evd5wXUE&k_yFy7-d6K;*%i@Kp=A69ne?Iw? zf?9aBosmHJzd5EED?$CDmfTE+DcPOD=rv6e#4ujjsj^^#H0qf9u@K9c&tm=Jydjof zJ?f=NmOStZS`l;-N~6q}MEUU$AW)vhfB+tuFSzp|{E*hYSbp%-m#w*!a$1ed}q3;QE3NANn}l?y*a7zBUdLxTpb zp>wBk+r;J8uj0K`xwin_odSceAa9l-U;CQZ2g~0?8ZhU(*v2H7`l^>3t zaCS~3tnuqS{H2Qws3YON1@=4hp*cn)-y_54c^oEs+e>CzbtHQ4L{FQUO#e#kQ+{G= zzDAnnarm_yYSw}cZA1~L8z;@yRK7c--_fxn@5FvIS8p197rsdo5@7BNmq8h%OqJFh z>jSp+I^OD2Ogtj3l)Jt7UE5dj3^XInK)ZPF=(nTA5#XaCvvIzHcb2iaz(Gd~MG9M2 zt+V+Udg*|=fzB}W8b&DWyL@iA`E+(tpS%t7q#5m@0MoSn<`S&PY;HC{?7Ive)Tt}o z915cT(vrEy_NX1ZetYSh?J+*6zEz_Zp3@A~j8ud+3a#2d`Dk?*w*6;vspn( zSEV9e^_9)xzy{Z*2){dzHrcuh%ha^`z06CBADbN9%9{;ErZZ~W+7RC~GfpW8_ss2( z5l2T{=KK0Ggc^c&{y@!~e#y+KY#!`ZrlqfK8|xK6!_0&tr+Y78Rvj^x<@=SKfZb|8 zEthOx*%mV{LaJ?S6LO^LR8UX(mnyh|%dG9mg_DgbCoq2EoG$VU3TF6oX5tFv=M<|) z&#MaTrY>)ej!Xqv)u!HePs{c5+13SArmZB01M25CJz#jB!~yY*(CE!=#2I9MzC`J# zR>e|_Y{z0Famb2C>D-GR>;QSwCBLJ1V&u1Y_kCBHRVUEKpV940SB4GDIWpb0F{hYGrQo<4H6hu6Ah_%0v z;A}nIdkfQ6)FR3rKGV(U$Za2XjUjWyaAK~tzYAw54uTcsv>*Gbs&>)J=3e149l_&5 z46>S1(0LMC(o8&k7%IVYK60MrnuC9BhcJYLEU-#k(QMgC#=-PR8~)Lt0|qQRpnBN#@>q zm<{Gzg`uV@3cRI<){F|-XnL6=N^}(C!l!U`zS8%~P5Fn)Pga#8Y3Xes*Z-ZxIbd*& zr7c5T6_y5<>T?~UnNKfLL(vv(4=r^#T*mihXbqk!VgpjZ#eq zkrP7s%qc)9qde`k*A7i&dXM(VfuS?=`KQAl&LEJN<8dY}x%N2oUg*eLr{DcF0d)o2 zIuGIMB=g>JViUIV*$zH-Sg<=q2Fa*XGMl*Gp{x+#+~zy0>LGzo(`n29VItQiKL56;-OH5p{K6KL*n>*v8kFMZX%pqm*3@dTe|N$ce?pTh%DMDAwZ z5aVp+Qxqeekv~D0qQLmu(Xp~ijJmf53ST?Tuu-Dlriv-T(ry&746Bk5`>) zyX=b2=U7OD>r*;&Mh0DFNcmg2l1OLnk=haeH=CQyBej#ecW|RR_LQ|B$`_AeV$Tp7 zRrprv&v?6K4T`C>cpI2><@!UlxP}1S;|e2ODH4E`2h=o`D1)I$qoEqL!&m)NEbdfJ zn~p>VT6eJcE$u-iIu$4xmB2eTsm@1DBp~ITv^Y9}3FOk0DnC{|6AEUH;Yv#xYclN; zgo&GciO`@4q<@0Z&EfX(Frj$yPD4gEz znlyng?23+WXaY~(`$XQRg`CnTk0^>LUVx|+Ef394G7xG-XVZ{dPCu$9k@jGsgMMMe zw|f5SN4>wyaTZ{XpI6QPG6xI599&sn&;Ml(pxjjOdi8o}Ref=fx)I+F8F87s^13vy zT>18Zc-#Zi`|>eoQl%w(WU?GXjUUT?-R*P6RSmyC`oQI@UB7rnnPZZ{$EP?M5=YU6 zCrP);-rXE@D=Rx`Z*~4I3X8Ohfa)YrFooMGeg?Z@J>pi7PZ8yAK*vrEp;f%B+J` zHz+bdVEKzi;^^AS$(6$H_1*z-^Xmx|mDnvObFf3v`3%c2UH}l0H@e%36OP+2#%&!$ z9gz3YJ+-sO>apV%ZoW|`Fitm-p9|;WM%QseGuhW4X1hw0Vu|$+${$Jl3+#TGUdW9w z;qt#{x3hv>nXjh&U?z|XiXPQtVynzQrUZ~2IksN_4HEYdVEx#;>Iyrbp})qM%J8zb zxUB<6$`V=(L%oe!3>fmDs@N)QQ2m~yoWP-N|M`W)LIK@2a}|vd zDaA>M&b^zevHmf74ZOu7VPGD6O+*fCAmwV05XJn~N&sTr9J11Llz`&d94_2AzVpBw zyiMes5L1EGJsWMZP}2z4*hjznp2ISw1tO?q>ZL!ie{lqh5QfH`sdbpBZ145|+&`s& zS#){S$I-LqWY*0Gl{|x@)qu1{OdJR%*q+q!PY>-39j*$CrTb^3OwWfFw4io4PrWhi z($UlSe_^Tr3Hy~g<7Fc>oNQk`*_G>qjDnj^e6G1$VzG5+u6{KN`|3LDwyF%uFRGdI zm)c9hy6&l{XbXf=7Zs@v3@qP}l7@RczBRYY@zsMH^+| zwk)cPpWGwLOMUwlMZ6jAd83wUJ=w0&^GCoWWhy0};fbjTVmrb2Ug`l0NhMdlK_SER zz0mWeA0{Zbfg(}JQMRx=kznwMA;R+(xryS)>GS;FAExD$!CjwlE*mf zwV}GTDL~?;*a9Sl%>IOeV7IgeIec9%-iyz*NYU0ij>{JfMpBDRVQ*eVb8@XUVnsC# zs_w&I_}2PgS?Tu`6uJjm;OQInKO(<=K1EEJhVeJ^kr4Ex9_3d4#;N|z_ME|thP;K@ zK6#ZhDc8A9#v4Gnd9jqkxUhZz>~U=8!<9q$;Q-oxF|6D#k$sga3}2iM%pTsCj4mC3 z8zpY0^@}GXO+L0_b4eLB%CV@62Xn0hh5TO!Sr!y{f=XItNR}8sdwBNmxBL)R0*T+h zBp8`4&l?{OmXiG4zTwDSU8W;N`M_aV26E+?O+ah3 zwxxhpU7Y$A%_T$Pxou}~m>^FhfIcnkBIn=h6%TMJ7cb~c|C?6qK=l@DdiL01n_3)z zXmisXmdggkLq{oSJ}bvexc?SwzzB_VsQYTG4dHJ+W<> zOk;tat*Dcw}a)z@H`AR>ij8zYal~I2fIYipr~ZDR z#t-d1r}4kvz3<>FIE2z!oP5C_HyY+n{=|ot+#X;hcz{R6EO5Ti($|%`wmwV(g2xF@ z=&nTSNI7J7{*Xr5c~LxS6(jM#^2FJf`r+3i$1e33CJmyd9bd+g-&vzRA`PH+X@^(b8|u)hWe3%z`P?Xy&;Pfz}u3`Ou10;+k-(mG>5X z8rqyWa=Kr?D>Ip^5{I~?9J@{&)Es=m_%kLD;+5bwdRja*cPx9W^=+V0hd9CQlc!dI|o@W+&^cuPh_fR-n3xXu@U9(^6c6nPDA-PrqMpo>4x zLm7AHuF%rNa_ketRjCK`)gPt}wT|h*KQL3G|sv z5!!goD(5VxOy}sCPm!=^I)zY^|IOw+{`Nj*fn4o^cQYOKmNZ`h7qX(`)rZ;HxCT)7 z>^b|;!wk;^`etTkkrRI*(GP&cHO`M(%$nAqkV^N<$@TjImO^NS1PhnG@w7W-6`x1b+)s+c!C z(j)ks1`X_E!7)6tuuJEe7lB4sKFfq&N!xvwwmPkRnW3aK2~gJWP{!eCQmQs>I}^*I=j>pE9Nmy`kaI0w^3kxwq1|D>7-3!3P&s{IprdT z@JeTKUO}On^m5FnVUrL<(0M#OPUq`&BpLk{R)`r^KD3Fj;37S(Fs(DKtskn{Wbb21kAl-j({ zR^w+MnI!Mmn5c2pY8Xdc2)Z0BR6`%^obq2j{0^}|GE3t&qUgVH`F|3 z-=EfDW&=u#6HRs0GirJ@4!y%qg_NdR>K)>2JHwu6x&b8Owl90X?@AHd#r<9|!DI1y z1uM`N<>h!LL2Ho)Ya#&= Date: Wed, 4 Sep 2019 14:06:52 +0200 Subject: [PATCH 05/28] Rename README to .md --- documentation/{README.html => README.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename documentation/{README.html => README.md} (100%) diff --git a/documentation/README.html b/documentation/README.md similarity index 100% rename from documentation/README.html rename to documentation/README.md From 1cf831939ae0d2a43df04e739c6e29a29444012a Mon Sep 17 00:00:00 2001 From: Niamh Dougan Date: Wed, 4 Sep 2019 14:22:10 +0200 Subject: [PATCH 06/28] Convert HTML in README.md to Github Markdown --- documentation/README.md | 543 ++++++++++++++++++++-------------------- 1 file changed, 268 insertions(+), 275 deletions(-) diff --git a/documentation/README.md b/documentation/README.md index 982079e01..149b8fae9 100644 --- a/documentation/README.md +++ b/documentation/README.md @@ -1,152 +1,153 @@ - - - - -README - EPICS Base Installation Instructions - - -
-

Installation Instructions

-

EPICS Base Release 3.15.6


-
-
-

Table of Contents

- -
+# Installation Instructions -

What is EPICS base?

-
The Experimental Physics and Industrial Control Systems - (EPICS) is an extensible set of software components and tools with - which application developers can create a control system. This control - system can be used to control accelerators, detectors, telescopes, or - other scientific experimental equipment. EPICS base is the set of core - software, i.e. the components of EPICS without which EPICS would not - function. EPICS base allows an arbitrary number of target systems, IOCs - (input/output controllers), and host systems, OPIs (operator - interfaces) of various types.
+## EPICS Base Release 3.15.6 -

What is new in this release?

-
Please check the RELEASE_NOTES file in the distribution for - description of changes and release migration details.
+ -

Copyright

-
Please review the LICENSE file included in the - distribution for legal terms of usage.
+----- -

Supported platforms

+### Table of Contents -
The list of platforms supported by this version of EPICS base - is given in the configure/CONFIG_SITE file. If you are trying to build - EPICS Base on an unlisted host or for a different target machine you - must have the proper host/target cross compiler and header files, and - you will have to create and add the appropriate new configure files to - the base/configure/os/directory. You can start by copying existing - configuration files in the configure/os directory and then make changes - for your new platforms.
+ - [What is EPICS base?](#0_0_1) + - [What is new in this release?](#0_0_2) + - [Copyright](#0_0_3) + - [Supported platforms](#0_0_4) + - [Supported compilers](#0_0_5) + - [Software requirements](#0_0_6) + - [Host system storage requirements](#0_0_7) + - [Documentation](#0_0_8) + - [Directory Structure](#0_0_10) + - [Build related components](#0_0_11) + - [Building EPICS base (Unix and Win32)](#0_0_12) + - [Example application and extension](#0_0_13) + - [Multiple host platforms](#0_0_14) -

Supported compilers

+----- -
This version of EPICS base has been built and tested using the host - vendor's C and C++ compilers, as well as the GNU gcc and g++ compilers. The GNU - cross-compilers work for all cross-compiled targets. You may need the C and C++ - compilers to be in your search path to do EPICS builds; check the definitions - of CC and CCC in base/configure/os/CONFIG.<host>.<host> if you have - problems.
+### What is EPICS base? -

Software requirements

+The Experimental Physics and Industrial Control Systems (EPICS) is an +extensible set of software components and tools with which application +developers can create a control system. This control system can be +used to control accelerators, detectors, telescopes, or other +scientific experimental equipment. EPICS base is the set of core +software, i.e. the components of EPICS without which EPICS would not +function. EPICS base allows an arbitrary number of target systems, +IOCs (input/output controllers), and host systems, OPIs (operator +interfaces) of various types. -
GNU make
- You must use GNU make, gnumake, for any EPICS builds. Set your path - so that a gnumake version 3.81 or later is available. +### What is new in this release? -

Perl
- You must have Perl version 5.8.1 or later installed. The EPICS configuration - files do not specify the perl full pathname, so the perl executable must - be found through your normal search path.

+Please check the RELEASE\_NOTES file in the distribution for +description of changes and release migration details. -

Unzip and tar (Winzip on WIN32 systems)
- You must have tools available to unzip and untar the EPICS base - distribution file.

+### Copyright -

Target systems
- EPICS supports IOCs running on embedded platforms such as VxWorks - and RTEMS built using a cross-compiler, and also supports soft IOCs running - as processes on the host platform.

+Please review the LICENSE file included in the distribution for legal +terms of usage. -

vxWorks
- You must have vxWorks 5.5.x or 6.x installed if any of your target systems are - vxWorks systems; the C++ compiler for vxWorks 5.4 is now too old to support. - The vxWorks installation provides the cross-compiler and header files needed to - build for these targets. The absolute path to and the version number of the - vxWorks installation must be set in the - base/configure/os/CONFIG_SITE.Common.vxWorksCommon file or in one of its - target-specific overrides.

+### Supported platforms -

Consult the vxWorks - 5.x or vxWorks - 6.x EPICS web pages about and the vxWorks documentation for information - about configuring your vxWorks operating system for use with EPICS.

+The list of platforms supported by this version of EPICS base is given +in the configure/CONFIG\_SITE file. If you are trying to build EPICS +Base on an unlisted host or for a different target machine you must +have the proper host/target cross compiler and header files, and you +will have to create and add the appropriate new configure files to the +base/configure/os/directory. You can start by copying existing +configuration files in the configure/os directory and then make +changes for your new platforms. -

RTEMS
- For RTEMS targets, you need RTEMS core and toolset version 4.9.2 or later.

+### Supported compilers -

GNU readline or Tecla library
- GNU readline and Tecla libraries can be used by the IOC shell to - provide command line editing and command line history recall and edit. - GNU readline (or Tecla library) must be installed on your target system - when COMMANDLINE_LIBRARY is set to READLINE (or TECLA) for that target. - EPICS (EPICS shell) is the default specified in CONFIG_COMMON. A - READLINE override is defined for linux-x86 in the EPICS distribution. - Comment out COMMANDLINE_LIBRARY=READLINE in - configure/os/CONFIG_SITE.Common.linux-x86 if readline is not installed - on linux-x86. Command-line editing and history will then be those - supplied by the os. On vxWorks the ledLib command-line input library is - used instead.

-
+This version of EPICS base has been built and tested using the host +vendor's C and C++ compilers, as well as the GNU gcc and g++ +compilers. The GNU cross-compilers work for all cross-compiled +targets. You may need the C and C++ compilers to be in your search +path to do EPICS builds; check the definitions of CC and CCC in +base/configure/os/CONFIG.<host>.<host> if you have problems. -

Host system storage requirements

+### Software requirements -
The compressed tar file is approximately 1.6 MB in size. The - distribution source tree takes up approximately 12 MB. Each host target will - need around 40 MB for build files, and each cross-compiled target around 20 - MB.
+**GNU make** +You must use GNU make, gnumake, for any EPICS builds. Set your path so +that a gnumake version 3.81 or later is available. -

Documentation

-
EPICS documentation is available through the - EPICS website at Argonne. -

Release specific documentation can also be found in the base/documentation - directory of the distribution.

+**Perl** +You must have Perl version 5.8.1 or later installed. The EPICS +configuration files do not specify the perl full pathname, so the perl +executable must be found through your normal search path. -

Directory Structure

-

Distribution directory structure:

+**Unzip and tar (Winzip on WIN32 systems)** +You must have tools available to unzip and untar the EPICS base +distribution file. -
+**Target systems**  
+EPICS supports IOCs running on embedded platforms such as VxWorks and
+RTEMS built using a cross-compiler, and also supports soft IOCs
+running as processes on the host platform.
+
+**vxWorks**  
+You must have vxWorks 5.5.x or 6.x installed if any of your target
+systems are vxWorks systems; the C++ compiler for vxWorks 5.4 is now
+too old to support. The vxWorks installation provides the
+cross-compiler and header files needed to build for these targets. The
+absolute path to and the version number of the vxWorks installation
+must be set in the base/configure/os/CONFIG\_SITE.Common.vxWorksCommon
+file or in one of its target-specific overrides.
+
+Consult the [vxWorks 5.x](https://epics.anl.gov/base/tornado.php) or
+[vxWorks 6.x](https://epics.anl.gov/base/vxWorks6.php) EPICS web pages
+about and the vxWorks documentation for information about configuring
+your vxWorks operating system for use with EPICS.
+
+**RTEMS**  
+For RTEMS targets, you need RTEMS core and toolset version 4.9.2 or
+later.
+
+**GNU readline or Tecla library**  
+GNU readline and Tecla libraries can be used by the IOC shell to
+provide command line editing and command line history recall and edit.
+GNU readline (or Tecla library) must be installed on your target
+system when COMMANDLINE\_LIBRARY is set to READLINE (or TECLA) for
+that target. EPICS (EPICS shell) is the default specified in
+CONFIG\_COMMON. A READLINE override is defined for linux-x86 in the
+EPICS distribution. Comment out COMMANDLINE\_LIBRARY=READLINE in
+configure/os/CONFIG\_SITE.Common.linux-x86 if readline is not
+installed on linux-x86. Command-line editing and history will then be
+those supplied by the os. On vxWorks the ledLib command-line input
+library is used instead.
+
+### Host system storage requirements
+
+The compressed tar file is approximately 1.6 MB in size. The
+distribution source tree takes up approximately 12 MB. Each host
+target will need around 40 MB for build files, and each cross-compiled
+target around 20 MB.
+
+### Documentation
+
+EPICS documentation is available through the [EPICS
+website](https://epics.anl.gov/) at Argonne.
+
+Release specific documentation can also be found in the
+base/documentation directory of the distribution.
+
+### Directory Structure
+
+#### Distribution directory structure:
+
+``` 
         base                    Root directory of the base distribution
         base/configure          Operating system independent build config files
         base/configure/os       Operating system dependent build config files
         base/documentation      Distribution documentation
         base/src                Source code in various subdirectories
         base/startup            Scripts for setting up path and environment
-
+``` -

Install directories created by the build:

-
+#### Install directories created by the build:
+
+``` 
         bin                     Installed scripts and executables in subdirs
         cfg                     Installed build configuration files
         db                      Installed data bases
@@ -159,37 +160,37 @@
         lib                     Installed libraries in arch subdirectories
         lib/perl                Installed perl modules
         templates               Installed templates
-
-
+``` -

Build related components

-
+### Build related components -

base/documentation directory - contains setup, build, and install - documents

- 
+#### base/documentation directory - contains setup, build, and install documents
+
+``` 
         README.1st           Instructions for setup and building epics base
         README.html          html version of README.1st
         README.darwin.html   Installation notes for Mac OS X (Darwin)
         RELEASE_NOTES.html   Notes on release changes
         KnownProblems.html   List of known problems and workarounds
-
+``` -

base/startup directory - contains scripts to set environment and path

-
+#### base/startup directory - contains scripts to set environment and path
+
+``` 
         EpicsHostArch       Shell script to set EPICS_HOST_ARCH env variable
         unix.csh            C shell script to set path and env variables
         unix.sh             Bourne shell script to set path and env variables
         win32.bat           Bat file example to configure win32-x86 target
         windows.bat         Bat file example to configure windows-x64 target
-
+``` -

base/configure directory - contains build definitions and rules

-
+#### base/configure directory - contains build definitions and rules
+
+``` 
         CONFIG                Includes configure files and allows variable overrides
         CONFIG.CrossCommon    Cross build definitions
         CONFIG.gnuCommon      Gnu compiler build definitions for all archs
-        CONFIG_ADDONS         Definitions for <osclass> and DEFAULT options
+        CONFIG_ADDONS         Definitions for <osclass> and DEFAULT options
         CONFIG_APP_INCLUDE    
         CONFIG_BASE           EPICS base tool and location definitions
         CONFIG_BASE_VERSION   Definitions for EPICS base version number
@@ -209,175 +210,167 @@
         RULES_EXPAND          
         RULES_FILE_TYPE       
         RULES_TARGET          
-        RULES_TOP             Rules specific to a <top> dir (uninstall and tar)
+        RULES_TOP             Rules specific to a <top> dir (uninstall and tar)
         Sample.Makefile       Sample makefile with comments
-
+``` -

base/configure/os directory - contains os-arch specific definitions

-
-        CONFIG.<host>.<target>      Specific host-target build definitions
-        CONFIG.Common.<target>      Specific target definitions for all hosts
-        CONFIG.<host>.Common        Specific host definitions for all targets
+#### base/configure/os directory - contains os-arch specific definitions
+
+``` 
+        CONFIG.<host>.<target>      Specific host-target build definitions
+        CONFIG.Common.<target>      Specific target definitions for all hosts
+        CONFIG.<host>.Common        Specific host definitions for all targets
         CONFIG.UnixCommon.Common    Definitions for Unix hosts and all targets
         CONFIG.Common.UnixCommon    Definitions for Unix targets and all hosts
         CONFIG.Common.vxWorksCommon Specific host definitions for all vx targets
-        CONFIG_SITE.<host>.<target> Site specific host-target definitions
-        CONFIG_SITE.Common.<target> Site specific target defs for all hosts
-        CONFIG_SITE.<host>.Common   Site specific host defs for all targets
-
+ CONFIG_SITE.<host>.<target> Site specific host-target definitions + CONFIG_SITE.Common.<target> Site specific target defs for all hosts + CONFIG_SITE.<host>.Common Site specific host defs for all targets +``` -
+### Building EPICS base (Unix and Win32) -

Building EPICS base (Unix and Win32)

-
+#### Unpack file -

Unpack file

-
Unzip and untar the distribution file. Use WinZip on Windows - systems. -
+systems. -

Set environment variables

-
-Files in the base/startup directory have been provided to - help set required path and other environment variables. +#### Set environment variables -

EPICS_HOST_ARCH
- Before you can build or use EPICS R3.15, the environment variable - EPICS_HOST_ARCH must be defined. A perl script EpicsHostArch.pl in the - base/startup directory has been provided to help set EPICS_HOST_ARCH. - You should have EPICS_HOST_ARCH set to your host operating system - followed by a dash and then your host architecture, e.g. solaris-sparc. - If you are not using the OS vendor's c/c++ compiler for host builds, - you will need another dash followed by the alternate compiler name - (e.g. "-gnu" for GNU c/c++ compilers on a solaris host or "-mingw" - for MinGW c/c++ compilers on a WIN32 host). See configure/CONFIG_SITE - for a list of supported EPICS_HOST_ARCH values.

+Files in the base/startup directory have been provided to help set +required path and other environment variables. -

PERLLIB
- On WIN32, some versions of Perl require that the environment - variable PERLLIB be set to <perl directory location>.

+**EPICS\_HOST\_ARCH** +Before you can build or use EPICS R3.15, the environment variable +EPICS\_HOST\_ARCH must be defined. A perl script EpicsHostArch.pl in +the base/startup directory has been provided to help set +EPICS\_HOST\_ARCH. You should have EPICS\_HOST\_ARCH set to your +host operating system followed by a dash and then your host +architecture, e.g. solaris-sparc. If you are not using the OS +vendor's c/c++ compiler for host builds, you will need another dash +followed by the alternate compiler name (e.g. "-gnu" for GNU c/c++ +compilers on a solaris host or "-mingw" for MinGW c/c++ compilers on +a WIN32 host). See configure/CONFIG\_SITE for a list of supported +EPICS\_HOST\_ARCH values. -

PATH
- As already mentioned, you must have the perl executable and you may - need C and C++ compilers in your search path. For building base you - also must have echo in your search path. For Unix host builds you also - need ln, cpp, cp, rm, mv, and mkdir in your search path and /bin/chmod - must exist. On some Unix systems you may also need ar and ranlib in - your path, and the C compiler may require as and ld in your path. On - solaris systems you need uname in your path.

+**PERLLIB** +On WIN32, some versions of Perl require that the environment +variable PERLLIB be set to <perl directory location>. -

LD_LIBRARY_PATH
+**PATH** +As already mentioned, you must have the perl executable and you may +need C and C++ compilers in your search path. For building base you +also must have echo in your search path. For Unix host builds you +also need ln, cpp, cp, rm, mv, and mkdir in your search path and +/bin/chmod must exist. On some Unix systems you may also need ar and +ranlib in your path, and the C compiler may require as and ld in +your path. On solaris systems you need uname in your path. - R3.15 shared libraries and executables normally contain the full path - to any libraries they require. - However, if you move the EPICS files or directories from their build-time - location then in order for the shared libraries to be found at runtime - LD_LIBRARY_PATH must include the full pathname to - $(INSTALL_LOCATION)/lib/$(EPICS_HOST_ARCH) when invoking executables, or - some equivalent OS-specific mechanism (such as /etc/ld.so.conf on Linux) - must be used. - Shared libraries are now built by default on all Unix type hosts.

-
+**LD\_LIBRARY\_PATH** +R3.15 shared libraries and executables normally contain the full +path to any libraries they require. However, if you move the EPICS +files or directories from their build-time location then in order +for the shared libraries to be found at runtime LD\_LIBRARY\_PATH +must include the full pathname to +$(INSTALL\_LOCATION)/lib/$(EPICS\_HOST\_ARCH) when invoking +executables, or some equivalent OS-specific mechanism (such as +/etc/ld.so.conf on Linux) must be used. Shared libraries are now +built by default on all Unix type hosts. -

Do site-specific build configuration

-
+#### Do site-specific build configuration -Site configuration
- To configure EPICS, you may want to modify the default definitions - in the following files: -
+**Site configuration**  
+To configure EPICS, you may want to modify the default definitions
+in the following files:
+
+``` 
         configure/CONFIG_SITE      Build choices. Specify target archs.
         configure/CONFIG_SITE_ENV  Environment variable defaults
         configure/RELEASE          TORNADO2 full path location
-
+``` - Host configuration
- To configure each host system, you may override the default - definitions by adding a new file in the configure/os directory with - override definitions. The new file should have the same name as the - distribution file to be overridden except with CONFIG in the name - changed to CONFIG_SITE. +**Host configuration** +To configure each host system, you may override the default +definitions by adding a new file in the configure/os directory with +override definitions. The new file should have the same name as the +distribution file to be overridden except with CONFIG in the name +changed to CONFIG\_SITE. -
-        configure/os/CONFIG.<host>.<host>      Host build settings
-        configure/os/CONFIG.<host>.Common      Host common build settings
-
+``` + configure/os/CONFIG.<host>.<host> Host build settings + configure/os/CONFIG.<host>.Common Host common build settings +``` -Target configuration
- To configure each target system, you may override the default - definitions by adding a new file in the configure/os directory with - override definitions. The new file should have the same name as the - distribution file to be overridden except with CONFIG in the name - replaced by CONFIG_SITE. This step is necessary even if the host system - is the only target system. - 
-        configure/os/CONFIG.Common.<target>     Target common settings
-        configure/os/CONFIG.<host>.<target>     Host-target settings
-
-
+**Target configuration** +To configure each target system, you may override the default +definitions by adding a new file in the configure/os directory with +override definitions. The new file should have the same name as the +distribution file to be overridden except with CONFIG in the name +replaced by CONFIG\_SITE. This step is necessary even if the host +system is the only target system. -

Build EPICS base

-
After configuring the build you should be able to build - EPICS base by issuing the following commands in the distribution's root - directory (base): - 
+``` 
+        configure/os/CONFIG.Common.<target>     Target common settings
+        configure/os/CONFIG.<host>.<target>     Host-target settings
+```
+
+#### Build EPICS base
+
+After configuring the build you should be able to build EPICS base
+by issuing the following commands in the distribution's root
+directory (base):
+
+``` 
         gnumake clean uninstall
         gnumake
-
+``` - The command "gnumake clean uninstall" - will remove all files and directories generated by a previous build. - The command "gnumake" will build and install everything for the - configured host and targets. +The command "gnumake clean uninstall" will remove all files and +directories generated by a previous build. The command "gnumake" +will build and install everything for the configured host and +targets. -

It is recommended that you do a "gnumake clean uninstall" at the - root directory of an EPICS directory structure before each complete - rebuild to ensure that all components will be rebuilt. -

-
+It is recommended that you do a "gnumake clean uninstall" at the +root directory of an EPICS directory structure before each complete +rebuild to ensure that all components will be rebuilt. -

Example application and extension

-
A perl tool, makeBaseApp.pl is included in the distribution - file. This script will create a sample application that can be built - and then executed to try out this release of base. +### Example application and extension -

- Instructions for building and executing the 3.15 example application - can be found in the section "Example Application" of Chapter 2, - "Getting Started", in the "IOC Application Developer's Guide" for this - release. The "Example IOC Application" section briefly explains how to - create and build an example application in a user created <top> - directory. It also explains how to run the example application on a - vxWorks ioc or as a process on the host system. - By running the example application as a host-based IOC, you will be - able to quickly implement a complete EPICS system and be able to run channel - access clients on the host system. +A perl tool, makeBaseApp.pl is included in the distribution file. This +script will create a sample application that can be built and then +executed to try out this release of base. -

- A perl script, - makeBaseExt.pl, is included in the distribution file. This script will - create a sample extension that can be built and executed. The - makeBaseApp.pl and makeBaseExt.pl scripts are installed into the - install location bin/<hostarch> directory during the base build. -

+Instructions for building and executing the 3.15 example application +can be found in the section "Example Application" of Chapter 2, +"Getting Started", in the "IOC Application Developer's Guide" for this +release. The "Example IOC Application" section briefly explains how to +create and build an example application in a user created <top> +directory. It also explains how to run the example application on a +vxWorks ioc or as a process on the host system. By running the example +application as a host-based IOC, you will be able to quickly implement +a complete EPICS system and be able to run channel access clients on +the host system. -

Multiple host platforms

-
You can build using a single EPICS directory structure on - multiple host systems and for multiple cross target systems. The - intermediate and binary files generated by the build will be created in - separate subdirectories and installed into the appropriate separate - host/target install directories. EPICS executables and perl scripts are - installed into the $(INSTALL_LOCATION)/bin/<arch> directories. - Libraries are installed into $(INSTALL_LOCATION)/lib/<arch>. - The default definition for $(INSTALL_LOCATION) is $(TOP) - which is the root directory in the distribution directory structure, - base. Created object files are stored in O.<arch> source - subdirectories, This allows objects for multiple cross target - architectures to be maintained at the same time. To build EPICS base - for a specific host/target combination you must have the proper - host/target C/C++ cross compiler and target header files and the - base/configure/os directory must have the appropriate configure files. -
- - +A perl script, makeBaseExt.pl, is included in the distribution file. +This script will create a sample extension that can be built and +executed. The makeBaseApp.pl and makeBaseExt.pl scripts are installed +into the install location bin/<hostarch> directory during the base +build. + +### Multiple host platforms + +You can build using a single EPICS directory structure on multiple +host systems and for multiple cross target systems. The intermediate +and binary files generated by the build will be created in separate +subdirectories and installed into the appropriate separate host/target +install directories. EPICS executables and perl scripts are installed +into the `$(INSTALL_LOCATION)/bin/` directories. Libraries are +installed into $`(INSTALL_LOCATION)/lib/`. The default +definition for `$(INSTALL_LOCATION)` is `$(TOP)` which is the root +directory in the distribution directory structure, base. Created +object files are stored in O.<arch> source subdirectories, This +allows objects for multiple cross target architectures to be +maintained at the same time. To build EPICS base for a specific +host/target combination you must have the proper host/target C/C++ +cross compiler and target header files and the base/configure/os +directory must have the appropriate configure files. From 177c377b816887c0e050494bac48ed0a06b2dff2 Mon Sep 17 00:00:00 2001 From: Niamh Dougan Date: Wed, 4 Sep 2019 15:08:32 +0200 Subject: [PATCH 07/28] Amend documentation filenames in README Also deleted old README.1st --- documentation/README.1st | 346 --------------------------------------- documentation/README.md | 3 +- 2 files changed, 1 insertion(+), 348 deletions(-) delete mode 100644 documentation/README.1st diff --git a/documentation/README.1st b/documentation/README.1st deleted file mode 100644 index 807ba2ade..000000000 --- a/documentation/README.1st +++ /dev/null @@ -1,346 +0,0 @@ - Installation Instructions - - EPICS Base Release 3.15.6 - - -------------------------------------------------------------------------- - - Table of Contents - - * What is EPICS base? - * What is new in this release? - * Copyright - * Supported platforms - * Supported compilers - * Software requirements - * Host system storage requirements - * Documentation - * Directory Structure - * Build related components - * Building EPICS base (Unix and Win32) - * Example application and extension - * Multiple host platforms - - -------------------------------------------------------------------------- - - What is EPICS base? - - The Experimental Physics and Industrial Control Systems (EPICS) is an - extensible set of software components and tools with which application - developers can create a control system. This control system can be used - to control accelerators, detectors, telescopes, or other scientific - experimental equipment. EPICS base is the set of core software, i.e. the - components of EPICS without which EPICS would not function. EPICS base - allows an arbitrary number of target systems, IOCs (input/output - controllers), and host systems, OPIs (operator interfaces) of various - types. - - What is new in this release? - - Please check the RELEASE_NOTES file in the distribution for description - of changes and release migration details. - - Copyright - - Please review the LICENSE file included in the distribution for legal - terms of usage. - - Supported platforms - - The list of platforms supported by this version of EPICS base is given - in the configure/CONFIG_SITE file. If you are trying to build EPICS Base - on an unlisted host or for a different target machine you must have the - proper host/target cross compiler and header files, and you will have to - create and add the appropriate new configure files to the - base/configure/os/directory. You can start by copying existing - configuration files in the configure/os directory and then make changes - for your new platforms. - - Supported compilers - - This version of EPICS base has been built and tested using the host - vendor's C and C++ compilers, as well as the GNU gcc and g++ compilers. - The GNU cross-compilers work for all cross-compiled targets. You may - need the C and C++ compilers to be in your search path to do EPICS - builds; check the definitions of CC and CCC in - base/configure/os/CONFIG.. if you have problems. - - Software requirements - - GNU make - You must use GNU make, gnumake, for any EPICS builds. Set your path so - that a gnumake version 3.81 or later is available. - - Perl - You must have Perl version 5.8.1 or later installed. The EPICS - configuration files do not specify the perl full pathname, so the perl - executable must be found through your normal search path. - - Unzip and tar (Winzip on WIN32 systems) - You must have tools available to unzip and untar the EPICS base - distribution file. - - Target systems - EPICS supports IOCs running on embedded platforms such as VxWorks and - RTEMS built using a cross-compiler, and also supports soft IOCs running - as processes on the host platform. - - vxWorks - You must have vxWorks 5.5.x or 6.x installed if any of your target - systems are vxWorks systems; the C++ compiler for vxWorks 5.4 is now too - old to support. The vxWorks installation provides the cross-compiler and - header files needed to build for these targets. The absolute path to and - the version number of the vxWorks installation must be set in the - base/configure/os/CONFIG_SITE.Common.vxWorksCommon file or in one of its - target-specific overrides. - - Consult the vxWorks 5.x or vxWorks 6.x EPICS web pages about and the - vxWorks documentation for information about configuring your vxWorks - operating system for use with EPICS. - - RTEMS - For RTEMS targets, you need RTEMS core and toolset version 4.9.2 or - later. - - GNU readline or Tecla library - GNU readline and Tecla libraries can be used by the IOC shell to provide - command line editing and command line history recall and edit. GNU - readline (or Tecla library) must be installed on your target system when - COMMANDLINE_LIBRARY is set to READLINE (or TECLA) for that target. EPICS - (EPICS shell) is the default specified in CONFIG_COMMON. A READLINE - override is defined for linux-x86 in the EPICS distribution. Comment out - COMMANDLINE_LIBRARY=READLINE in - configure/os/CONFIG_SITE.Common.linux-x86 if readline is not installed - on linux-x86. Command-line editing and history will then be those - supplied by the os. On vxWorks the ledLib command-line input library is - used instead. - - Host system storage requirements - - The compressed tar file is approximately 1.6 MB in size. The - distribution source tree takes up approximately 12 MB. Each host target - will need around 40 MB for build files, and each cross-compiled target - around 20 MB. - - Documentation - - EPICS documentation is available through the EPICS website at Argonne. - - Release specific documentation can also be found in the - base/documentation directory of the distribution. - - Directory Structure - - Distribution directory structure: - - base Root directory of the base distribution - base/configure Operating system independent build config files - base/configure/os Operating system dependent build config files - base/documentation Distribution documentation - base/src Source code in various subdirectories - base/startup Scripts for setting up path and environment - - Install directories created by the build: - - bin Installed scripts and executables in subdirs - cfg Installed build configuration files - db Installed data bases - dbd Installed data base definitions - doc Installed documentation files - html Installed html documentation - include Installed header files - include/os Installed os specific header files in subdirs - include/compiler Installed compiler-specific header files - lib Installed libraries in arch subdirectories - lib/perl Installed perl modules - templates Installed templates - - Build related components - - base/documentation directory - contains setup, build, and install documents - - README.1st Instructions for setup and building epics base - README.html html version of README.1st - README.darwin.html Installation notes for Mac OS X (Darwin) - RELEASE_NOTES.html Notes on release changes - KnownProblems.html List of known problems and workarounds - - base/startup directory - contains scripts to set environment and path - - EpicsHostArch Shell script to set EPICS_HOST_ARCH env variable - unix.csh C shell script to set path and env variables - unix.sh Bourne shell script to set path and env variables - win32.bat Bat file example to configure win32-x86 target - windows.bat Bat file example to configure windows-x64 target - - base/configure directory - contains build definitions and rules - - CONFIG Includes configure files and allows variable overrides - CONFIG.CrossCommon Cross build definitions - CONFIG.gnuCommon Gnu compiler build definitions for all archs - CONFIG_ADDONS Definitions for and DEFAULT options - CONFIG_APP_INCLUDE - CONFIG_BASE EPICS base tool and location definitions - CONFIG_BASE_VERSION Definitions for EPICS base version number - CONFIG_COMMON Definitions common to all builds - CONFIG_ENV Definitions of EPICS environment variables - CONFIG_FILE_TYPE - CONFIG_SITE Site specific make definitions - CONFIG_SITE_ENV Site defaults for EPICS environment variables - MAKEFILE Installs CONFIG* RULES* creates - RELEASE Location of external products - RULES Includes appropriate rules file - RULES.Db Rules for database and database definition files - RULES.ioc Rules for application iocBoot/ioc* directory - RULES_ARCHS Definitions and rules for building architectures - RULES_BUILD Build and install rules and definitions - RULES_DIRS Definitions and rules for building subdirectories - RULES_EXPAND - RULES_FILE_TYPE - RULES_TARGET - RULES_TOP Rules specific to a dir (uninstall and tar) - Sample.Makefile Sample makefile with comments - - base/configure/os directory - contains os-arch specific definitions - - CONFIG.. Specific host-target build definitions - CONFIG.Common. Specific target definitions for all hosts - CONFIG..Common Specific host definitions for all targets - CONFIG.UnixCommon.Common Definitions for Unix hosts and all targets - CONFIG.Common.UnixCommon Definitions for Unix targets and all hosts - CONFIG.Common.vxWorksCommon Specific host definitions for all vx targets - CONFIG_SITE.. Site specific host-target definitions - CONFIG_SITE.Common. Site specific target defs for all hosts - CONFIG_SITE..Common Site specific host defs for all targets - - Building EPICS base (Unix and Win32) - - Unpack file - - Unzip and untar the distribution file. Use WinZip on Windows systems. - - Set environment variables - - Files in the base/startup directory have been provided to help set - required path and other environment variables. - - EPICS_HOST_ARCH - Before you can build or use EPICS R3.15, the environment variable - EPICS_HOST_ARCH must be defined. A perl script EpicsHostArch.pl in the - base/startup directory has been provided to help set EPICS_HOST_ARCH. - You should have EPICS_HOST_ARCH set to your host operating system - followed by a dash and then your host architecture, e.g. - solaris-sparc. If you are not using the OS vendor's c/c++ compiler for - host builds, you will need another dash followed by the alternate - compiler name (e.g. "-gnu" for GNU c/c++ compilers on a solaris host - or "-mingw" for MinGW c/c++ compilers on a WIN32 host). See - configure/CONFIG_SITE for a list of supported EPICS_HOST_ARCH values. - - PERLLIB - On WIN32, some versions of Perl require that the environment variable - PERLLIB be set to . - - PATH - As already mentioned, you must have the perl executable and you may - need C and C++ compilers in your search path. For building base you - also must have echo in your search path. For Unix host builds you also - need ln, cpp, cp, rm, mv, and mkdir in your search path and /bin/chmod - must exist. On some Unix systems you may also need ar and ranlib in - your path, and the C compiler may require as and ld in your path. On - solaris systems you need uname in your path. - - LD_LIBRARY_PATH - R3.15 shared libraries and executables normally contain the full path - to any libraries they require. However, if you move the EPICS files or - directories from their build-time location then in order for the - shared libraries to be found at runtime LD_LIBRARY_PATH must include - the full pathname to $(INSTALL_LOCATION)/lib/$(EPICS_HOST_ARCH) when - invoking executables, or some equivalent OS-specific mechanism (such - as /etc/ld.so.conf on Linux) must be used. Shared libraries are now - built by default on all Unix type hosts. - - Do site-specific build configuration - - Site configuration - To configure EPICS, you may want to modify the default definitions in - the following files: - - configure/CONFIG_SITE Build choices. Specify target archs. - configure/CONFIG_SITE_ENV Environment variable defaults - configure/RELEASE TORNADO2 full path location - - Host configuration - To configure each host system, you may override the default - definitions by adding a new file in the configure/os directory with - override definitions. The new file should have the same name as the - distribution file to be overridden except with CONFIG in the name - changed to CONFIG_SITE. - - configure/os/CONFIG.. Host build settings - configure/os/CONFIG..Common Host common build settings - - Target configuration - To configure each target system, you may override the default - definitions by adding a new file in the configure/os directory with - override definitions. The new file should have the same name as the - distribution file to be overridden except with CONFIG in the name - replaced by CONFIG_SITE. This step is necessary even if the host - system is the only target system. - - configure/os/CONFIG.Common. Target common settings - configure/os/CONFIG.. Host-target settings - - Build EPICS base - - After configuring the build you should be able to build EPICS base by - issuing the following commands in the distribution's root directory - (base): - - gnumake clean uninstall - gnumake - - The command "gnumake clean uninstall" will remove all files and - directories generated by a previous build. The command "gnumake" will - build and install everything for the configured host and targets. - - It is recommended that you do a "gnumake clean uninstall" at the root - directory of an EPICS directory structure before each complete rebuild - to ensure that all components will be rebuilt. - - Example application and extension - - A perl tool, makeBaseApp.pl is included in the distribution file. This - script will create a sample application that can be built and then - executed to try out this release of base. - - Instructions for building and executing the 3.15 example application can - be found in the section "Example Application" of Chapter 2, "Getting - Started", in the "IOC Application Developer's Guide" for this release. - The "Example IOC Application" section briefly explains how to create and - build an example application in a user created directory. It also - explains how to run the example application on a vxWorks ioc or as a - process on the host system. By running the example application as a - host-based IOC, you will be able to quickly implement a complete EPICS - system and be able to run channel access clients on the host system. - - A perl script, makeBaseExt.pl, is included in the distribution file. - This script will create a sample extension that can be built and - executed. The makeBaseApp.pl and makeBaseExt.pl scripts are installed - into the install location bin/ directory during the base - build. - - Multiple host platforms - - You can build using a single EPICS directory structure on multiple host - systems and for multiple cross target systems. The intermediate and - binary files generated by the build will be created in separate - subdirectories and installed into the appropriate separate host/target - install directories. EPICS executables and perl scripts are installed - into the $(INSTALL_LOCATION)/bin/ directories. Libraries are - installed into $(INSTALL_LOCATION)/lib/. The default definition - for $(INSTALL_LOCATION) is $(TOP) which is the root directory in the - distribution directory structure, base. Created object files are stored - in O. source subdirectories, This allows objects for multiple - cross target architectures to be maintained at the same time. To build - EPICS base for a specific host/target combination you must have the - proper host/target C/C++ cross compiler and target header files and the - base/configure/os directory must have the appropriate configure files. diff --git a/documentation/README.md b/documentation/README.md index 149b8fae9..444dd44cc 100644 --- a/documentation/README.md +++ b/documentation/README.md @@ -167,8 +167,7 @@ base/documentation directory of the distribution. #### base/documentation directory - contains setup, build, and install documents ``` - README.1st Instructions for setup and building epics base - README.html html version of README.1st + README.md Instructions for setup and building epics base README.darwin.html Installation notes for Mac OS X (Darwin) RELEASE_NOTES.html Notes on release changes KnownProblems.html List of known problems and workarounds From 03e613cec0f4090ad98c6cf0dd0cc5de77b5ad6a Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Mon, 21 Jan 2019 17:38:31 -0600 Subject: [PATCH 08/28] Adding POD to event and fanout records --- src/std/rec/{eventRecord.dbd => eventRecord.dbd.pod} | 0 src/std/rec/{fanoutRecord.dbd => fanoutRecord.dbd.pod} | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename src/std/rec/{eventRecord.dbd => eventRecord.dbd.pod} (100%) rename src/std/rec/{fanoutRecord.dbd => fanoutRecord.dbd.pod} (100%) diff --git a/src/std/rec/eventRecord.dbd b/src/std/rec/eventRecord.dbd.pod similarity index 100% rename from src/std/rec/eventRecord.dbd rename to src/std/rec/eventRecord.dbd.pod diff --git a/src/std/rec/fanoutRecord.dbd b/src/std/rec/fanoutRecord.dbd.pod similarity index 100% rename from src/std/rec/fanoutRecord.dbd rename to src/std/rec/fanoutRecord.dbd.pod From 86b188218687ccb147ba367ce4a148e17790ecec Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Thu, 29 Aug 2019 12:54:21 -0500 Subject: [PATCH 09/28] Updates to existing .dbd.pod texts, add event and fanout from wiki --- src/std/rec/aoRecord.dbd.pod | 14 +- src/std/rec/biRecord.dbd.pod | 66 +++++---- src/std/rec/boRecord.dbd.pod | 51 ++++--- src/std/rec/calcRecord.dbd.pod | 50 +++---- src/std/rec/calcoutRecord.dbd.pod | 82 +++++++---- src/std/rec/dfanoutRecord.dbd.pod | 5 - src/std/rec/eventRecord.dbd.pod | 225 +++++++++++++++++++++++++++++- src/std/rec/fanoutRecord.dbd.pod | 187 ++++++++++++++++++++++++- 8 files changed, 556 insertions(+), 124 deletions(-) diff --git a/src/std/rec/aoRecord.dbd.pod b/src/std/rec/aoRecord.dbd.pod index 41467dcd3..6aaf7d4b7 100644 --- a/src/std/rec/aoRecord.dbd.pod +++ b/src/std/rec/aoRecord.dbd.pod @@ -70,7 +70,7 @@ output value PVAL is added to it. =head4 Drive Limits The output value is now clipped to the range DRVL to DRVH inclusive, provided -that DRVH > DRVL. +that DRVH E DRVL. The result is copied into both the VAL and PVAL fields. =head4 Limit Rate of Change @@ -164,9 +164,7 @@ OUT field must specify the address of the I/O card. In addition, the DTYP field must contain the name of the device support module. Be aware that the address format differs according to the I/O bus used. See Address Specification for information on the format of hardware -addresses. The user can see a list of the device support modules -currently supported at the user's local site by using the dbst utility -in R3.13. +addresses. For soft records the output link can be a database link, a channel access link, or a constant value. If the link is a constant, no output @@ -593,7 +591,7 @@ terminated. For compatibility with old device supports that don't know EOFF, if both EOFF and ESLO have their default value, EOFF is set to EGUL. -If device support includes init_record, it is called. +If device support includes C, it is called. INIT is set TRUE. This causes PBRK, LBRK, and smoothing to be re-initialized. If "backwards" linear conversion is requested, then VAL @@ -620,10 +618,6 @@ called. INIT is set TRUE. This causes PBRK, LBRK, and smoothing to be re-initialized. -=item get_value - -Fills in the values of struct valueDes so that they refer to VAL. - =item get_alarm_double Sets the following values: @@ -903,7 +897,7 @@ OUT link type must be either a CONSTANT, DB_LINK, or CA_LINK. This module writes the current value of OVAL. If the OUT link type is PV_LINK, then dbCaAddInlink is called by -init_record. init_record always returns a value of 2, which means that +C. C always returns a value of 2, which means that no conversion will ever be attempted. write_ao calls recGblPutLinkValue to write the current value of VAL. diff --git a/src/std/rec/biRecord.dbd.pod b/src/std/rec/biRecord.dbd.pod index a711435ba..2d4cc0c51 100644 --- a/src/std/rec/biRecord.dbd.pod +++ b/src/std/rec/biRecord.dbd.pod @@ -69,9 +69,7 @@ If the binary input record gets its value from hardware, the address of the card must be entered in the INP field, and the name of the device support module must be entered in the DTYP field. See L
for information on the format of the hardware address. Be aware that the format -differs between types of cards. You can see a list of device support -modules currently supported at the user's local site by using C -utility (R3.13). +differs between types of cards. For records that specify C or C device support routines, the INP field can be a channel or a database link, or a @@ -94,18 +92,18 @@ the device support module reads a value directly into VAL or the C device support is used. The value can also be fetched as one of the strings specified in the ZNAM or ONAM fields. The ZNAM field has a string that corresponds to the 0 state, so when the value is fetched as -this string, C will return a 0. The ONAM field hold the +this string, C will return a 0. The ONAM field hold the string that corresponds to the 1 state, so when the value is fetched as -this string, C returns a 1. +this string, C returns a 1. =fields ZNAM, ONAM =head3 Operator Display Parameters These parameters are used to present meaningful data to the operator. The -C record support routine can retrieve the state string -corresponding to the VAL's state. If the value is 1, C will -return the string in the ONAM field; and if 0, C will return +C record support routine can retrieve the state string +corresponding to the VAL's state. If the value is 1, C will +return the string in the ONAM field; and if 0, C will return the ZNAM string. See L for more on the record name (NAME) @@ -149,7 +147,7 @@ The LALM fields holds the value of the last occurence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MAJOR or MINOR. -The MSLT field is used by the C record support routine to +The MSLT field is used by the C record support routine to determine if archive and value change monitors are invoked. They are if MSLT is not equal to VAL. @@ -276,16 +274,12 @@ This routine next checks to see that device support is available and a device support routine is defined. If neither exist, an error is issued and processing is terminated. -If device support includes C, it is called. +If device support includes C, it is called. =head2 C See next section. -=head2 C - -Fills in the values of struct valueDes so that they refer to VAL. - =head2 C Retrieves ASCII string corresponding to VAL. @@ -311,7 +305,7 @@ the PACT field still set to TRUE. This ensures that processes will no longer be called for this record. Thus error storms will not occur. =item 2. -C is called. See L for details. +C is called. See L for details. =item 3. If PACT has been changed to TRUE, the device support read routine has @@ -332,7 +326,7 @@ status = read_bi PACT = TRUE =item * -TIME = tslocaltime +C is called. =item * if status is 0, then set VAL=(0,1) if RVAL is (0, not 0) and UDF = False. @@ -383,7 +377,7 @@ Scan forward link if necessary, set PACT FALSE, and return. Each binary input record must have an associated set of device support routines. The primary resposibility of the device support routines is to -obtain a new raw input value whenever C is called. The device +obtain a new raw input value whenever C is called. The device support routines are primarily interested in the following fields: =fields PACT, DPVT, UDF, NSEV, NSTA, VAL, INP, RVAL, MASK @@ -392,22 +386,32 @@ support routines are primarily interested in the following fields: Device support consists of the following routines: -=head2 C +=head4 long report(int level) -Not currently used. +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. -=head2 C +=head4 long init(int after) -This routine is called once during IOC initialization. +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. =head2 C This routine is optional. If provided, it is called by the record support -C routine. +C routine. =head2 C -This routine is called by the C system each time the record is +This routine is called by the ioEventScan system each time the record is added or deleted from an I/O event scan list. C has the value (0,1) if the record is being (added to, deleted from) and I/O event list. It must be provided for any device type that can use the ioEvent scanner. @@ -439,25 +443,25 @@ link type must be either CONSTANT, DB_LINK, or CA_LINK. =head3 Soft Channel -C always returns a value of 2, which means that no conversion is +C always returns a value of 2, which means that no conversion is performed. If the INP link type is CONSTANT, then the constant value is stored in VAL -by C, and the UDF is set to FALSE. VAL can be changed via -C requests. If the INP link type is PV_LINK, the C is -called by C. +by C, and the UDF is set to FALSE. VAL can be changed via +C requests. If the INP link type is PV_LINK, the C is +called by C. -C calls C to read the current value of VAL. +C calls C to read the current value of VAL. See L for details. -If the return status of C is zero, then C sets -UDF to FALSE. The status of C is returned. +If the return status of C is zero, then C sets +UDF to FALSE. The status of C is returned. =head3 Raw Soft Channel This module is like the previous except that values are read into RVAL. -C returns a value of 0. Thus the record processing routine will +C returns a value of 0. Thus the record processing routine will force VAL to be 0 or 1. =cut diff --git a/src/std/rec/boRecord.dbd.pod b/src/std/rec/boRecord.dbd.pod index cbeee1abf..8d29bcf92 100644 --- a/src/std/rec/boRecord.dbd.pod +++ b/src/std/rec/boRecord.dbd.pod @@ -130,8 +130,7 @@ It must specify the address of an I/O card if the record sends its output to hardware, and the DTYP field must contain the corresponding device support module. Be aware that the address format differs according to the I/O bus used. See L
for information on the format of -hardware addresses. You can see a list of device support modules currently -supported at the user's local site by using the C utility in R3.13. +hardware addresses. Otherwise, if the record is configured to use the soft device support modules, then it can be either a database link, a channel access link, or a @@ -143,9 +142,9 @@ this chapter for more on output to other records. =head3 Operator Display Parameters These parameters are used to present meaningful data to the operator, The -C record support routine can retrieve the state string -corresponding to the VAL's state. So, if the value is 1, C -will return the string in the ONAM field: and if 0, C will +C record support routine can retrieve the state string +corresponding to the VAL's state. So, if the value is 1, C +will return the string in the ONAM field: and if 0, C will return the ZNAM string. See L for more on the record name (NAME) @@ -194,7 +193,7 @@ The LALM field holds the value of the last occurrence of the change of state alarm. It is used to implement the change of state alarm, and thus only has meaning if COSV is MINOR or MAJOR. -The MLST is used by the C record support routine to determine if +The MLST is used by the C record support routine to determine if archive and value change monitors are invoked. They are if MLST is not equal to VAL. @@ -373,17 +372,13 @@ exist, and error message is issued and processing is terminated. If DOL is a constant, then VAL is initialized to 1 if its value is nonzero or initialzed to 0 if DOL is zero, and UDF is set to FALSE. -If device support includes C, it is called. VAL is set using +If device support includes C, it is called. VAL is set using RVAL, and UDF is set to FALSE. =head2 C See next section. -=head2 C - -Fills in the values of struct valueDes so that they refer to VAL. - =head2 C Retrieves ASCII string corresponding to VAL. @@ -416,7 +411,7 @@ If PACT is FALSE =over =item * -If DOL is DB_LINK and OMSL is CLOSED_LOOP +If DOL holds a link and OMSL is C =over @@ -500,27 +495,37 @@ Scan forward link if necessary, set PACT FALSE, and return Each binary output record must have an associated set of device support routines. The primary responsibility of the device support routines is to -write a new value whenever C is called. The device support routines +write a new value whenever C is called. The device support routines are primarily interested in the following fields: =fields PACT, DPVT, NSEV, NSTA, VAL, OUT, RVAL, MASK, RBV -=head3 Decive Support Routines +=head3 Device Support Routines Device support consists of the following routines: -=head2 C +=head4 long report(int level) -Not currently used. +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. -=head2 C +=head4 long init(int after) -This routine is called once during IOC initialization. +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. =head2 C This routine is optional. If provided, it is called by record support -C routine. It should determine MASK if it is needed. +C routine. It should determine MASK if it is needed. =over @@ -566,10 +571,10 @@ link type must be either CONSTANT, DB_LINK, or CA_LINK. This module writes the current value of VAL. -If the OUT link type is PV_LINK, then C is called by -C. C always returns a value of 2, which means -that no conversion will ever be attempted. C calls -C to write the current value of VAL. See L +If the OUT link type is PV_LINK, then C is called by +C. C always returns a value of 2, which means +that no conversion will ever be attempted. C calls +C to write the current value of VAL. See L for details. =head3 Raw Soft Channel diff --git a/src/std/rec/calcRecord.dbd.pod b/src/std/rec/calcRecord.dbd.pod index c50667fb3..243c81eee 100644 --- a/src/std/rec/calcRecord.dbd.pod +++ b/src/std/rec/calcRecord.dbd.pod @@ -261,22 +261,22 @@ ATAN: Arc tangent =over 1 =item * ->= : Greater than or equal to +C<<< >= >>> : Greater than or equal to =item * -> : Greater than +C<<< > >>> : Greater than =item * -<= : Less than or equal to +C<<< <= >>> : Less than or equal to =item * -< : Less than +C<<< < >>> : Less than =item * -# : Not equal to +C<<< # >>> : Not equal to =item * -= : Equal to +C<<< = >>> : Equal to =back @@ -285,13 +285,13 @@ ATAN: Arc tangent =over 1 =item * -&& : And +C<&&> : And =item * -|| : Or +C<||> : Or =item * -! : Not +C : Not =back @@ -300,10 +300,10 @@ ATAN: Arc tangent =over 1 =item * -| : Bitwise Or +C<|> : Bitwise Or =item * -& : Bitwise And +C<&> : Bitwise And =item * OR : Bitwise Or @@ -315,13 +315,13 @@ AND : Bitwise And XOR : Bitwise Exclusive Or =item * -~ : One's Complement +C<~> : One's Complement =item * -<< : Left shift +C<<< << >>> : Left shift =item * ->> : Right shift +C<<< >> >>> : Right shift =back @@ -330,7 +330,7 @@ XOR : Bitwise Exclusive Or =over 1 =item * -:= : assigns a value (right hand side) to a variable (i.e. field) +C<:=> : assigns a value (right hand side) to a variable (i.e. field) =back @@ -360,35 +360,35 @@ C =over 1 =item * -Result is A + B + 10 +Result is C =back =head3 Relational -C<(A + B) < (C + D)> +C<<< (A + B) < (C + D) >>> =over 1 =item * -Result is 1 if (A + B) < (C + D) +Result is 1 if C<<< (A + B) < (C + D) >>> =item * -Result is 0 if (A + B) >= (C + D) +Result is 0 if C<<< (A + B) >= (C + D) >>> =back =head3 Question Mark -C<(A + B) < (C + D) ? E : F + L + 10> +C<<< (A + B) < (C + D) ? E : F + L + 10 >>> =over 1 =item * -Result is E if (A + B) < (C + D) +Result is C if C<<< (A + B) < (C + D) >>> =item * -Result is F + L + 10 if (A + B) >= (C + D) +Result is C if C<<< (A + B) >= (C + D) >>> =back @@ -412,7 +412,7 @@ C<(A + B) < (C + D) ? E : VAL> =head3 Logical -C +C =over 1 @@ -851,10 +851,6 @@ See next section. This is called if CALC is changed. C calls postfix. -=head2 C - -Fills in the values of struct valueDes so that the refer to VAL. - =head2 C Retrieves EGU. diff --git a/src/std/rec/calcoutRecord.dbd.pod b/src/std/rec/calcoutRecord.dbd.pod index 6289f9043..176f1d25f 100644 --- a/src/std/rec/calcoutRecord.dbd.pod +++ b/src/std/rec/calcoutRecord.dbd.pod @@ -293,22 +293,22 @@ ATAN: Arc tangent =over 1 =item * ->= : Greater than or equal to +C<<< >= >>> : Greater than or equal to =item * -> : Greater than +C<<< > >>> : Greater than =item * -<= : Less than or equal to +C<<< <= >>> : Less than or equal to =item * -< : Less than +C<<< < >>> : Less than =item * -# : Not equal to +C<<< # >>> : Not equal to =item * -= : Equal to +C<<< = >>> : Equal to =back @@ -332,10 +332,10 @@ ATAN: Arc tangent =over 1 =item * -| : Bitwise Or +C<|> : Bitwise Or =item * -& : Bitwise And +C<&> : Bitwise And =item * OR : Bitwise Or @@ -347,13 +347,13 @@ AND : Bitwise And XOR : Bitwise Exclusive Or =item * -~ : One's Complement +C<~> : One's Complement =item * -<< : Left shift +C<<< << >>> : Left shift =item * ->> : Right shift +C<<< >> >>> : Right shift =back @@ -362,11 +362,11 @@ XOR : Bitwise Exclusive Or =over 1 =item * -:= : assigns a value (right hand side) to a variable (i.e. field) +C<:=> : assigns a value (right hand side) to a variable (i.e. field) =back -=head3 Parentheses and Comma +=head3 Parantheses, Comma, and Semicolon The open and close parentheses are supported. Nested parentheses are supported. @@ -374,6 +374,10 @@ supported. The comma is supported when used to separate the arguments of a binary function. +The semicolon is used to separate expressions. Although only one +traditional calculation expression is allowed, multiple assignment +expressions are allowed. + =head3 Conditional Expression The C language's question mark operator is supported. The format is: @@ -388,41 +392,59 @@ C =over 1 =item * -Result is A + B + 10 +Result is C =back =head3 Relational -C<(A + B) < (C + D)> +C<<< (A + B) < (C + D) >>> =over 1 =item * -Result is 1 if (A + B) < (C + D) +Result is 1 if C<<< (A + B) < (C + D) >>> =item * -Result is 0 if (A + B) >= (C + D) +Result is 0 if C<<< (A + B) >= (C + D) >>> =back =head3 Question Mark -C<(A + B) < (C + D) ? E : F + L + 10> +C<<< (A + B) < (C + D) ? E : F + L + 10 >>> =over 1 =item * -Result is E if (A + B) < (C + D) +Result is C if C<<< (A + B) < (C + D) >>> =item * -Result is F + L + 10 if (A + B) >= (C + D) +Result is C if C<<< (A + B) >= (C + D) >>> + +=back + +Prior to Base 3.14.9 it was legal to omit the : and the second (else) part +of the conditional, like this: + +C<(A + B)<(C + D) ? E> + +=over 1 + +=item +Result is E if (A + B)<(C + D) + +=item +Result is unchanged if (A + B)>=(C + D) + +From 3.14.9 onwards, this expresion must be written as +C<(A + B) < (C + D) ? E : VAL> =back =head3 Logical -C +C =over 1 @@ -447,6 +469,18 @@ Convert result to floating point =back +=head3 Assignment + +C + +=over 1 + +=item * +Causes the Calc record to output the successive values of a sine curve in +1 degree intervals. + +=back + =head3 Output Parameters These parameters specify and control the output capabilities of the Calcout @@ -529,7 +563,7 @@ are also meant to represent the status of the record at run-time. The EGU field contains a string of up to 16 characters which is supplied by the user and which describes the values being operated upon. The string is -retrieved whenever the routine C is called. The EGU string is +retrieved whenever the routine C is called. The EGU string is solely for an operator's sake and does not have to be used. The HOPR and LOPR fields on;y refer to the limits if the VAL, HIHI, HIGH, @@ -1146,10 +1180,6 @@ See next section. This is called id CALC or OCAL is changed. C calls postfix. -=head2 C - -Fills in the values of struct valueDes so that they refer to VAL. - =head2 C Retrieves EGU. diff --git a/src/std/rec/dfanoutRecord.dbd.pod b/src/std/rec/dfanoutRecord.dbd.pod index 0d0487666..790abdffe 100644 --- a/src/std/rec/dfanoutRecord.dbd.pod +++ b/src/std/rec/dfanoutRecord.dbd.pod @@ -379,11 +379,6 @@ and the DOL link, a non-zero value is returned if an error occurs. See next section. -=head2 C - -This routine fills in the members of C with the VAL fields -value and characteristics. - =head2 C The routine copies the string specified in the EGU field to the location diff --git a/src/std/rec/eventRecord.dbd.pod b/src/std/rec/eventRecord.dbd.pod index 348902e4b..0d512da22 100644 --- a/src/std/rec/eventRecord.dbd.pod +++ b/src/std/rec/eventRecord.dbd.pod @@ -6,8 +6,63 @@ # EPICS BASE is distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=title Event Record (event) + +The normal use for this record type is to post an event and/or process a +forward link. Device support for this record can provide a hardware interrupt +handler routine for I/O Event-scanned records. + +=head2 Parameter Fields + +The records in this field fall into the following groups of parameters: + +=over + +=item * + +scan parameters + +=item * + +read parameters + +=item * + +event number parameters + +=item * + +simulation mode parameters + +=back + +=recordtype event + +=cut + recordtype(event) { - include "dbCommon.dbd" + include "dbCommon.dbd" + +=head3 Scan Parameters + +The event record has the standard fields for specifying under what circumstances +it will be processed. If the SCAN field specifies C, then device +support will provide an interrupt handler, posting an event number when an I/O +interrupt occurs. These fields are listed in L. In addition, +L explains how the scanning fields work. Note that I/O +event scanning is only supported for those card types that interrupt. + +=head3 Event Number Parameters + +The VAL field contains the event number read by the device support routines. It +is this number which is posted. For records that use C device +support, it can be configured before run-time or set via dbPuts. + +=fields VAL + +=cut + field(VAL,DBF_STRING) { prompt("Event Name To Post") promptgroup("40 - Input") @@ -22,11 +77,52 @@ recordtype(event) { interest(4) extra("EVENTPVT epvt") } + +=head3 Input Specification + +The device support routines use the address in this record to obtain input. For +records that provide an interrupt handler, the INP field should specify the +address of the I/O card, and the DTYP field should specify a valid device +support module. Be aware that the address format differs according to the card +type used. See L
for information on the format of +hardware addresses and specifying links. + +For soft records, the INP field can be a constant, a database link, or a channel +access link. For soft records, the DTYP field should specify C. + +=fields INP, DTYP + +=cut + field(INP,DBF_INLINK) { prompt("Input Specification") promptgroup("40 - Input") interest(1) } + +=head3 Operator Display Parameters + +See L for more on the record name (NAME) and +description (DESC) fields. + +=fields NAME, DESC + +=head3 Alarm Parameters + +The Event record has the alarm parameters common to all record types. L lists other fields related to alarms that are common to all record +types. + +=head3 Simulation Mode Parameters + +The following fields are used to operate the event record in the simulation +mode. See L for more information on these +fields. + +=fields SIOL, SVAL, SIML, SIMM, SIMS + +=cut + field(SIOL,DBF_INLINK) { prompt("Sim Input Specifctn") promptgroup("90 - Simulate") @@ -52,4 +148,131 @@ recordtype(event) { interest(2) menu(menuAlarmSevr) } + +=head2 Record Support + +=head3 Record Support Routines + +=head4 init_record + +This routine initializes SIMM with the value of SIML if SIML type is a CONSTANT +link or creates a channel access link if SIML type is PV_LINK. SVAL is likewise +initialized if SIOL is CONSTANT or PV_LINK. + +If device support includes C, it is called. + +=head4 process + +See next section. + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +readValue is called. See L for more information. + +=item 2. + +If PACT has been changed to TRUE, the device support read routine has started +but has not completed reading a new input value. In this case, the processing +routine merely returns, leaving PACT TRUE. + +=item 3. + +If VAL E 0, post event number VAL. + +=item 4. + +Check to see if monitors should be invoked. Alarm monitors are invoked if the +alarm status or severity has chanet to 0. + +=item 5. + +Scan forward link if necessary, set PACT FALSE, and return. + +=back + +=head2 Device Support + +=head3 Fields of Interest To Device Support + +Each record must have an associated set of device support routines. The device +support routines are primarily interested in the following fields: + +=fields PACT, DPVT, UDF, NSEV, NSTA, INP, PRIO + +=head3 Device Support Routines + +Device support consists of the following routines: + +=head4 long report(int level) + +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. + +=head4 long init(int after) + +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. + +=head4 init_record + + init_record(precord) + +This routine is optional. If provided, it is called by the record support +C routine. + +=head4 get_ioint_info + + get_ioint_info(int cmd, struct dbCommon *precord, IOSCANPVT *ppvt) + +This routine is called by the ioEventScan system each time the record is added +or deleted from an I/O event scan list. cmd has the value (0,1) if the record is +being (added to, deleted from) an I/O event list. It must be provided for any +device type that can use the ioEvent scanner. + +=head4 read_event + + read_event(precord) + +This routine returns the following values: + +=over + +=item * + +0: Success. + +=item * + +Other: Error. + +=back + +=head3 Device Support For Soft Records + +The C device support module is available. The INP link type must +be either CONSTANT, DB_LINK, or CA_LINK. + +If the INP link type is CONSTANT, then the constant value is stored into VAL by +C, and UDF is set to FALSE. If the INP link type is PV_LINK, then +dbCaAddInlink is called by C. + +C calls recGblGetLinkValue to read the current value of VAL. See +L for details on soft input. + +=cut + } diff --git a/src/std/rec/fanoutRecord.dbd.pod b/src/std/rec/fanoutRecord.dbd.pod index 251d63a11..11a9ad32e 100644 --- a/src/std/rec/fanoutRecord.dbd.pod +++ b/src/std/rec/fanoutRecord.dbd.pod @@ -6,13 +6,121 @@ # EPICS BASE is distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=title Fanout Record (fanout) + +The fanout record uses several forward processing links to force multiple +passive records to scan. When more than one record needs to be scanned as the +result of a record being processed, the forward link of that record can specify +a fanout record. The fanout record can specify up to sixteen other records to +process. If more than sixteen are needed, one of the forward links in the fanout +record (or its FLNK field) can point to another fanout record. + +B The dfanout or +data fanout record can, on the other hand, send data to other records. + +=head2 Parameter Fields + +The fanout record's fields fall into the following categories: + +=over + +=item * + +scan parameters + +=item * + +operator display parameters + +=item * + +run-time parameters. + +=back + +=recordtype fanout + +=cut + menu(fanoutSELM) { choice(fanoutSELM_All,"All") choice(fanoutSELM_Specified,"Specified") choice(fanoutSELM_Mask,"Mask") } + recordtype(fanout) { - include "dbCommon.dbd" + include "dbCommon.dbd" + +=head3 Scan Parameters + +The forward link fields of the fanout record (LNK0-LNK9, LNKA-LNKF) specify +records to be scanned. The records to be processed must specify C in +their SCAN fields; otherwise the forward link will not cause them to process. +Also when specifying database links for the fanout record, the user needs only +to specify the record name. As no value is being sent or retrieved, a field name +is only required when the link will be over Channel Access, in which case the +field PROC must be named. + +The SELM, SELN, and SELL fields specify the order of processing for the forward +links. The select mechanism menu field (SELM) has three choices: + +=menu fanoutSELM + +How the SELM value affects which links to process and in which order is as +follows: + +=over + +=item * + +B +Links are processed in numerical order - LNK0, LNK1, etc. + +=item * + +B The sum of the values in the SELN and OFFS fields is used as the +specifier of which link to process. For instance, with OFFS=0 and SELN=1, the +record targeted by LNK1 will be processed. + +=item * + +B The individual bits in SELN are shifted by SHFT bits (negative means +shift left) and the result used to select which links to process as follows: + +=over + +=item * + +If bit 0 (LSB) is set, LNK0 is processed. + +=item * + +If bit 1 is set, LNK2 is processed. + +=item * + +If bit 2 is set, LNK3 is processed, etc. + +=back + +=back + +SELN reads its value from SELL. SELL can be a constant, a database link, or a +channel access link. If a constant, SELN is initialized with the constant value +and can be changed via dbPuts. For database/channel access links, SELN is +retrieved from SELL each time the record is processed and can also be changed +via dbPuts. + +The Fanout record also has the standard scanning fields common to all records. +These fields are listed in L. In addition, +L explains in more detail how forward links and the +scanning algorithms work. + +=fields SELM, SELN, SELL, OFFS, SHFT, LNK0, LNK1, LNK2, LNK3, LNK4, LNK5, LNK6, LNK7, LNK8, LNK9, LNKA, LNKB, LNKC, LNKD, LNKE, LNKF + +=cut + field(VAL,DBF_LONG) { prompt("Used to trigger") asl(ASL0) @@ -126,4 +234,81 @@ recordtype(fanout) { promptgroup("52 - Output 8-F") interest(1) } + +=head3 Operator Display Parameters + +These parameters are used to present meaningful data to the operator. See +L for more on these fields. + +=fields NAME, DESC + +=head3 Alarm Parameters + +The Fanout record has the alarm parameters common to all record types. +L lists other fields related to a alarms that are common to all +record types. + +=head3 Run-time Parameters + +The VAL field performs no specific function, but a Channel Access put to it will +cause the record to process. + +=fields VAL + +=head2 Record Support + +=head3 Record Support Routines + +=head4 init_record + +This routine initializes SELN with the value of SELL, if SELL type is CONSTANT +link, or creates a channel access link if SELL type is PV_LINK. + +=head4 process + +See next section. + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +PACT is set to TRUE. + +=item 2. + +The link selection SELN is fetched. + +=item 3. + +Depending on the selection mechanism, the link selection forward links are +processed, and UDF is set to FALSE. + +=item 4. + +Check to see if monitors should be invoked: + +=over + +=item * + +Alarm monitors are invoked if the alarm status or severity has changed. + +=item * + +NSEV and NSTA are reset to 0. + +=back + +=item 5. + +Scan forward link field FLNK if used, set PACT FALSE, and return. + +=back + +=cut + } From 623539c3e8be539f8dc2a1dfa65b97768f72cac1 Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Fri, 6 Sep 2019 10:14:39 +0200 Subject: [PATCH 10/28] Add redefinition guard to menu-generated typedefs --- src/tools/DBD/Menu.pm | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/tools/DBD/Menu.pm b/src/tools/DBD/Menu.pm index 9c93c6d50..959536eaa 100644 --- a/src/tools/DBD/Menu.pm +++ b/src/tools/DBD/Menu.pm @@ -59,14 +59,17 @@ sub equals { sub toDeclaration { my $this = shift; my $name = $this->name; + my $macro_name = "${name}_NUM_CHOICES"; my @choices = map { sprintf " %-31s /* %s */", @{$_}[0], escapeCcomment(@{$_}[1]); } $this->choices; my $num = scalar @choices; - return "typedef enum {\n" . + return "#ifndef $macro_name\n" . + "typedef enum {\n" . join(",\n", @choices) . "\n} $name;\n" . - "#define ${name}_NUM_CHOICES $num\n\n"; + "#define $macro_name $num\n" . + "#endif\n\n"; } sub toDefinition { From 89e3c582b5f8579f4550db0def54fc07af10c8df Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Fri, 6 Sep 2019 10:44:02 +0200 Subject: [PATCH 11/28] Fix menu declaration test too --- src/tools/test/Menu.plt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/tools/test/Menu.plt b/src/tools/test/Menu.plt index c68ba9a85..0dd3a5c79 100644 --- a/src/tools/test/Menu.plt +++ b/src/tools/test/Menu.plt @@ -24,9 +24,11 @@ ok !$menu->legal_choice('Choice 3'), 'Third choice not legal'; is_deeply $menu->choice(2), undef, 'Third choice undefined'; like $menu->toDeclaration, qr/ ^ + \s* \# \s* ifndef \s+ test_NUM_CHOICES \s* \n \s* typedef \s+ enum \s+ \{ \s* \n \s* ch1 \s+ \/\* [^*]* \*\/, \s* \n \s* ch2 \s+ \/\* [^*]* \*\/ \s* \n \s* \} \s* test \s* ; \s* \n \s* \# \s* define \s+ test_NUM_CHOICES \s+ 2 \s* \n + \s* \# \s* endif \s* \n \s* $ /x, 'C declaration'; From 83458421aaab1405e16b514c573330a138291580 Mon Sep 17 00:00:00 2001 From: Joao Paulo Martins Date: Fri, 6 Sep 2019 11:20:11 +0200 Subject: [PATCH 12/28] Rename seqRecord.dbd seqRecord.dbd.pod --- src/std/rec/{seqRecord.dbd => seqRecord.dbd.pod} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/std/rec/{seqRecord.dbd => seqRecord.dbd.pod} (100%) diff --git a/src/std/rec/seqRecord.dbd b/src/std/rec/seqRecord.dbd.pod similarity index 100% rename from src/std/rec/seqRecord.dbd rename to src/std/rec/seqRecord.dbd.pod From b93f92c8432756a12aa5c716ea143b220c260cb4 Mon Sep 17 00:00:00 2001 From: Joao Paulo Martins Date: Fri, 6 Sep 2019 11:26:39 +0200 Subject: [PATCH 13/28] Add POD annotations to seqRecord from Wiki --- src/std/rec/seqRecord.dbd.pod | 282 ++++++++++++++++++++++++++++++++++ 1 file changed, 282 insertions(+) diff --git a/src/std/rec/seqRecord.dbd.pod b/src/std/rec/seqRecord.dbd.pod index 826f3ecf6..077d36107 100644 --- a/src/std/rec/seqRecord.dbd.pod +++ b/src/std/rec/seqRecord.dbd.pod @@ -6,12 +6,294 @@ # EPICS BASE is distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=title Sequence Record (seq) + +The Sequence record is used to trigger the processing of up to ten other records +and send values to those records. It is similar to the fanout record, except +that it will fetch an input value and write an output value instead of simply +processing a collection of forward links. It can also specify one of several +selection algorithms that determine which values to write. It has no associated +device support. + +=recordtype seq + +=cut + menu(seqSELM) { choice(seqSELM_All,"All") choice(seqSELM_Specified,"Specified") choice(seqSELM_Mask,"Mask") } + recordtype(seq) { + +=pod + +=head1 Contents + +=over + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=item * L + +=back + +=begin html + +

+ +=end html + +=head2 Parameter Fields + +The fields fall into the following categories: + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=head3 Scan Parameters + +The sequence record has the standard fields for specifying under what +circumstances it will be processed. These fields are listed in L. +In addition, L explains how these fields are used. + +=head3 Desired Output Parameters + +These fields determine where the record retrieves the values it is to write to +other records. All of these values are not necessarily used, depending on the +selection algorithm. + +The sequence record can retrieve up to 16 values from 16 locations. The user +specifies the locations in the Desired Output Link fields (DOL0-DOLF), which can +be either constants, database links, or channel access links. If a Desired +Output Link is a constant, the corresponding value field for that link is +initialized to the constant value and ''cannot'' be changed via dbputs. +Otherwise, if the Desired Output Link is a database or channel access link, a +value is fetched from the link each time the record is processed (provided that +the output link is part of the record's selection algorithm). See L
for information on how to specify database links. + +The value fetched from the Desired Output Links are stored in the corresponding +Desired Output Value fields (DO0-DOF). These fields can be initialized to a +constant value, but they cannot be changed via dbPuts. + +=head4 Desired Output Link Fields + +=fields DOL0, DOL1, DOL2, DOL3, DOL4, DOL5, DOL6, DOL7, DOL8, DOL9, DOLA, DOLB, DOLC, DOLD, DOLE, DOLF + +=head4 Desired Output Value Fields + +=fields DO0, DO1, DO2, DO3, DO4, DO5, DO6, DO7, DO8, DO9, DOA, DOB, DOC, DOD, DOE, DOF + +=head3 Output Parameters + +When the record is processed, the desired output values are retrieved for the +links in the record's selection algorithm and are written to the corresponding +output link (LNK0-LNKF). These output links can be database links or channel +access links; they cannot be device addresses. There are sixteen output links, one +for each desired output link. Only those that are defined are used. + +=fields LNK0, LNK1, LNK2, LNK3, LNK4, LNK5, LNK6, LNK7, LNK8, LNK9, LNKA, LNKB, LNKC, LNKD, LNKE, LNKF + +=head3 Selection Algorithm Parameters + +When the sequence record is processed, it uses a selection algorithm similar to +that of the selection record to decide which links to process.The select +mechanism field (SELM) has three algorithms to choose from: C<<< All >>>, +C<<>> or C<<< Mask >>>. + +=head4 Record fields related to the Selection Algorithm + +=fields SELM, SELN, SELL, SHFT, OFFS + +=head4 Fields Description + +B + +=menu seqSELM + +See L below; + +B + +This field can be initialized as a CONSTANT or as a LINK to any other record. SELN will fetch its value from this field when the seq record is processed. +Thus, when using I or I modes, the links that seq will process can be dinamically changed by the record pointed by SELL. + +B + +When B> this is the index number of the link that will be processed, used in combination with the C field: + + SELN = SELN + OFFS + + +I<(By default, the OFFS is initalized to ZERO)> + +When B> this field is the bitmask that will be used to determine which links will be processed by the seq record, +in combination with the C field: + + if (SHFT >= 0) + SELN = SELN << -SHFT + else + SELN = SELN >> SHFT + +I<(By default, the SHFT is initalized to -1)> + +=head4 B + +The first versions of seq record had DO, DOL, LNK and DLY fields starting with index ONE (DO1, DOL1, LNK1 and DLY1). +New version of the seq record now supports 16 links, starting by index ZERO (DO0, DOL0, LNK0 and DLY0). The SHFT and OFFS fields +were introduced to keep compatibility of old databases that used seq record with its links indexed from one onwards. + +B + +=head4 Selection Algorithms Description + +B + +The C<<< All >>> algorithm causes the record to process each input and output +link each time the record is processed, in order from 0 to 15. So when SELM is +C<<< All >>>, the desired output value from DOL0 will fetched and sent to LNK0, +then the desired output value from DOL1 will be fetched and sent to the location +in LNK1, and so on until the last input and output link DOF and LNKF. (Note that +undefined links are not used.) If DOLI is a constant, the current value +field is simply used and the desired output link is ignored. The SELN field is +not used when C<<< All >>> is the algorithm. + +B + +When the C<<< Specified >>> algorithm is chosen, each time the record is +processed it gets the integer value in the Link Selection (SELN) field and uses +that as the index of the link to process. For instance, if SELN is 4, the +desired output value from DO4 will be retrieved and sent to LNK4. If DOLI is +a constant, DOI is simply used without the value being fetched from the +input link. + +B + +When C<<< Mask >>> is chosen, the record uses the individual bits of the SELN +field to determine the links to process. When bit 0 of SELN is set, the value +from DO0 will be written to the location in LNK0; when bit 1 is set, the valud +from DO1 will be written to the location in LNK1 etc. Thus for example if SELN +is 3, the record will retrieve the values from DO0 and DO1 and write them to the +locations in LNK0 and LNK1, respectively. If SELN is 63, DO0...DO5 will be +written to LNK0...LNK5. + + +=head3 Delay Parameters + +The delay parameters consist of 16 fields, one for each I/O link discussed +above. These fields can be configured to cause the record to delay processing +the link. For instance, if the user gives the DLY1 field a value of 3.0, each +time the record is processed at run-time, the record will delay processing the +DOL1, DOV1, and LNK1 fields for three seconds. That is, the desired output value +will not be fetched and written to the output link until three seconds have +lapsed. + +=fields DLY0, DLY1, DLY2, DLY3, DLY4, DLY5, DLY6, DLY7, DLY8, DLY9, DLYA, DLYB, DLYC, DLYD, DLYE, DLYF + +=head3 Operator Display Parameters + +These parameters are used to present meaningful data to the operator. The +Precision field (PREC) determines the decimal precision for the VAL field when +it is displayed. It is used when the C<<< get_precision >>> record routine is +called. + +See L for more on the record name (NAME) and +description (DESC) fields. + +=fields PREC, NAME, DESC + +=head3 Alarm Parameters + +The sequence record has the alarm parameters common to all record types. +L lists other fields related to a alarms that are common to all +record types. + +=head2 Record Support + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +First, PACT is set to TRUE, and the link selection is fetched. Depending on the +selection mechanism, the link selection output links are processed in order from +LNK0 to LNKF. When LNKI is processed, the corresponding DLYI value is +used to generate a delay via watchdog timer. + +=item 2. + +After DLYI seconds have expired, the input value is fetched from DOI (if +DOLI is constant) or DOLI (if DOLI is a database link or channel +access link) and written to LNKI. + +=item 3. + +When all links are completed, an asynchronous completion call back to dbProcess +is made (see the Application Developer's Guide for more information on +asynchronous processing.) + +=item 4. + +Then UDF is set to FALSE. + +=item 5. + +Monitors are checked. + +=item 6. + +The forward link is scanned, PACT is set FALSE, and the process routine returns. + +=back + +For the delay mechanism to operate properly, the record is processed +asynchronously. The only time the record will not be processed asynchronously is +when there are no non-NULL output links selected (i.e. when it has nothing to +do.) The processing of the links is done via callback tasks at the priority set +in the PRIO field in dbCommon (see the Application Developer's Guide for more +information on call + +=cut + include "dbCommon.dbd" field(VAL,DBF_LONG) { prompt("Used to trigger") From db6825f62ed90ac0cb83328a9992c661140e1afd Mon Sep 17 00:00:00 2001 From: Saeed Haghtalab Date: Fri, 6 Sep 2019 13:13:46 +0200 Subject: [PATCH 14/28] Rename selRecord.dbd selRecord.dbd.pod --- src/std/rec/{selRecord.dbd => selRecord.dbd.pod} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/std/rec/{selRecord.dbd => selRecord.dbd.pod} (100%) diff --git a/src/std/rec/selRecord.dbd b/src/std/rec/selRecord.dbd.pod similarity index 100% rename from src/std/rec/selRecord.dbd rename to src/std/rec/selRecord.dbd.pod From 44149c170e54999b32aa52109be26885c9173642 Mon Sep 17 00:00:00 2001 From: Saeed Haghtalab Date: Fri, 6 Sep 2019 13:14:48 +0200 Subject: [PATCH 15/28] Add POD annotations to selRecord from Wiki --- src/std/rec/selRecord.dbd.pod | 330 ++++++++++++++++++++++++++++++++++ 1 file changed, 330 insertions(+) diff --git a/src/std/rec/selRecord.dbd.pod b/src/std/rec/selRecord.dbd.pod index 724482704..6eb88942b 100644 --- a/src/std/rec/selRecord.dbd.pod +++ b/src/std/rec/selRecord.dbd.pod @@ -6,6 +6,64 @@ # EPICS BASE is distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=pod + +=head1 Select Record (sel) + +The select record computes a value based on input obtained from up to 12 +locations. The selection algorithm can be one of the following: C<<< Specified +>>>, C<<< High Signal >>>, C<<< Low Signal >>>, C<<< Median Signal >>>. Each +input can be a constant, a database link, or a channel access link. + +=head2 Contents + +=over + +=item * L + +=over + +=item * L + +=item * L + +=item * L for more information. + +=item 3. + +If PACT has been changed to TRUE, the device support read routine has started +but has not completed reading a new input value. In this case, the processing +routine merely returns, leaving PACT TRUE. + +=item 4. + +Check alarms. This routine checks to see if the new VAL causes the alarm status +and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the +alarm hysteresis factor (HYST). Thus the value must change by more than HYST +before the alarm status and severity is lowered. + +=item 5. + +Check to see if monitors should be invoked: + +=over + +=item * + +Alarm monitors are invoked if the alarm status or severity has changed. + +=item * + +Archive and value change monitors are invoked if ADEL and MDEL conditions are +met. + +=item * + +NSEV and NSTA are reset to 0. + +=back + +=item 6. + +Scan forward link if necessary, set PACT FALSE, and return. + +=back + +=begin html + +

+ +=end html + +=head2 Device Support + +=head3 Fields Of Interest To Device Support + +Each long input record must have an associated set of device support routines. +The primary responsibility of the device support routines is to obtain a new +input value whenever read_longin is called. The device support routines are +primarily interested in the following fields: + +=fields PACT, DPVT, UDF, NSEV, NSTA, VAL, INP + +=head3 Device Support Routines + +Device support consists of the following routines: + +=head4 long report(int level) + +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. + +=head4 long init(int after) + +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. + +=head4 init_record + + init_record(precord) + +This routine is optional. If provided, it is called by the record support +C routine. + +=head4 get_ioint_info + + get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt) + +This routine is called by the ioEventScan system each time the record is added +or deleted from an I/O event scan list. cmd has the value (0,1) if the +record is being (added to, deleted from) an I/O event list. It must be +provided for any device type that can use the ioEvent scanner. + +=head4 read_longin + + read_longin(precord) + +This routine must provide a new input value. It returns the following values: + +=over + +=item * + +0: Success. A new value is placed in VAL. + +=item * + +Other: Error. + +=back + +=head3 Device Support For Soft Records + +The C<<< Soft Channel >>> device support module places a value directly in VAL. + +If the INP link type is constant, then the constant value is stored into VAL by +C, and UDF is set to FALSE. If the INP link type is PV_LINK, then +dbCaAddInlink is called by C. + +C<<< read_longin >>> calls recGblGetLinkValue to read the current value of VAL. +See L for more information + +If the return status of C<<< recGblGetLinkValue >>> is zero then read_longin +sets UDF to FALSE. read_longin returns the status of C. + + +=cut + include "dbCommon.dbd" field(VAL,DBF_LONG) { prompt("Current value") From a3d0699b8490994260e115c9e79deefb89562624 Mon Sep 17 00:00:00 2001 From: Joao Paulo Martins Date: Fri, 6 Sep 2019 13:59:31 +0200 Subject: [PATCH 20/28] Rename longoutRecord.dbd longoutRecord.dbd.pod --- src/std/rec/{longoutRecord.dbd => longoutRecord.dbd.pod} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/std/rec/{longoutRecord.dbd => longoutRecord.dbd.pod} (100%) diff --git a/src/std/rec/longoutRecord.dbd b/src/std/rec/longoutRecord.dbd.pod similarity index 100% rename from src/std/rec/longoutRecord.dbd rename to src/std/rec/longoutRecord.dbd.pod From eac3d2719b0697a6b03b275b7bea661843d8bcd5 Mon Sep 17 00:00:00 2001 From: Joao Paulo Martins Date: Fri, 6 Sep 2019 14:00:17 +0200 Subject: [PATCH 21/28] Add POD annotations to longoutRecord from Wiki --- src/std/rec/longoutRecord.dbd.pod | 434 +++++++++++++++++++++++++++++- 1 file changed, 433 insertions(+), 1 deletion(-) diff --git a/src/std/rec/longoutRecord.dbd.pod b/src/std/rec/longoutRecord.dbd.pod index c3ba0b977..5d8dd9320 100644 --- a/src/std/rec/longoutRecord.dbd.pod +++ b/src/std/rec/longoutRecord.dbd.pod @@ -6,7 +6,149 @@ # EPICS BASE is distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=head1 B + +The normal use for the long output or "longout" record type is to store long +integer values of up to 32 bits and write them to hardware devices. The C<<< +Soft Channel >>> device support routine can also be used to write values to +other records via database or channel access links. The OUT field determines how +the record is used. The record supports alarm limits and graphics and control +limits. + +=head1 L + +=over + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=back + +=back + +=begin html + +

+ +=end html + +=recordtype longout + +=cut + recordtype(longout) { + +=head2 Parameter Fields + +The fields in this record fall into the following categories: + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=head3 Scan Parameters + +The longout record has the standard fields for specifying under what +circumstances it will be processed. These fields are listed in L. +In addition, L explains how these fields are used. Note +that I/O event scanning is only supported for those card types that +interrupt. + +=head3 Desired Output Parameters + +The record must specify where the desired output originates, i.e., the 32 bit +integer value it is to write. The output mode select (OMSL) field determines +whether the output originates from another record or from database access. When +set to C<<< closed_loop >>>, the desired output is retrieved from the link +specified in the desired output (DOL) field (which can specify either a database +or channel access link) and placed into the VAL field. When set to C<<< +supervisory >>>, the desired output can be written into the VAL field via dpPuts +at run-time. + +A third type of value for the DOL field is a constant in which case, when the +record is initialized, the VAL field will be initialized with this constant +value. + +The VAL field's value will be clipped within limits specified in the fields DRVH +and DRVL if these have been configured by the database designer: + + DRVL <= VAL <= DRVH + +Note: These limits are only enforced as long as DRVH E DRVL. If they are not +set or DRVH E= DRVL they will not be used. + +=fields DOL, OMSL, DRVH, DRVL, VAL + +=head3 Write Parameters + +The OUT link field determines where the record is to send its output. For +records that write values to hardware devices, the OUT output link field must +specify the address of the I/O card, and the DTYP field must specify the +name of the corresponding device support module. + +For soft records, the OUT output link can be a constant, a database link, or a +channel access link. If the link is a constant, the result is no output. The +DTYP field must then specify the C<<< Soft Channel >>> device support routine. + +See L
for information on the format of hardware addresses +and database links. + +=fields OUT, DTYP + +=cut + include "dbCommon.dbd" field(VAL,DBF_LONG) { prompt("Desired Output") @@ -30,6 +172,27 @@ recordtype(longout) { interest(1) menu(menuOmsl) } + +=head3 Operator Display Parameters + +These parameters are used to present meaningful data to the operator. They +display the value and other parameters of the long output either textually or +graphically. + +EGU is a string of up to 16 characters describing the units that the long output +measures. It is retrieved by the C<<< get_units >>> record support routine. + +The HOPR and LOPR fields set the upper and lower display limits for the VAL, +HIHI, HIGH, LOW, and LOLO fields. Both the C<<< get_graphic_double >>> and C<<< +get_control_double >>> record support routines retrieve these fields. + +See L for more on the record name (NAME) and +description (DESC) fields. + +=fields EGU, HOPR, LOPR, NAME, DESC + +=cut + field(EGU,DBF_STRING) { prompt("Engineering Units") promptgroup("80 - Display") @@ -63,6 +226,29 @@ recordtype(longout) { interest(1) prop(YES) } + +=head3 Alarm Parameters + +The possible alarm conditions for long inputs are the SCAN, READ, INVALID, and +limit alarms. The SCAN and READ alarms are not configurable by the user because +their severity is always MAJOR. The INVALID alarm is called by the record +support routine when the record or device support routines cannot write the +record's output. The IVOA field specifies the action to take in this case. + +The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW +fields using floating-point values. For each of these fields, there is a +corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The +HYST field contains the alarm deadband around each limit alarm. + +See the See L for a complete explanation of alarms and +these fields. For an explanation of the IVOA and IVOV fields, see L. L lists other fields related to a alarms that are common +to all record types. + +=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST, IVOA, IVOV + +=cut + field(HIHI,DBF_LONG) { prompt("Hihi Alarm Limit") promptgroup("70 - Alarm") @@ -124,6 +310,22 @@ recordtype(longout) { promptgroup("70 - Alarm") interest(1) } + +=head3 Monitor Parameters + +These parameters are used to determine when to send monitors placed on the value +field. The monitors are sent when the value field exceeds the last monitored +field by the appropriate delta. If these fields have a value of zero, everytime +the value changes, a monitor will be triggered; if they have a value of -1, +everytime the record is scanned, monitors are triggered. The ADEL field is the +delta for archive monitors, and the MDEL field is the delta for all other types +of monitors. See L for a complete explanation of +monitors. + +=fields ADEL, MDEL + +=cut + field(ADEL,DBF_LONG) { prompt("Archive Deadband") promptgroup("80 - Display") @@ -149,6 +351,25 @@ recordtype(longout) { special(SPC_NOMOD) interest(3) } + +=head3 Run-time and Simulation Mode Parameters + +The LALM, MLST, and ALST fields are used to implement the hysteresis factors for +monitor callbacks. Only if the difference between these fields and the +corresponding value field is greater than the appropriate delta (MDEL, ADEL, +HYST)--only then are monitors triggered. For instance, only if the difference +between VAL and MLST is greater than MDEL are the monitors triggered for VAL. + +=fields LALM, ALST, MLST + +The following fields are used to operate the long output in the simulation mode. +See L for more information on the simulation +mode fields + +=fields SIOL, SIML, SIMM, SIMS + +=cut + field(SIOL,DBF_OUTLINK) { prompt("Sim Output Specifctn") promptgroup("90 - Simulate") @@ -181,4 +402,215 @@ recordtype(longout) { promptgroup("50 - Output") interest(2) } -} + + +=begin html + +

+ +=end html + +=head2 Record Support + +=head3 Record Support Routines + +=head4 init_record + +This routine initializes SIMM if SIML is a constant or creates a channel access +link if SIML is PV_LINK. If SIOL is PV_LINK a channel access link is created. + +This routine next checks to see that device support is available. The routine +next checks to see if the device support write routine is defined. + +If either device support or the device support write routine does not exist, an +error message is issued and processing is terminated. + +If DOL is a constant, then VAL is initialized to its value and UDF is set to +FALSE. If DOL type is a PV_LINK then dbCaAddInlink is called to create a channel +access link. + +If device support includes C, it is called. + +=head4 process + +See next section. + +=head4 get_units + +Retrieves EGU. + +=head4 get_graphic_double + +Sets the upper display and lower display limits for a field. If the field is +VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the +field has upper and lower limits defined they will be used, else the upper and +lower maximum values for the field type will be used. + +=head4 get_control_double + +Sets the upper control and the lower control limits for a field. If the field is +VAL, HIHI, HIGH, LOW, or LOLO, the limits are set to HOPR and LOPR, else if the +field has upper and lower limits defined they will be used, else the upper and +lower maximum values for the field type will be used. + +=head4 get_alarm_double + +Sets the following values: + + upper_alarm_limit = HIHI + upper_warning_limit = HIGH + lower_warning_limit = LOW + lower_alarm_limit = LOLO + + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +Check to see that the appropriate device support module exists. If it doesn't, +an error message is issued and processing is terminated with the PACT field +still set to TRUE. This ensures that processes will no longer be called for this +record. Thus error storms will not occur. + +=item 2. + +If PACT is FALSE and OMSL is CLOSED_LOOP recGblGetLinkValue is called to read +the current value of VAL. See L for more information. If the +return status of recGblGetLinkValue is zero then UDF is set to FALSE. + +=item 3. + +Check alarms. This routine checks to see if the new VAL causes the alarm status +and severity to change. If so, NSEV, NSTA and LALM are set. It also honors the +alarm hysteresis factor (HYST). Thus the value must change by more than HYST +before the alarm status and severity is lowered. + +=item 4. + +Check severity and write the new value. See L for +information on how INVALID alarms affect output records. + +=item 5. + +If PACT has been changed to TRUE, the device support write output routine has +started but has not completed writing the new value. In this case, the +processing routine merely returns, leaving PACT TRUE. + +=item 6. + +Check to see if monitors should be invoked: + +=over + +=item * + +Alarm monitors are invoked if the alarm status or severity has changed. + +=item * + +Archive and value change monitors are invoked if ADEL and MDEL conditions are +met. + +=item * + +NSEV and NSTA are reset to 0. + +=back + +=item 7. + +Scan forward link if necessary, set PACT FALSE, and return. + +=back + +=begin html + +

+ +=end html + +=head2 Device Support + +=head3 Fields Of Interest To Device Support + +Each long output record must have an associated set of device support routines. +The primary responsibility of the device support routines is to output a new +value whenever write_longout is called. The device support routines are +primarily interested in the following fields: + +=fields PACT, DPVT, NSEV, NSTA, OUT + +=head3 Device Support Routines + +Device support consists of the following routines: + +=head4 long report(int level) + +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. + +=head4 long init(int after) + +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. + +=head4 init_record + + init_record(precord) + +This routine is optional. If provided, it is called by the record support +C routine. + +=head4 get_ioint_info + + get_ioint_info(int cmd,struct dbCommon *precord,IOSCANPVT *ppvt) + +This routine is called by the ioEventScan system each time the record is added +or deleted from an I/O event scan list. cmd has the value (0,1) if the +record is being (added to, deleted from) an I/O event list. It must be +provided for any device type that can use the ioEvent scanner. + +=head4 write_longout + + write_longout(precord) + +This routine must output a new value. It returns the following values: + +=over + +=item * + +0: Success. + +=item * + +Other: Error. + +=back + +=head3 Device Support For Soft Records + +The C<<< Soft Channel >>> module writes the current value of VAL. + +If the OUT link type is PV_LINK, then dbCaAddInlink is called by +C. + +write_longout calls recGblPutLinkValue to write the current value of VAL. + +See L for a further explanation. + +=cut + +} #end of the DBD file From 96e3e678e94a8e53e33c327a79097a9bfbdfe6ba Mon Sep 17 00:00:00 2001 From: Saeed Haghtalab Date: Fri, 6 Sep 2019 18:02:39 +0200 Subject: [PATCH 22/28] Rename subArrayRecord.dbd and menuAlarmStat.dbd to .pod --- src/ioc/db/{menuAlarmStat.dbd => menuAlarmStat.dbd.pod} | 0 src/std/rec/{subArrayRecord.dbd => subArrayRecord.dbd.pod} | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename src/ioc/db/{menuAlarmStat.dbd => menuAlarmStat.dbd.pod} (100%) rename src/std/rec/{subArrayRecord.dbd => subArrayRecord.dbd.pod} (100%) diff --git a/src/ioc/db/menuAlarmStat.dbd b/src/ioc/db/menuAlarmStat.dbd.pod similarity index 100% rename from src/ioc/db/menuAlarmStat.dbd rename to src/ioc/db/menuAlarmStat.dbd.pod diff --git a/src/std/rec/subArrayRecord.dbd b/src/std/rec/subArrayRecord.dbd.pod similarity index 100% rename from src/std/rec/subArrayRecord.dbd rename to src/std/rec/subArrayRecord.dbd.pod From f70c17ee69f495ff005bb674abcc1789e5736d7d Mon Sep 17 00:00:00 2001 From: Saeed Haghtalab Date: Fri, 6 Sep 2019 18:20:43 +0200 Subject: [PATCH 23/28] Add POD annotations from Wiki to subArrayRecord and menuAlarmStat --- src/ioc/db/menuAlarmStat.dbd.pod | 11 + src/std/rec/subArrayRecord.dbd.pod | 365 +++++++++++++++++++++++++++++ 2 files changed, 376 insertions(+) diff --git a/src/ioc/db/menuAlarmStat.dbd.pod b/src/ioc/db/menuAlarmStat.dbd.pod index e8d7f1ced..78debf8c5 100644 --- a/src/ioc/db/menuAlarmStat.dbd.pod +++ b/src/ioc/db/menuAlarmStat.dbd.pod @@ -7,6 +7,17 @@ # and higher are distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=head1 Menu menuAlarmStat + +This menu defines the possible alarm statuses that EPICS records can exhibit +which is used for C and C fields of all record types. +See L for more information. + +=menu menuAlarmStat + +=cut + menu(menuAlarmStat) { choice(menuAlarmStatNO_ALARM,"NO_ALARM") choice(menuAlarmStatREAD,"READ") diff --git a/src/std/rec/subArrayRecord.dbd.pod b/src/std/rec/subArrayRecord.dbd.pod index 7814a2e48..ac4454f6f 100644 --- a/src/std/rec/subArrayRecord.dbd.pod +++ b/src/std/rec/subArrayRecord.dbd.pod @@ -6,7 +6,372 @@ # EPICS BASE is distributed subject to a Software License Agreement found # in file LICENSE that is included with this distribution. #************************************************************************* + +=head1 Sub-Array Record (subArray) + +The normal use for the subArray record type is to obtain sub-arrays from +waveform records. Setting either the number of elements (NELM) or index (INDX) +fields causes the record to be processed anew so that applications in which the +length and position of a sub-array in a waveform record vary dynamically can be +implemented using standard EPICS operator interface tools. + +The first element of the sub-array, that at location INDX in the referenced +waveform record, can be displayed as a scalar, or the entire subarray (of length +NELM) can be displayed in the same way as a waveform record. If there are fewer +than NELM elements in the referenced waveform after the INDX, only the number of +elements actually available are returned, and the number of elements read field +(NORD) is set to reflect this. This record type does not support writing new +values into waveform records. + +=head2 Contents + +=over + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=item * L + +=back + +=item * L + +=over + +=item * L + +=item * L + +=item * L + +=back + +=back + +=begin html + +
+
+
+ +=end html + +=recordtype subArray + +=cut + recordtype(subArray) { + +=head2 Parameter Fields + +=head3 Scan Parameters + +The subArray record has the standard fields for specifying under what +circumstances the record will be processed. These fields are listed in +L. +In addition, +L +explains how these fields are used. + +=head3 Read Parameters + +The subArray's input link (INP) should be configured to reference the Waveform +record. It should specify the VAL field of a Waveform record. The INP field can +be a channel access link, in addition to a database link. See +L
+for information on specifying links. + +In addition, the DTYP field must specify a device support module. Currently, the +only device support module is C<<< Soft Channel >>>. + +=fields INP, DTYP + +=head3 Array Parameters + +These parameters determine the number of array elements (the array length) and +the data type of those elements. The Field Type of Value (FTVL) field determines +the data type of the array. + +The user specifies the maximum number of elements allowed in the subarray in the +MALM field. Generally, the number should be equal to the number of elements of +the Waveform array (found in the Waveform's NELM field). The MALM field is used +to allocate memory. The subArray's Number of Elements (NELM) field is where the +user specifies the actual number of elements that the subArray will contain. It +should of course be no greater than MALM; if it is, the record processing +routine sets it equal to MALM. + +The INDX field determines the offset of the subArray record's array in relation +to the Waveform's. For instance, if INDX is 2, then the subArray will read NELM +elements starting with the third element of the Waveform's array. Thus, it +equals the index number of the Waveform's array. + +The actual sub-array is referenced by the VAL field. + +=fields FTVL, VAL, MALM, NELM, INDX + +=head3 Operator Display Parameters + +These parameters are used to present meaningful data to the operator. They +display the value and other parameters of the subarray record either textually +or graphically. + +EGU is a string of up to 16 characters describing the engineering units (if any) +of the values which the subArray holds. It is retrieved by the C<<< get_units +>>> record support routine. + +The HOPR and LOPR fields set the upper and lower display limits for the +sub-array elements. Both the C<<< get_graphic_double >>> and C<<< +get_control_double >>> record support routines retrieve these fields. + +The PREC field determines the floating point precision with which to display +VAL. It is used whenever the C<<< get_precision >>> record support routine is +called. + +See L +for more on the record name (NAME) and description (DESC) fields. + +=fields EGU, HOPR, LOPR, PREC, NAME, DESC + +=head3 Alarm Parameters + +The subarray record has the alarm parameters common to all record types. +L lists other fields related to a alarms that are common to all +record types. + +=head3 Run-time Parameters + +These fields are not configurable by the user. They are used for the record's +internal processing or to represent the current state of the record. + +The NORD field holds a counter of the number of elements read into the array. It +can be less than NELM even after the array is full if NELM exceeds the number of +existing elements in the referenced array, i.e., the Waveform's array. + +BPTR contains a pointer to the record's array. + +=fields NORD, BPTR + +=begin html + +
+
+
+ +=end html + +=head2 Record Support + +=head3 Record Support Routines (subArrayRecord.c) + +=head4 init_record + + long (*init_record)(struct dbCommon *precord, int pass) + +Using MALM and FTVL, space for the array is allocated. The array address is +stored in BPTR. This routine checks to see that device support is available and +a device support read routine is defined. If either does not exist, an error +message is issued and processing is terminated. If device support includes +C, it is called. + +=head4 process + + long (*process)(struct dbCommon *precord) + +See L. + +=head4 cvt_dbaddr + + long (*cvt_dbaddr)(struct dbAddr *paddr) + +This is called by dbNameToAddr. It makes the dbAddr structure refer to the +actual buffer holding the result. + +=head4 get_array_info + + long (*get_array_info)(struct dbAddr *paddr, long *no_elements, long *offset) + +Retrieves NELM. + +=head4 put_array_info + + long (*put_array_info)(struct dbAddr *paddr, long nNew) + +Sets NORD. + +=head4 get_graphic_double + + long (*get_graphic_double)(struct dbAddr *paddr, struct dbr_grDouble *p) + +For the elements in the array, this routine routines HOPR and LOPR. For the INDX +field, this routine returns MALM - 1 and 0. For NELM, it returns MALM and 1. For +other fields, it calls C<<< recGblGetGraphicDouble() >>>. + +=head4 get_control_double + + long (*get_control_double)(struct dbAddr *paddr, struct dbr_ctrlDouble *p) + +For array elements, this routine retrieves HOPR and LOPR. Otherwise, C<<< +recGblGetControlDouble() >>> is called. + +=head4 get_units + + long (*get_units)(struct dbAddr *paddr, char *units) + +Retrieves EGU. + +=head4 get_precision + + long (*get_precision)(const struct dbAddr *paddr, long *precision) + +Retrieves PREC. + +=head3 Record Processing + +Routine process implements the following algorithm: + +=over + +=item 1. + +Check to see that the appropriate device support module exists. If it doesn't, +an error message is issued and processing is terminated with the PACT field +still set to TRUE. This ensures that processes will no longer be called for this +record. Thus error storms will not occur. + +=item 2. + +Sanity check NELM and INDX. If NELM is greater than MALM it is set to MALM. If +INDX is greater than or equal to MALM it is set to MALM-1. + +=item 3. + +Call device support read routine. This routine is expected to place the desired +sub-array at the beginning of the buffer and set NORD to the number of elements +of the sub-array that were read. + +=item 4. + +If PACT has been changed to TRUE, the device support read routine has started +but has not completed writing the new value. In this case, the processing +routine merely returns, leaving PACT TRUE. Otherwise, process sets PACT TRUE at +this time. This asynchronous processing logic is not currently used but has been +left in place. + +=item 5. + +Check to see if monitors should be invoked. + +=over + +=item * + +Alarm monitors are invoked if the alarm status or severity has changed. + +=item * + +Archive and value change monitors are always invoked. + +=item * + +NSEV and NSTA are reset to 0. + +=back + +=item 6. + +Scan forward link if necessary, set PACT FALSE, and return. + +=back + +=begin html + +
+
+
+ +=end html + +=head2 Device Support + +=head3 Fields Of Interest To Device Support + +The device support routines are primarily interested in the following fields: + +=fields PACT, DPVT, UDF, NSEV, NSTA, INP, FTVL, MALM, NELM, INDX, BPTR, NORD + +=head3 Device Support Routines (devSASoft.c) + +Device support consists of the following routines: + +=head4 long report(int level) + +This optional routine is called by the IOC command C and is passed the +report level that was requested by the user. +It should print a report on the state of the device support to stdout. +The C parameter may be used to output increasingly more detailed +information at higher levels, or to select different types of information with +different levels. +Level zero should print no more than a small summary. + +=head4 long init(int after) + +This optional routine is called twice at IOC initialization time. +The first call happens before any of the C calls are made, with +the integer parameter C set to 0. +The second call happens after all of the C calls have been made, +with C set to 1. + +=head4 init_record + + long init_record(subArrayRecord *prec) + +This routine is called by the record support C routine. + +=head4 read_sa + + long read_sa(subArrayRecord *prec) + +Enough of the source waveform is read into BPTR, from the beginning of the +source, to include the requested sub-array. The sub-array is then copied to the +beginning of the buffer. NORD is set to indicate how many elements of the +sub-array were acquired. + +=head3 Device Support For Soft Records + +Only the device support module C<<< Soft Channel >>> is currently provided. The +INP link type must be either DB_LINK or CA_LINK. + +=head4 Soft Channel + +INP is expected to point to a waveform record. + +=cut + include "dbCommon.dbd" field(VAL,DBF_NOACCESS) { prompt("Value") From 704e6251e6ba1d7a8f860cb4c868f869514c541d Mon Sep 17 00:00:00 2001 From: Andrew Johnson Date: Fri, 6 Sep 2019 18:33:55 +0200 Subject: [PATCH 24/28] Remove links to wiki-ext --- src/std/rec/compressRecord.dbd.pod | 35 +++++++++++++-------------- src/std/rec/selRecord.dbd.pod | 38 +++++++++++++----------------- src/std/rec/subRecord.dbd.pod | 28 +++++++++------------- 3 files changed, 44 insertions(+), 57 deletions(-) diff --git a/src/std/rec/compressRecord.dbd.pod b/src/std/rec/compressRecord.dbd.pod index f0a586baa..209e8d1f8 100644 --- a/src/std/rec/compressRecord.dbd.pod +++ b/src/std/rec/compressRecord.dbd.pod @@ -78,10 +78,9 @@ recordtype(compress) { =head3 Scanning Parameters The compression record has the standard fields for specifying under what -circumstances the record will be processed. These fields are listed in -L. In addition, -L -explains how these fields are used. Since the compression record supports no +circumstances the record will be processed. These fields are listed in +L. In addition, L +explains how these fields are used. Since the compression record supports no direct interfaces to hardware, its SCAN field cannot specify C<<< I/O Intr >>>. =head3 Algorithms and Related Parameters @@ -99,18 +98,17 @@ The following fields determine what channel to read and how to compress the data As stated above, the ALG field specifies which algorithm to be performed on the data. -The INP should be a database or channel access link. Though INP can be a constant, -the data compression algorithms are supported only when INP is a database link. See -L
-for information on specifying links. +The INP should be a database or channel access link. Though INP can be a constant, +the data compression algorithms are supported only when INP is a database link. See +L
for information on specifying links. IHIL and ILIL can be set to provide an initial value filter on the input array. -If ILIL E IHIL, the input elements will be skipped until a value is found -that is in the range of ILIL to IHIL. Note that ILIL and IHIL are used only in +If ILIL E IHIL, the input elements will be skipped until a value is found +that is in the range of ILIL to IHIL. Note that ILIL and IHIL are used only in C<<< N to 1 >>> algorithms. -OFF provides the offset to the current beginning of the array data. +OFF provides the offset to the current beginning of the array data. Note that OFF is used only in C<<< N to 1 >>> algorithms. The RES field can be accessed at run time to cause the algorithm to reset @@ -120,7 +118,7 @@ itself before the maximum number of samples are reached. B algorithm keeps a circular buffer of length NSAM. Each time the record is processed, it gets the data referenced by INP and puts -it into the circular buffer referenced by VAL. The INP can refer to both scalar or +it into the circular buffer referenced by VAL. The INP can refer to both scalar or array data and VAL is just a time ordered circular buffer of values obtained from INP. Note that N, ILIL, IHIL and OFF are not used in C<<< Circular Buffer >>> algorithm. @@ -144,7 +142,7 @@ shows the equation: B If any of the C<<< N to 1 >>> algorithms are chosen, then VAL is a circular buffer of NSAM samples. -The actual algorithm depends on whether INP references a scalar or an array. +The actual algorithm depends on whether INP references a scalar or an array. If INP refers to a scalar, then N successive time ordered samples of INP are taken. After the Nth sample is obtained, a new value determined by the algorithm @@ -201,21 +199,21 @@ graphically. The EGU field should be given a string that describes the value of VAL, but is used whenever the C<<< get_units >>> record support routine is called. -The HOPR and LOPR fields only specify the upper and lower display limits for +The HOPR and LOPR fields only specify the upper and lower display limits for VAL, HIHI, HIGH, LOLO and LOW fields. PREC controls the floating-point precision whenever C<<< get_precision >>> is called, and the field being referenced is the VAL field (i.e., one of the values contained in the circular buffer). -See L +See L for more on the record name (NAME) and description (DESC) fields. =head3 Alarm Parameters -The compression record has the alarm parameters common to all record types described in -L. +The compression record has the alarm parameters common to all record types +described in L. =head3 Run-time Parameters @@ -247,7 +245,7 @@ WPTR is used by the dbGetlinks routines. =head3 Record Support Routines (compressRecord.c) =head4 init_record - + long (*init_record)(struct dbCommon *precord, int pass) Space for all necessary arrays is allocated. The addresses are stored in the @@ -517,3 +515,4 @@ Scan forward link if necessary, set PACT FALSE, and return. interest(3) } } + diff --git a/src/std/rec/selRecord.dbd.pod b/src/std/rec/selRecord.dbd.pod index 6eb88942b..9e49745cc 100644 --- a/src/std/rec/selRecord.dbd.pod +++ b/src/std/rec/selRecord.dbd.pod @@ -77,10 +77,8 @@ recordtype(sel) { =head3 Scan Parameters The select record has the standard fields for specifying under what -circumstances the record will be processed. These fields are listed in -L. -In addition, -L +circumstances the record will be processed. These fields are listed in +L. In addition, L explains how these fields work. =head3 Read Parameters @@ -91,8 +89,7 @@ links configured by the user to be either constants, channel access links, or database links. If channel access or database links, a value is retrieved for each link and placed in the corresponding value field, A-L. If any input link is a constant, the value field for that link will be initialized with the constant -value given to it and can be modified via dbPuts. See -L
+value given to it and can be modified via dbPuts. See L
for information on how to specify database links. Any links not defined are ignored by the selection record and its algorithm. An @@ -111,24 +108,24 @@ The selection algorithm is determined by three fields configurable by the user: the select mechanism (SELM) field, the select number (SELN) field, and the index value location (NVL) field. -The SELM field has four choices, i.e., four algorithms as follows: +The SELM field has four choices, i.e., four algorithms as follows: =head4 Menu selSELM =menu selSELM -The selection record's VAL field is determined differently for each algorithm. -For C<<< Specified >>>, the VAL field is set equal to the value field (A, B, C, -D, E, F, G, H, I, J, K, or L) specified by the SELN field. The SELN field contains a +The selection record's VAL field is determined differently for each algorithm. +For C<<< Specified >>>, the VAL field is set equal to the value field (A, B, C, +D, E, F, G, H, I, J, K, or L) specified by the SELN field. The SELN field +contains a number from 0-11 which corresponds to the value field to be used (0 means use A; 1 means use B, etc.). How the NVL field is configured determines, in turn, SELN's value. NVL is an input link from which a value for SELN can be retrieved, Like most other input links NVL can be a constant, or a channel access or database link. If NVL is a link, SELN is retrieved from the location in NVL. If a constant, SELN is initialized to the value given to the constant and can be -changed via dbPuts. See -L
-for information on how to specify database links. +changed via dbPuts. See L
for information on how to +specify database links. The C<<< High Signal >>>, C<<< Low Signal >>>, and C<<< Median Signal >>> algorithms do not use SELN or NVL. If C<<< High Signal >>> is chosen, VAL is set @@ -160,9 +157,8 @@ The PREC field determines the floating point precision with which to display VAL. It is used whenever the C<<< get_precision >>> record support routine is called. -See -L -for more on the record name (NAME) and description (DESC) fields. +See L for more on the record name (NAME) +and description (DESC) fields. =fields EGU, HOPR, LOPR, PREC, NAME, DESC @@ -173,10 +169,8 @@ alarms. The SCAN and READ alarms are called by the record or device support routines. The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW fields using numerical values. They specify conditions for the VAL field. For each of these fields, there is a corresponding severity field which -can be either NO_ALARM, MINOR, or MAJOR. See -L -for a complete explanation of alarms and these fields. -L +can be either NO_ALARM, MINOR, or MAJOR. See L +for a complete explanation of alarms and these fields. L lists other fields related to a alarms that are common to all record types. =fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST @@ -188,8 +182,7 @@ archiver and monitor calls for the VAL field. Unless, VAL changes by more than the value specified by each, then the respective monitors will not be called. If these fields have a value of zero, everytime the VAL changes, monitors are triggered; if they have a value of -1, everytime the record is processed, -monitors are triggered. -L +monitors are triggered. L gives a complete explanation of alarms and deadbands. =fields ADEL, MDEL @@ -651,3 +644,4 @@ Scan forward link if necessary, set PACT FALSE, and return. interest(3) } } + diff --git a/src/std/rec/subRecord.dbd.pod b/src/std/rec/subRecord.dbd.pod index c5027284c..1e2f25dde 100644 --- a/src/std/rec/subRecord.dbd.pod +++ b/src/std/rec/subRecord.dbd.pod @@ -10,7 +10,7 @@ =head1 Subroutine Record (sub) The subroutine record is used to call a C initialization routine and a recurring -scan routine. There is no device support for this record. +scan routine. There is no device support for this record. =head2 Contents @@ -71,10 +71,8 @@ recordtype(sub) { =head3 Scan Parameters The subroutine record has the standard fields for specifying under what -circumstances it will be processed. These fields are listed in -L. -In addition, -L +circumstances it will be processed. These fields are listed in +L. In addition, L explains how these fields are used. =head3 Read Parameters @@ -87,16 +85,14 @@ The input links can be either channel access or database links, or constants. When constants, the corresponding value field for the link is initialized with the constant value and the field's value can be changed at run-time via dbPuts. Otherwise, the values for (A-F) are fetched from the input links when the record -is processed. See -L
-for information on specifying links. +is processed. See L
for information on specifying links. =fields INPA, INPB, INPC, INPD, INPE, INPF, INPG, INPH, INPI, INPJ, INPK, INPL, A, B, C, D, E, F, G, H, I, J, K, L =head3 Subroutine Connection These fields are used to connect to the C subroutine. The name of the subroutine -should be entered in the SNAM field. +should be entered in the SNAM field. =fields INAM, SNAM @@ -119,7 +115,7 @@ The PREC field determines the floating point precision with which to display VAL. It is used whenever the C<<< get_precision >>> record support routine is called. -See L +See L for more on the record name (NAME) and description (DESC) fields. =fields EGU, HOPR, LOPR, PREC, NAME, DESC @@ -135,10 +131,8 @@ these fields, there is a corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The BRSV field is where the user can set the alarm severity in case the -subroutine returns a negative value. See -L -for a complete explanation of alarms and these fields. -L +subroutine returns a negative value. See L +for a complete explanation of alarms and these fields. L lists other fields related to a alarms that are common to all record types. =fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, BRSV, HYST @@ -153,8 +147,7 @@ minimum delta which the change must surpass before the value-change monitors are invoked. If these fields have a value of zero, everytime the value changes, a monitor will be triggered; if they have a value of -1, everytime the record is processed, monitors are triggered. The ADEL field is used by archive monitors -and the MDEL field for all other types of monitors. See -L +and the MDEL field for all other types of monitors. See L for a complete explanation of monitors and deadbands. =fields ADEL, MDEL @@ -779,4 +772,5 @@ processing. special(SPC_NOMOD) interest(3) } -} \ No newline at end of file +} + From 2461dc357418638a24788cf2f0d2f4c803efe6aa Mon Sep 17 00:00:00 2001 From: krmpotic Date: Mon, 9 Sep 2019 11:42:04 +0200 Subject: [PATCH 25/28] Update dbTest.c Fix MAX define. --- src/ioc/db/dbTest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ioc/db/dbTest.c b/src/ioc/db/dbTest.c index 637f8277d..7f4f77b95 100644 --- a/src/ioc/db/dbTest.c +++ b/src/ioc/db/dbTest.c @@ -54,7 +54,7 @@ typedef struct msgBuff TAB_BUFFER; # define MIN(x,y) (((x) < (y)) ? (x) : (y)) #endif #ifndef MAX -# define MAX(x,y) (((x) < (y)) ? (x) : (y)) +# define MAX(x,y) (((x) > (y)) ? (x) : (y)) #endif /* Local Routines */ From 73fec88168da1f16d499516c969c8326599b3d9d Mon Sep 17 00:00:00 2001 From: Michael Davidsaver Date: Thu, 5 Sep 2019 07:56:45 -0700 Subject: [PATCH 26/28] replace CALLBACK -> epicsCallback git grep -l -w CALLBACK -- src|xargs sed -i -e 's/\bCALLBACK\b/epicsCallback/g' with exceptions in callback.h --- src/ioc/as/asDbLib.h | 2 +- src/ioc/db/callback.c | 18 +++++++++--------- src/ioc/db/callback.h | 14 +++++++------- src/ioc/db/dbNotify.c | 6 +++--- src/ioc/db/dbScan.c | 12 ++++++------ src/ioc/db/test/callbackParallelTest.c | 8 ++++---- src/ioc/db/test/callbackTest.c | 8 ++++---- src/libCom/taskwd/taskwd.c | 2 +- src/std/dev/asSubRecordFunctions.c | 2 +- src/std/dev/devAiSoftCallback.c | 2 +- src/std/dev/devBiSoftCallback.c | 2 +- src/std/dev/devLiSoftCallback.c | 2 +- src/std/dev/devMbbiDirectSoftCallback.c | 2 +- src/std/dev/devMbbiSoftCallback.c | 2 +- src/std/dev/devSiSoftCallback.c | 2 +- src/std/rec/boRecord.c | 4 ++-- src/std/rec/calcoutRecord.c | 10 +++++----- src/std/rec/histogramRecord.c | 4 ++-- src/std/rec/seqRecord.c | 6 +++--- 19 files changed, 54 insertions(+), 54 deletions(-) diff --git a/src/ioc/as/asDbLib.h b/src/ioc/as/asDbLib.h index 65c4c6f59..1e0f6756e 100644 --- a/src/ioc/as/asDbLib.h +++ b/src/ioc/as/asDbLib.h @@ -16,7 +16,7 @@ #include "shareLib.h" typedef struct { - CALLBACK callback; + epicsCallback callback; long status; } ASDBCALLBACK; diff --git a/src/ioc/db/callback.c b/src/ioc/db/callback.c index b805c1c16..4c0f5eea6 100644 --- a/src/ioc/db/callback.c +++ b/src/ioc/db/callback.c @@ -168,7 +168,7 @@ static void callbackTask(void *arg) epicsEventMustWait(mySet->semWakeUp); while ((ptr = epicsRingPointerPop(mySet->queue))) { - CALLBACK *pcallback = (CALLBACK *)ptr; + epicsCallback *pcallback = (epicsCallback *)ptr; if(!epicsRingPointerIsEmpty(mySet->queue)) epicsEventMustTrigger(mySet->semWakeUp); mySet->queueOverflow = FALSE; @@ -268,7 +268,7 @@ void callbackInit(void) } /* This routine can be called from interrupt context */ -int callbackRequest(CALLBACK *pcallback) +int callbackRequest(epicsCallback *pcallback) { int priority; int pushOK; @@ -297,7 +297,7 @@ int callbackRequest(CALLBACK *pcallback) return 0; } -static void ProcessCallback(CALLBACK *pcallback) +static void ProcessCallback(epicsCallback *pcallback) { dbCommon *pRec; @@ -308,14 +308,14 @@ static void ProcessCallback(CALLBACK *pcallback) dbScanUnlock(pRec); } -void callbackSetProcess(CALLBACK *pcallback, int Priority, void *pRec) +void callbackSetProcess(epicsCallback *pcallback, int Priority, void *pRec) { callbackSetCallback(ProcessCallback, pcallback); callbackSetPriority(Priority, pcallback); callbackSetUser(pRec, pcallback); } -int callbackRequestProcessCallback(CALLBACK *pcallback, +int callbackRequestProcessCallback(epicsCallback *pcallback, int Priority, void *pRec) { callbackSetProcess(pcallback, Priority, pRec); @@ -324,11 +324,11 @@ int callbackRequestProcessCallback(CALLBACK *pcallback, static void notify(void *pPrivate) { - CALLBACK *pcallback = (CALLBACK *)pPrivate; + epicsCallback *pcallback = (epicsCallback *)pPrivate; callbackRequest(pcallback); } -void callbackRequestDelayed(CALLBACK *pcallback, double seconds) +void callbackRequestDelayed(epicsCallback *pcallback, double seconds) { epicsTimerId timer = (epicsTimerId)pcallback->timer; @@ -339,7 +339,7 @@ void callbackRequestDelayed(CALLBACK *pcallback, double seconds) epicsTimerStartDelay(timer, seconds); } -void callbackCancelDelayed(CALLBACK *pcallback) +void callbackCancelDelayed(epicsCallback *pcallback) { epicsTimerId timer = (epicsTimerId)pcallback->timer; @@ -348,7 +348,7 @@ void callbackCancelDelayed(CALLBACK *pcallback) } } -void callbackRequestProcessCallbackDelayed(CALLBACK *pcallback, +void callbackRequestProcessCallbackDelayed(epicsCallback *pcallback, int Priority, void *pRec, double seconds) { callbackSetProcess(pcallback, Priority, pRec); diff --git a/src/ioc/db/callback.h b/src/ioc/db/callback.h index 9011446dc..ca53fba11 100644 --- a/src/ioc/db/callback.h +++ b/src/ioc/db/callback.h @@ -55,21 +55,21 @@ typedef void (*CALLBACKFUNC)(struct callbackPvt*); #define callbackSetUser(USER,PCALLBACK)\ ( (PCALLBACK)->user = (void *)(USER) ) #define callbackGetUser(USER,PCALLBACK)\ -( (USER) = (void *)((CALLBACK *)(PCALLBACK))->user ) +( (USER) = (void *)((epicsCallback *)(PCALLBACK))->user ) epicsShareFunc void callbackInit(void); epicsShareFunc void callbackStop(void); epicsShareFunc void callbackCleanup(void); -epicsShareFunc int callbackRequest(CALLBACK *pCallback); +epicsShareFunc int callbackRequest(epicsCallback *pCallback); epicsShareFunc void callbackSetProcess( - CALLBACK *pcallback, int Priority, void *pRec); + epicsCallback *pcallback, int Priority, void *pRec); epicsShareFunc int callbackRequestProcessCallback( - CALLBACK *pCallback,int Priority, void *pRec); + epicsCallback *pCallback,int Priority, void *pRec); epicsShareFunc void callbackRequestDelayed( - CALLBACK *pCallback,double seconds); -epicsShareFunc void callbackCancelDelayed(CALLBACK *pcallback); + epicsCallback *pCallback,double seconds); +epicsShareFunc void callbackCancelDelayed(epicsCallback *pcallback); epicsShareFunc void callbackRequestProcessCallbackDelayed( - CALLBACK *pCallback, int Priority, void *pRec, double seconds); + epicsCallback *pCallback, int Priority, void *pRec, double seconds); epicsShareFunc int callbackSetQueueSize(int size); epicsShareFunc int callbackParallelThreads(int count, const char *prio); diff --git a/src/ioc/db/dbNotify.c b/src/ioc/db/dbNotify.c index 4727649b2..eaf254902 100644 --- a/src/ioc/db/dbNotify.c +++ b/src/ioc/db/dbNotify.c @@ -70,7 +70,7 @@ typedef struct notifyPvt { ELLNODE node; /*For free list*/ long magic; short state; - CALLBACK callback; + epicsCallback callback; ELLLIST waitList; /*list of records for current processNotify*/ short cancelWait; short userCallbackWait; @@ -93,7 +93,7 @@ static void notifyCleanup(processNotify *ppn); static void restartCheck(processNotifyRecord *ppnr); static void callDone(dbCommon *precord,processNotify *ppn); static void processNotifyCommon(processNotify *ppn,dbCommon *precord); -static void notifyCallback(CALLBACK *pcallback); +static void notifyCallback(epicsCallback *pcallback); #define ellSafeAdd(list,listnode) \ { \ @@ -265,7 +265,7 @@ static void processNotifyCommon(processNotify *ppn,dbCommon *precord) callDone(precord, ppn); } -static void notifyCallback(CALLBACK *pcallback) +static void notifyCallback(epicsCallback *pcallback) { processNotify *ppn = NULL; dbCommon *precord; diff --git a/src/ioc/db/dbScan.c b/src/ioc/db/dbScan.c index 311297441..dd283f7bf 100644 --- a/src/ioc/db/dbScan.c +++ b/src/ioc/db/dbScan.c @@ -109,7 +109,7 @@ static char *priorityName[NUM_CALLBACK_PRIORITIES] = { /* EVENT */ typedef struct event_list { - CALLBACK callback[NUM_CALLBACK_PRIORITIES]; + epicsCallback callback[NUM_CALLBACK_PRIORITIES]; scan_list scan_list[NUM_CALLBACK_PRIORITIES]; struct event_list *next; char eventname[1]; /* actually arbitrary size */ @@ -120,7 +120,7 @@ static epicsMutexId event_lock; /* IO_EVENT*/ typedef struct io_scan_list { - CALLBACK callback; + epicsCallback callback; scan_list scan_list; } io_scan_list; @@ -141,9 +141,9 @@ static void periodicTask(void *arg); static void initPeriodic(void); static void deletePeriodic(void); static void spawnPeriodic(int ind); -static void eventCallback(CALLBACK *pcallback); +static void eventCallback(epicsCallback *pcallback); static void ioscanInit(void); -static void ioscanCallback(CALLBACK *pcallback); +static void ioscanCallback(epicsCallback *pcallback); static void ioscanDestroy(void); static void printList(scan_list *psl, char *message); static void scanList(scan_list *psl); @@ -448,7 +448,7 @@ int scanpiol(void) /* print pioscan_list */ return 0; } -static void eventCallback(CALLBACK *pcallback) +static void eventCallback(epicsCallback *pcallback) { scan_list *psl; @@ -863,7 +863,7 @@ static void spawnPeriodic(int ind) epicsEventWait(startStopEvent); } -static void ioscanCallback(CALLBACK *pcallback) +static void ioscanCallback(epicsCallback *pcallback) { ioscan_head *piosh = (ioscan_head *) pcallback->user; int prio = pcallback->priority; diff --git a/src/ioc/db/test/callbackParallelTest.c b/src/ioc/db/test/callbackParallelTest.c index f8d0c3981..a985cd2d8 100644 --- a/src/ioc/db/test/callbackParallelTest.c +++ b/src/ioc/db/test/callbackParallelTest.c @@ -44,8 +44,8 @@ #define TEST_DELAY(i) ((i / NUM_CALLBACK_PRIORITIES) * DELAY_QUANTUM) typedef struct myPvt { - CALLBACK cb1; - CALLBACK cb2; + epicsCallback cb1; + epicsCallback cb2; epicsTimeStamp pass1Time; epicsTimeStamp pass2Time; double delay; @@ -55,7 +55,7 @@ typedef struct myPvt { epicsEventId finished; -static void myCallback(CALLBACK *pCallback) +static void myCallback(epicsCallback *pCallback) { myPvt *pmyPvt; @@ -74,7 +74,7 @@ static void myCallback(CALLBACK *pCallback) } } -static void finalCallback(CALLBACK *pCallback) +static void finalCallback(epicsCallback *pCallback) { myCallback(pCallback); epicsEventSignal(finished); diff --git a/src/ioc/db/test/callbackTest.c b/src/ioc/db/test/callbackTest.c index 3ccc2c2f3..4b7e24d78 100644 --- a/src/ioc/db/test/callbackTest.c +++ b/src/ioc/db/test/callbackTest.c @@ -44,8 +44,8 @@ #define TEST_DELAY(i) ((i / NUM_CALLBACK_PRIORITIES) * DELAY_QUANTUM) typedef struct myPvt { - CALLBACK cb1; - CALLBACK cb2; + epicsCallback cb1; + epicsCallback cb2; epicsTimeStamp pass1Time; epicsTimeStamp pass2Time; double delay; @@ -56,7 +56,7 @@ typedef struct myPvt { epicsEventId finished; -static void myCallback(CALLBACK *pCallback) +static void myCallback(epicsCallback *pCallback) { myPvt *pmyPvt; @@ -75,7 +75,7 @@ static void myCallback(CALLBACK *pCallback) } } -static void finalCallback(CALLBACK *pCallback) +static void finalCallback(epicsCallback *pCallback) { myCallback(pCallback); epicsEventSignal(finished); diff --git a/src/libCom/taskwd/taskwd.c b/src/libCom/taskwd/taskwd.c index f8a061c2c..03900b38b 100644 --- a/src/libCom/taskwd/taskwd.c +++ b/src/libCom/taskwd/taskwd.c @@ -367,7 +367,7 @@ epicsShareFunc void taskwdShow(int level) mCount, tCount, fCount); if (level) { printf("%16.16s %9s %12s %12s %12s\n", - "THREAD NAME", "STATE", "EPICS TID", "CALLBACK", "USR ARG"); + "THREAD NAME", "STATE", "EPICS TID", "epicsCallback", "USR ARG"); pt = (struct tNode *)ellFirst(&tList); while (pt != NULL) { epicsThreadGetName(pt->tid, tName, sizeof(tName)); diff --git a/src/std/dev/asSubRecordFunctions.c b/src/std/dev/asSubRecordFunctions.c index 957db300a..c42902a79 100644 --- a/src/std/dev/asSubRecordFunctions.c +++ b/src/std/dev/asSubRecordFunctions.c @@ -34,7 +34,7 @@ /* The following is provided for access security*/ /*It allows a CA client to force access security initialization*/ -static void myCallback(CALLBACK *pcallback) +static void myCallback(epicsCallback *pcallback) { ASDBCALLBACK *pasdbcallback = (ASDBCALLBACK *)pcallback; subRecord *precord; diff --git a/src/std/dev/devAiSoftCallback.c b/src/std/dev/devAiSoftCallback.c index 3744509ed..9eac0df93 100644 --- a/src/std/dev/devAiSoftCallback.c +++ b/src/std/dev/devAiSoftCallback.c @@ -36,7 +36,7 @@ typedef struct devPvt { processNotify pn; - CALLBACK callback; + epicsCallback callback; long options; int status; int smooth; diff --git a/src/std/dev/devBiSoftCallback.c b/src/std/dev/devBiSoftCallback.c index 02887ebe7..159145420 100644 --- a/src/std/dev/devBiSoftCallback.c +++ b/src/std/dev/devBiSoftCallback.c @@ -35,7 +35,7 @@ typedef struct devPvt { processNotify pn; - CALLBACK callback; + epicsCallback callback; long options; int status; struct { diff --git a/src/std/dev/devLiSoftCallback.c b/src/std/dev/devLiSoftCallback.c index 90bbff311..d776b27bf 100644 --- a/src/std/dev/devLiSoftCallback.c +++ b/src/std/dev/devLiSoftCallback.c @@ -35,7 +35,7 @@ typedef struct devPvt { processNotify pn; - CALLBACK callback; + epicsCallback callback; long options; int status; struct { diff --git a/src/std/dev/devMbbiDirectSoftCallback.c b/src/std/dev/devMbbiDirectSoftCallback.c index 6234a163b..bb9e88564 100644 --- a/src/std/dev/devMbbiDirectSoftCallback.c +++ b/src/std/dev/devMbbiDirectSoftCallback.c @@ -35,7 +35,7 @@ typedef struct devPvt { processNotify pn; - CALLBACK callback; + epicsCallback callback; long options; int status; struct { diff --git a/src/std/dev/devMbbiSoftCallback.c b/src/std/dev/devMbbiSoftCallback.c index 5447b4b6e..957697c69 100644 --- a/src/std/dev/devMbbiSoftCallback.c +++ b/src/std/dev/devMbbiSoftCallback.c @@ -35,7 +35,7 @@ typedef struct devPvt { processNotify pn; - CALLBACK callback; + epicsCallback callback; long options; int status; struct { diff --git a/src/std/dev/devSiSoftCallback.c b/src/std/dev/devSiSoftCallback.c index e2eff3213..ad7ceec7e 100644 --- a/src/std/dev/devSiSoftCallback.c +++ b/src/std/dev/devSiSoftCallback.c @@ -37,7 +37,7 @@ typedef struct devPvt { DBADDR dbaddr; processNotify pn; - CALLBACK callback; + epicsCallback callback; long options; int status; struct { diff --git a/src/std/rec/boRecord.c b/src/std/rec/boRecord.c index 48cc4846a..7dd0bec6f 100644 --- a/src/std/rec/boRecord.c +++ b/src/std/rec/boRecord.c @@ -98,7 +98,7 @@ struct bodset { /* binary output dset */ /* control block for callback*/ typedef struct myCallback { - CALLBACK callback; + epicsCallback callback; struct dbCommon *precord; }myCallback; @@ -106,7 +106,7 @@ static void checkAlarms(boRecord *); static void monitor(boRecord *); static long writeValue(boRecord *); -static void myCallbackFunc(CALLBACK *arg) +static void myCallbackFunc(epicsCallback *arg) { myCallback *pcallback; boRecord *prec; diff --git a/src/std/rec/calcoutRecord.c b/src/std/rec/calcoutRecord.c index c62b3f446..56bbdfd97 100644 --- a/src/std/rec/calcoutRecord.c +++ b/src/std/rec/calcoutRecord.c @@ -116,8 +116,8 @@ typedef struct calcoutDSET { #define CA_LINKS_NOT_OK 2 typedef struct rpvtStruct { - CALLBACK doOutCb; - CALLBACK checkLinkCb; + epicsCallback doOutCb; + epicsCallback checkLinkCb; short cbScheduled; short caLinkStat; /* NO_CA_LINKS, CA_LINKS_ALL_OK, CA_LINKS_NOT_OK */ } rpvtStruct; @@ -127,7 +127,7 @@ static void monitor(calcoutRecord *prec); static int fetch_values(calcoutRecord *prec); static void execOutput(calcoutRecord *prec); static void checkLinks(calcoutRecord *prec); -static void checkLinksCallback(CALLBACK *arg); +static void checkLinksCallback(epicsCallback *arg); static long writeValue(calcoutRecord *prec); int calcoutRecDebug; @@ -673,7 +673,7 @@ static int fetch_values(calcoutRecord *prec) return(status); } -static void checkLinksCallback(CALLBACK *arg) +static void checkLinksCallback(epicsCallback *arg) { calcoutRecord *prec; @@ -731,7 +731,7 @@ static void checkLinks(calcoutRecord *prec) prpvt->caLinkStat = NO_CA_LINKS; if (!prpvt->cbScheduled && caLinkNc) { - /* Schedule another CALLBACK */ + /* Schedule another epicsCallback */ prpvt->cbScheduled = 1; callbackRequestDelayed(&prpvt->checkLinkCb, .5); } diff --git a/src/std/rec/histogramRecord.c b/src/std/rec/histogramRecord.c index f24bba625..17730991b 100644 --- a/src/std/rec/histogramRecord.c +++ b/src/std/rec/histogramRecord.c @@ -100,7 +100,7 @@ struct histogramdset { /* histogram input dset */ /* control block for callback*/ typedef struct myCallback { - CALLBACK callback; + epicsCallback callback; histogramRecord *prec; } myCallback; @@ -110,7 +110,7 @@ static void monitor(histogramRecord *); static long readValue(histogramRecord *); -static void wdogCallback(CALLBACK *arg) +static void wdogCallback(epicsCallback *arg) { myCallback *pcallback; histogramRecord *prec; diff --git a/src/std/rec/seqRecord.c b/src/std/rec/seqRecord.c index 13d1cba1f..b143e0530 100644 --- a/src/std/rec/seqRecord.c +++ b/src/std/rec/seqRecord.c @@ -31,7 +31,7 @@ static void processNextLink(seqRecord *prec); static long asyncFinish(seqRecord *prec); -static void processCallback(CALLBACK *arg); +static void processCallback(epicsCallback *arg); /* Create RSET - Record Support Entry Table*/ #define report NULL @@ -94,7 +94,7 @@ typedef struct linkGrp { /* The list of link-groups for processing */ typedef struct seqRecPvt { - CALLBACK callback; + epicsCallback callback; seqRecord *prec; linkGrp *grps[NUM_LINKS + 1]; /* List of link-groups */ int index; /* Where we are now */ @@ -241,7 +241,7 @@ static long asyncFinish(seqRecord *prec) } -static void processCallback(CALLBACK *arg) +static void processCallback(epicsCallback *arg) { seqRecPvt *pcb; seqRecord *prec; From 75a1b82322e8cbaa5f3630f94e38728cfe774052 Mon Sep 17 00:00:00 2001 From: Michael Davidsaver Date: Thu, 5 Sep 2019 10:28:27 -0700 Subject: [PATCH 27/28] add option EPICS_NO_CALLBACK Allow the CALLBACK definition to be hidden to prevent conflicts on WIN32. --- src/ioc/db/callback.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/ioc/db/callback.h b/src/ioc/db/callback.h index ca53fba11..0a212ade5 100644 --- a/src/ioc/db/callback.h +++ b/src/ioc/db/callback.h @@ -26,7 +26,7 @@ extern "C" { /* * WINDOWS also has a "CALLBACK" type def */ -#ifdef _WIN32 +#if defined(_WIN32) && !defined(EPICS_NO_CALLBACK) # ifdef CALLBACK # undef CALLBACK # endif /*CALLBACK*/ @@ -44,7 +44,9 @@ typedef struct callbackPvt { void *timer; /*for use by callback itself*/ }epicsCallback; +#if !defined(EPICS_NO_CALLBACK) typedef epicsCallback CALLBACK; +#endif typedef void (*CALLBACKFUNC)(struct callbackPvt*); From 77574022a109d82edb52a959c11e09b4e89440db Mon Sep 17 00:00:00 2001 From: Michael Davidsaver Date: Mon, 9 Sep 2019 16:56:28 -0700 Subject: [PATCH 28/28] update RELEASE_NOTES --- documentation/RELEASE_NOTES.html | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/documentation/RELEASE_NOTES.html b/documentation/RELEASE_NOTES.html index 8ed4e04bf..6f2019379 100644 --- a/documentation/RELEASE_NOTES.html +++ b/documentation/RELEASE_NOTES.html @@ -16,6 +16,18 @@ +

Add option to avoid CALLBACK conflict

+ +

If a macro EPICS_NO_CALLBACK is defined, then callback.h will no longer (re)define CALLBACK. +The name 'CALLBACK' is used by the WIN32 API, and redefinition in callback.h cause errors +if some windows headers are later included. +

+ +

Code which defines EPICS_NO_CALLBACK, but still wishes to use callbacks, should use +the alternate name 'epicsCallback' introduced in 3.15.6, 3.16.2, and 7.0.2. +It is also possible, though not encouraged, to use 'struct callbackPvt' +which has been present since the callback API was introduced.

+

Cleaning up with Multiple CA contexts in a Process

Bruno Martins reported a problem with the CA client library at shutdown in a