Documentation of the ONCS HV Software
- Author:
- C.Witzig, BNL
Design Considerations:
The following guidelines have been followed in the design
of the ONCS HV software:
- Which classes do exist?
Currently there are C++ classes for the HVgroup, HVmodule, the HVchannel
and subclasses that allow to control the EPICS HV software in
real time as well and subclasses that make a connection to the
database (Objectivity/DB).
- HV module vs HV channel:
In real life the HV module has not much meaning beyond being
a piece of hardware that happens to be installed in a mainframe
and has several controllable HV channels.
Therefore the decision was made to add control features only to the
HVchannel and HVgroup object, but not the module object. However
the HVchannel object is instantiated by the HVmodule object (obviously
you must have a HV module in order to have a HV channel).
- HVgroup :
HVchannels and HVmodules can be added/removed to groups which allows
to control them in a common way.
- What does the user see?
The design decision was made to hide all the details of EPICS
and the database from the user. Thus the classes that the normal
user sees are only HVgroup, HVmodule and HVchannel (unless
the wants eg to control directly the database using the
classes dbHVxxx - see below).
This means that the classes HVgroup, HVmodule and HVchannel to not
support any directly EPICS/DB access, but inherit it from the
classes genOncsEpicsDevice and dbHVinterface.
In addition to the objects that correspond to the hardware there
are two classes HVsetpoint (the setpoints of a channel) and
HVreadback (the readback), which can also be stored in the
database.
In particular it was attempted to separate the EPICS connectivity
from the Objectivity that one can be used without the other
(after proper modifications of the inheritance tree and Makefile
as well as recompilation).
- Connection to EPICS :
Only the class HVchannel has a connection to EPICS which is done
using the EPICS extension "ezca" (easy channel access). If
speed becomes an issue, this could be replaced with a more
sophisticated mechanism.
Currently all the LeCroy parameters of a module can be
manipulated, but not read/writeable EPICS parameters (such as
alarm limits).
- Connection to the database (Objectivity/DB) :
The persistent classes are dbHVmainframe, dbHVmodule, dbHVchannel,
dbHVsetpoint (a setpoint in the past) and dbHVreadback (the stored
readback value of a channel).
The classes HVmodule and HVchannel inherit from the class
dbHVinterface the capability to interface to Objectivity using the
class dbHV, which opens/closes the database. Class dbHV thus encapsulates
all the Objectivity details.
In addition HVmodule and HVchannel have a private datamember
which is the reference to their persistent counterpart
in the database (class dbHVmodule/dbHVchannel).
Of course a user can also directly access the database using the
classes dbHVxxx, but in that case there is no connectivity to EPICS.
- Why aren't the persistent classes not documented?
This is a problem of doc++ that does not fully understand the ddl files.
Sorry about that. Look for the .ddl and .cc for details.
- How are the LeCroy 1469 classes supported?
The 1469 HV module has 3 bulk supplies each of which control 8
HV channels. They are supported through inheritance. See section below.
- What happened to the Objectivity Classes ?
In July-August 1999, the Objectivty database structure was redefined,
allowing for faster data transport/storage and lower space requirements.
In doing this, the old dbHV files were replaced. The new source files are:
cfhv_module.cc, cfhv_mainframe.cc, thv_timetag.cc, rbhv_readback.cc,
and hvdb_set.cc. All but hvdb_set.cc have cooresponding .ddl files;
hvdb_set.cc has its own header file. Like the Objectivity classes before
them, they cannot be doccumented with doc++, but have been commented throughly
in the .cc and .ddl files. -- R. Roth
- Does this change to the new Objectivity DB change the way
the HV library operates ?
The changes to the HV libraries have been restricted. Most changes involve
the way int whcih data is stored in the database. Effort has been made to make sure
that the function/object calls/names remain the same. There should be little,
if any, changes necessary to make in existing programs. -- R. Roth
- Version:
- 1.0
alphabetic index hierarchy of classes