Documentation:Users:EPICS - MdsWiki
Navigation
Personal tools

From MdsWiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 13:47, 8 September 2016 (edit)
Manduchi (Talk | contribs)
(MDSplus Records for EPICS I/O Controllers)
← Previous diff
Revision as of 13:47, 8 September 2016 (edit)
Manduchi (Talk | contribs)
(MDSplus Records for EPICS I/O Controllers)
Next diff →
Line 8: Line 8:
==MDSplus Records for EPICS I/O Controllers== ==MDSplus Records for EPICS I/O Controllers==
-In EPICS control and supervision is carried out by I/O Controllers (IOCs) . Every I/O controller is an application which executes a set of interconnected components called Records. Every record carries out a specific set of actions and can propagate data to other interconnected records. The behavior of a IOC is therefore defined by the associated records, and such configuration is stored as a text file. Graphical tools exist for the proper record programming and interconnection. Every record defines a set of fields which define its behavior. Records can be executed either periodically or when the the records connected via incoming links are executed. The basic set of EPICS records has been extended to provide MDSplus functionality within IOCs, via the'''mdsexpr''' record, for evaluating MDSplus expressions. MDSplus expressions represent a very flexible way for retrieving data or executing actions, including saving data in MDSplus trees. The corresponding expression is evaluated every time that record is processed in the EPICS IOC.+In EPICS control and supervision is carried out by I/O Controllers (IOCs) . Every I/O controller is an application which executes a set of interconnected components called Records. Every record carries out a specific set of actions and can propagate data to other interconnected records. The behavior of a IOC is therefore defined by the associated records, and such configuration is stored as a text file. Graphical tools exist for the proper record programming and interconnection. Every record defines a set of fields which define its behavior. Records can be executed either periodically or when the the records connected via incoming links are executed. The basic set of EPICS records has been extended to provide MDSplus functionality within IOCs, via the '''mdsexpr''' record, for evaluating MDSplus expressions. MDSplus expressions represent a very flexible way for retrieving data or executing actions, including saving data in MDSplus trees. The corresponding expression is evaluated every time that record is processed in the EPICS IOC.
===mdsexpr record=== ===mdsexpr record===

Revision as of 13:47, 8 September 2016

Contents

MDSplus EPICS interface

The MDSplus interface for EPICS is composed of three main components:

  1. A Set of IOC records which allow using MDSplus functionality from within EPICS Input/Output Controllers;
  2. A Channel archiver for MDSplus, for storing data generated within EPICS IOCs (and more in gereral by any Channel Access Server (CAS) application) exported using the Channel Access protocol into MDSplus trees;
  3. A Channel Access Server for exporting MDSplus configuration data to IOC records using the Channel Access protocol.

MDSplus Records for EPICS I/O Controllers

In EPICS control and supervision is carried out by I/O Controllers (IOCs) . Every I/O controller is an application which executes a set of interconnected components called Records. Every record carries out a specific set of actions and can propagate data to other interconnected records. The behavior of a IOC is therefore defined by the associated records, and such configuration is stored as a text file. Graphical tools exist for the proper record programming and interconnection. Every record defines a set of fields which define its behavior. Records can be executed either periodically or when the the records connected via incoming links are executed. The basic set of EPICS records has been extended to provide MDSplus functionality within IOCs, via the mdsexpr record, for evaluating MDSplus expressions. MDSplus expressions represent a very flexible way for retrieving data or executing actions, including saving data in MDSplus trees. The corresponding expression is evaluated every time that record is processed in the EPICS IOC.

mdsexpr record

When processed, record mdsexpr will provide the evaluation of the specified MDSplus expression. Since in MDSplus expressions represent a very general concept, evaluating a MDSplus expression may involve many different actions. If the expression is used in the traditional way, it will perform the computation specified by field EXPR, possibly taking up to 8 arguments, specified by fields INP1-8 (links to data arguments) and FT1-8 (types of data arguments). The result of the evaluated expression is stored in field VAL, converted to the type specified in field FTVL. Field NORD will contain the number of returned data items (>1 if an array is the result of the expression evaluation). The expression may also contain calls to routines of shareable libraries, so this record can also be used to trigger external computation, possibly taking inputs from the records connected to the mdsexpr record.

The evaluation of the expression can be carried out either locally or remotely, on any node running a mdsip server. In the latter case, the possible arguments are sent over the network and the result is sent back, using the mdsip protocol for remote data access.
The expression may also contain references to MDSplus trees: in this case fields EXP and SHOT specify the name and the shot of the tree to which data item in the expression refer to. If field EXP is empty it is assumed that the expression does not refer MDSplus pulse files (trees) and no tree is open during record initialization.
In order to specify external arguments to the expression specification, use $ arguments in the textual expression definition (field EXPR). For example, the evaluation of expression 2 * $ + $ will take the first argument specified in field INP1, multiply it for 2 and then add the second argument, specified by field INP2. Array arguments are supported since MDSplus is able to handle multidimensional elements in expression evaluation.
The specific fields of mdsexpr record are:

  • DTYP Device type, must be devExprSoft;
  • LOC Local/Remote switch. If remote, the expression is evaluated on the machine whose address is specified in DSIP;
  • DSIP Address of the mdsip server which will evaluate the expression;
  • EXPR Textual specification of the expression. Refer to MDSplus documentation for syntax description and examples;
  • INP1 - INP8 Input specifications, typically links to other records, they are associated with the $ argument specification in the textual expression description in EXPR;
  • FT1 - FT8 Type specification of the input fields;
  • FTVL Output type. The result of the expression is converted to the specified type;
  • NORD Number of returned elements, > 1 if the evaluation of the expression is an array;
  • NELM Maximum number of elements: used to dimension the internal buffers. Must be not less than the maximum number of samples for the inputs and the computed value;
  • EXP Tree name in case a tree has to be open during expression evaluation (in the case the expression contains references to data item stored in MDSplus trees). When containing an empty string no tree is open;
  • SHOT Shot number of the tree to be open.
  • ERRM Error message string. After processing it will contain the error message in case of errors.

The result of the expression is then stored in field VAL


Installation

The files required to install the records in EPICS are contained in <MDSplus root>/epics/mdsrecord.
Basic installation is performed in following steps:

  • Create a EPICS directory tree named mdsplusSup using the EPICS procedure MakeBaseApp starting from root <ApplicationRoot>
  • Copy the files in <MDSplus root>/epics/mdsrecord into the directory created: <ApplicationsRoot>/m-mdsplusSup/src/main/epics/mdsplusSupApp/src/
  • Build it with the EPICS mvn compile command

In order to use mdsexpr record in a EPICS IOC (named <AppName>), the following actions are requied in the IOC specific EPICS directory tree:

  • Copy all the dbd files from <MDSplus root>/epics/mdsrecord into <AppName>/src/main/epics/<AppName>App/src/
  • Modify Makefile in that directory to include the following lines:
#===========================
# MDSplus record support

<AppName>_DBD += mdsexprRecord.dbd
<AppName>_DBD += devMeSoft.dbd
<AppName>_DBD += devExprSoft.dbd

<AppName>_LIBS += mdsplusSup
mdsplusSup_DIR += <ApplicationsRoot>/m-mdsplusSup/target/main/epics/lib/linux-x86_64 
mdsplusSup_LIBS += MdsObjectsCppShr
mdsplusSup_LIBS += MdsIpShr
MdsObjectsCppShr_DIR += /usr/local/mdsplus/lib/
MdsIpShr_DIR += /usr/local/mdsplus/lib/
*Build the application with the EPICS command mvn compile

MDSplus Channel Archiver for EPICS

The MDSplus channel archiver allows to connect to a set of IOC data items which are exported via Channel Access, and to store their values in a MDSplus tree. Every channel can be acquired in either of the following modes:

  • Scan mode The channel is read periodically, at a programmable read rate;
  • Monitor mode The channel is acquired only when its actual value changes and is therefore exported via the monitor functionality of Channel Access;
  • Scan/Monitor mode The channel is actually recorded using the monitor mechanism (i.e. a network transaction occurs only when its value changes), but it is saved in the pulse file at the specified scan rate. This feature is useful to avoid useless remote data accesses in the case the data items does not change frequently.

Data items are stored in the corresponding nodes in the MDSplus tree using segmented data items. Received data is buffered in memory until a preset number of samples has been received. In this case the whole segment is written, obtaining therefore better performance in writing. The number of samples per segment is passed as an optional argument when ChannelArchiver is launched. The default value of segment size is 300 samples. If a segment size of 1 is specified, data are written sample by sample in the tree using putRow() operation. In this case the write operation is less efficient, but data are available as soon as they are received. This option may be useful when using ChannelArchiver for acquiring very slow signals whose update rate is not higher than 10 Hz.
Channels can be grouped into groups, and it is possible to define group-level data acquisition policies. A disabling expression can in fact be specified at the group level, possibly referring to the values of other data items. Whenever a new data item is available, the disable expression, if any, for its group is evaluated, and the data actually saved on the tree only if the result of the evaluation is 0. In this way it is possible to define data acquisition policies avoiding, for example, acquiring groups of data items in the case the corresponding plant is switched off. A flag will be associated with every data item specifying if it concurs to the evaluation of a disable expression, and in this case the data item is stored all the same in the tree.
The command syntax for ChannelArchiver is:

java ChannelArchiver <MDSplus tree> <shot> [segment_size]

The command requires the specification of a tree from which the program will retrieve all the required information on the groups and the channels to be acquired. It is necessary to include <MDSplus root>/java/classes/mdsobjects.jar in env variable CLASSPATH.

ChannelArchiver expects a given structure in the passed tree, and retrieves information on the names of the Channels to be periodically read or monitored by traversing the tree. Following is an example of tree structure for a configuration defining a group named GROUP1 and two data items: DATA1 and DATA2.
Image:ChannelArchiverTree.jpg
At the top level some parameters are defined. Some of them have been defined for compatibility with the original EPICS channel archiver and are meaningless here. The meaningful global parameters are:

  • FILE_SIZE it represents the largest dimension in MBytes of the tree. Further data is stored in a tree with a subsequent shot number. The default value is 1GByte;
  • GET_TRESH it represents the period (in seconds) under which a SCAN definition for channels is changed into SCAN/MONITOR. The default value is 1 seconds;
  • IGN_FUTURE it represents the maximum time in advance (in hours) in respect of the time of the last sample above which the received data item is discarded. The default is 6 hours;

At the group level item DISABLE is defined, containing the definition of the disable expression for that group. The group subtree contains as many subtrees as the number of defined channels for that group. Every channel subtree defines the following configuration items:

  • REC_NAME the Name of the Channel for the Channel Access protocol;
  • EGU Engineering units for that data item (typically the value of an IOC record);
  • HOPR High operating range for the data item;
  • LOPR Low operating range for the data item;
  • PERIOD Acquisition period (meaningful only if mode is SCAN);
  • IS_DISABLE Indicates whether that data item contributes to the disable expression (and is therefore always stored);
  • SCAN_MODE Can be either "SCAN" for cyclic readout or "MONITOR" for monitored data collection. If mode is "SCAN" and PERIOD less than GET_TRESH, a Channel Access monitor is internally used;
  • VAL The actual values of the data item;
  • ALARM Alarm severity for the data item. Severity values are stored only when changed.

It is possible to convert the XML definition of the original EPICS channel archiver tool into the XML specification of the reference tree for the MDSplus ChannelArchiver. Following is the xml definition of the original archiver tool, corresponding to the tree shown above:

Image:EpicsArchiverConfiguration.jpg

The following command translates the original channel archiver configurationinto the tree specification in xml of the for the MDSplus CannelArchiver.

xsltproc epics2mdsplus.xsl <original xml description>.xml > <TreeName>.xml

epics2mdsplus is a XSL translation file available in <MDSplusRoot>/epics/archiver. The second argument is the file name of the original EPICS channel archiver configuration and the output is redirected to a xml file containing the MDSplus xml definition for a tree. Such description is converted into a MDSplus tree with the following command:

java CompileTree <TreeName>.xml <TreeName>

after making sure that <MDSplusRoot>/java/classes/jTraverser.jar is included in CLASSPATH.

Currently, the MDSplus ChannelArchiver does not support http-based introspection for getting information from a running ChannelArchiver program. It is planned that these feature will be added in the next months.

Directory <MDSplusRoot>/epics/archiver contains also two jar files implementing the EPICS Channel Access protocol. In order to compile ChannelArchiver.java you need to include these two jar files in CLASSPATH together with the jar file <MDSplusRoot>/java/classes/mdsobjects.jar

MDSplus Channel Access server for EPICS

The MDSplus Channel Access Server exports data contained in pulse files over Channel Access. It is intended to ease the usage of MDSplus for storing configuration data and to let such data be natively available in IOCs. It is also possible to use any EPICS tool (e.g. from CSS) for the graphical configuration set-up, using a MDSplus pulse file as data repository. In this case the presence of the pulse file becomes transparent (both the interface and the IOC records access data over Channel Access), but allows for a unique repository of configuration data, following the data centric philosophy of MDSplus.
The MDSplus Channel Access server can operate in two modes: append and non append. In non append mode data written through Channel Access overwrites previous data for that Process Variable in the pulse file. In append mode, previous data is not deleted, so that the history of that Process Variable is maintained in the pulse file. In the latter case MDSplus segments are used, and the old values together with their associated times (i.e. the EPICS time at which they have been set) are available in the pulse files.

The command line syntax of the MDSplus ChannelAccess server is:

casmds <experiment_name> <shot> [append]

When started, the server scans the pulse file in order to find the defined tag names. It is expected that data associated with a single process variable will be contained in a subtree whose root has an associated tag corresponding to the name of the Process Variable. The only mandatory data item for this subtree is VAL, i.e. the data item containing the actual value of the corresponding PV. If the usage of node VAL is TEXT, the PV will be exported as a text PV (and in this case its value is always overwritten), otherwise it is exported as a numeric PV. The other (optional) nodes of the subtree associated with a given Process Variable are:

  • DIMS: specifies whether the numeric PV is a scalar or a (multidimensional) array. It is an integer array: if empty or missing, the PV is assumed to be scalar, otherwise it contains for each dimension the corresponding number of elements
  • LOPR
  • HOPR: operating range definition
  • HIGH_ALARM
  • LOW_ALARM: alarm threshold definition
  • HIGH_WARN
  • LOW_WARN: warning threshold definition
  • HIGH_CTRL
  • LOW_CTRL: control threshold definition
  • HIGH_GRAPH
  • LOW_GRAPH: graphical display limits
  • UNITS: the units for the PV
  • ENUMS : enumerated state strings

Except for VAL, the other PV data items are optional and are read at startup. They are used to provide additional information in the Channel Access protocol as well as for setting the appropriate Alarm and severity definition when PVs are monitored.

Installation

The MDSplus Channel Access server is implemented as a set of C++ classes which inherit from the EPICS Channel Access Portable Server. The source files are in <mdsplus_distr_root>/epics/cas. In order to build the MDSplus Channel Access Server the following steps are required:
- Using the EPICS MakeBaseApp perl script build the directory tree and the associated configuration file. Call the application casmds. The command is:

<epics root>/epics/base/bin/<arch>/makeBaseApp.pl -b $EPICS_BASE -t caServer casmds

where <epics root> and <arch> refer to the root directory of EPICS distribution and the used architecture, respectively.
- Copy the source files in <mdsplus_distr_root>/epics/cas to <appRoot>/casmdsApp
- Add the following lines to the Makefile defined in <appRoot>/casmdsApp (where it is assumed that the MDSplus shared libraries are in /usr/local/mdsplus/lib64), replacing the lines starting with casexampleSRCS +=:

SRCS += main.cc
SRCS += mdsServer.cc
SRCS += mdsPV.cc
SRCS += mdsChannel.cc
SRCS += pvEntry.cc
PROD_LIBS += MdsObjectsCppShr
PROD_LIBS += MdsIpShr
MdsObjectsCppShr_DIR += /usr/local/mdsplus/lib64/
MdsIpShr_DIR += /usr/local/mdsplus/lib64/
USR_INCLUDES += -I/usr/local/mdsplus/include

- Replace in the Makefile line

PROD_HOST = casexample

with

PROD_HOST = casmds

within <appRoot>/casmdsApp call make