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