-
Notifications
You must be signed in to change notification settings - Fork 2
CSS Archive Engine
Wiki > The Backend System > System components > CSS Archive Engine
The Archive Engine is part of CSS and is used to archive PV values, the manual for which is here. Note that most facilities use the Archive Appliance as the Archive Engine (specifically MySQL) was found to be slow at millions of PVs. As we don't have that many PVs we have continued to use the Archive Engine.
The code for the Archive Engine is here. We have our own fork of this here but in general the two should be in sync as much as possible as discussed.
We have a built version of the ArchiveEngine at \\shadow.isis.cclrc.ac.uk\ICP_Binaries$\CSS which gets copied into EPICS\CSS\master\css-win.x86_64 during the build. The built version is manually updated to keep it in line with the cs-studio version, see updating the archive engine.
We actually run two archive engines on each instrument:
- Block archive, this just archives blocks and is restarted whenever the configuration (and blocks) change.
- Instrument archive, this is just started once and archives all PVs marked with the archive info setting which are in the database. See configuration.
To run these archive engines there are two batch files in EPICS\CSS\master\ArchiveEngine called start_block_archiver and start_inst_archiver. They can also both be accessed via procserv as ARBLOCK and ARINST.
Each Archive Engine can be accessed via a web browser when running. This is what the web dashboard is based on.
The archive engine stores values in a MySQL database. To set the database up see here.
Create the database using the mysql_schema.txt in ...EPICS\CSS\master\ArchiveEngine which originates from org.csstudio.archive.rdb\dbd
To change properties of the archive engine in general such as which database it is pointing to and the channel access settings you can modify mysql_settings_*.ini in EPICS\CSS\master\ArchiveEngine.
The archive engine gets its configuration for what PVs to archive and how (i.e. frequency or monitoring) from the same database that it archives values to. Rather than editing this directly the easiest way to modify it is using the Archive Configuration Tool.
Various examples of the xml format used for the tool are in EPICS\CSS\master\ArchiveEngine. They can be manually imported/exported using the get/set batch scripts in EPICS\CSS\master\ArchiveEngine. The way this xml is created differs for the instrument and block archivers:
For setting which PVs to archive you can add an info field into the relevant db. For example info(archive, "0.1 VAL") will archive the VAL field every 0.1 seconds. When the IOC is first started this info field data gets put into the ioc database. The CSS\master\ArchiveEngine\make_archive_xml.py script then converts this into xml for the Archive Config Tool to put into the archive engine database.
The configuration for logging blocks is created and set by the Blockserver.
As our version of the Archive Engine is no different to CSS we can just copy their builds to get the latest version. To do this:
- Download the build from CSS.
- Place it in a folder called
css_archvive_engine - Zip the folder and call it
css_archive_engine-win.x86_64.zip - Copy this to ICP Binaries on to internal server
In some cases we may want to build the archive engine ourselves. For example, if we want to edit the code. To do this:
- Clone the repository from https://github.com/ISISComputingGroup/cs-studio
- In Eclipse
Import->General->Projects from Folder or Archiveand import thecs-studio\applications\archivedirectory. It may prompt you to install some tycho plug ins and restart eclipse. - Create a target platform and add the latest CSS version specified here as a
In Eclipse, go to org.csstudio.archive.engine and open ArchiveEngine.product.
Add the following settings to the "Launching" tab under "Program Arguments" and run as a normal RCP application:
-engine my_engine -pluginCustomization full_path_here\my_settings.ini
The CS-Studio manual says that the port is required for consistency tests but I have found this to cause problems.
Alternatively, leave the "Program Arguments" blank and edit the plugin_customization.ini in the project to contain the settings.
If creating a standalone executable, leave "Program Arguments" blank and use command line arguments instead.
By using the MySQL command line it should be possible to see the database filling up (it appears the update rate is ~30 seconds, so you might not see any changes initially).
mysql> use archive;
mysql> select * from sample;