The arrays can be loaded at boot time, using autosave; written to at run time by a CA client; or built up element by element at run time, by setting the MODE switch ("$(P)interp_mode") to "Add Entry".
To interpolate, one sets the mode switch to "Interpolate", and writes a number to the X-input field, "$(P)interp_x". This causes an underlying aSub record to interpolate the Yi arrays to find values that would correspond with that value of X, to display them as "$(P)interp_y1" and "$(P)interp_y2", and, optionally, to write them to the external PVs named in the link fields "$(P)interp_y1.OUT", and "$(P)interp_y2.OUT".
The interpolation performed is a Lagrange interpolation, where the degree of the polynomial can be specified by writing to "$(P)interp.F". The order must be in the range 1..10. Currently the database doesn't visibly enforce these limits, but silently clips to them if they are violated.
To add an element to the arrays, one sets the mode switch to "Add Element", writes Yi values to "$(P)interp_y1" and "$(P)interp_y2", and then writes the corresponding X value to "$(P)interp_x". The number of entries, "$(P)interp_n" will then increase by one.
The arrays can be cleared by setting the mode switch to "Clear All" and writing anything to X.
For more information, see interp.README.
These records are intended for use in run-time programming. With either algorithm, the records can operate in two ways:
In either mode, the record uses its alarm field to indicate whether the output value it is displaying ("$(P)userAve$(N).VAL") is valid (i.e., is the result of M readings). Until M readings have been read, the record will be in alarm (STAT=="SOFT", SEVR=="MAJOR"). After M readings have been treated, STAT=="NO_ALARM", SEVR=="NO_ALARM".
Although the swait record is not recommended for new development, it is retained in this case because many users have become accustomed to the way it behaves -- in particular, to the way its links are programmed: they take only a PV name, without the link attributes (e.g., NPP, NMS) that standard EPICS links have.
configure/RELEASEto specify the paths to EPICS base, and to the sscan and seq modules. If you don't have sscan, or don't want it to be used by the calc module, comment the definition out, and the calc module will adjust its build accordingly. Same for seq. The only thing calc can't build without sscan is the swait record, which is retained in calc mostly for historical reasons. The only thing calc can't build without sscan is the editSseq program and database, which support run-time editing of sseq and seq records.
If calc was built with sscan or seq, modules that depend on calc should also be built with those modules.
The swait record is the original "userCalc" record, and many users at APS have become accustomed to the way it works. The calcout record from EPICS base, with "Async Soft Channel" device support, is a reasonable substitute for the swait record,
include calc.dbdto its
xxxInclude.dbdfile, and it must link with
libcalc, by adding a line like
xxx_LIBS += calcto xxxApp/src/Makefile.