ConSys Introduction/Overview
Contents:
- Introduction
- Overall Structure
- Applications
- Devices
- Parameters / Database
- References to more documentation.
Other links:
- General Purpose ConSys Programs.
- ConSys Automation Overview.
- ConSys Device List.
- ConSys History.
- ConSys User Manuals
- Consys home page
Introduction:
ConSys is a complete and modern control system for storage rings and associated injectors, running on Microsoft Windows NT/XP. The system is network based (Ethernet), with distributed front-end and client/console computers. The system consists of three parts: The kernel, devices, and client programs. The kernel, common for all computers, handles all communication between devices and client programs, be it locally on the same computer or across the network. The devices store the values of the parameters on the system, and handle all the input/output communication to the hardware under control through device drivers etc. For interaction with the operators, a number of client programs have been developed, of which the major one is the Console. The tripartition of the system allows very easy addition of new devices and client programs, as new types of hardware need control, and as new needs for utility programs arise. The computer code is highly object-oriented reducing code size and development time. The system is fully software configurable with all addresses, conversions, and display properties stored in an ODBC compliant database.
ConSys is being used at ISA (ASTRID, ELISA) and MSL (CryRing).
Overall Structure:
The figure to the right shows the overall relations between the major ConSys
objects. At the top is a ConSys Application, which, through one (or more) ConSysClient(s), accesses ConSys parameters, whose values are defined and stored in
Devices. In between the Client and the Device is the Transport Layer, which is
responsible for the transport of values between the Client and the Device, be it
locally on the same computer or across the network. A fundamental part of the Transport
Layer is the Dataservers, which act as acquisition agents. It is the Dataservers which, based on criteria from the clients, decide when parameters are
to be transmitted to the clients. The criteria can be minimum/maximum
time intervals and/or minimum changes of floating values.
ConSys is programmed in Microsoft Visual C++ with a very strong use of MFC
(Microsoft Foundation Classes). ConSys is presently (sep 2003) being ported to
the new Visual C++ .NET 2003 compiler. Objects (classes) are used heavily,
giving a large flexibility and a large code-reuse.
Applications:
ConSys has a number of General Purpose
programs, of which the most important are the
Console, ReSto,
and CSPlot.
Writing a new application is very easy, since only a few methods in the CClient
class has to be learned.
Accessing ConSys parameters from other programming languages, is very easy
through the CSAPI.dll (standard Windows Dynamic Link Library). Definition files
and examples exist for LabView, Delphi, and Visual Basic.
Devices:
The devices are the placeholders for the current parameter values and are
furthermore the interface to the hardware. The device
base-class defines abstract methods for reading and writing. An address object
included with these methods locates the parameter in the device. The device
class furthermore includes an abstract method for parameter subscription. Data
servers call this method in order to register for subscription at the device.
The device signals registered data servers whenever data has changed in the
device.
An important concept is a virtual device - a device without direct connection to
hardware. In the simplest case, a virtual device can simply be a storage place for
persistent information (for example the time of last injection). A more advanced
use of the virtual device is intelligent data handling - that might be
automation of operation or as special conversions between, for instance, physical
parameters and direct controls. In the latter case the virtual device utilises
the ability to connect to any parameter on the control system, just as any other
client application on the system. See the document on
automation for more details.
The writing of a new device is, in most cases, quite easy, since a number of base
classes exist. These include a class (CCrateConvBaseDevice) handling larger
devices with many input/output channels of general usage (typical
data acquisition control (PLC, VME, GAMAC, etc). The addressing and conversion
from binary to physical values are retrieved from the central database. This means that scaling and bit usage are
defined in the database. Another class (CCalcDevice) wraps all of the interface
to the ConSys Kernel into a few simple functions to set and retrieve device
values and values from other parameters. It is especially useful for automation
devices and for interface to specific hardware, like function generators, volt
meters etc., typically interfaced via GPIB, RS232 or similar. A special
inherited class (CSerialPortCalcDevice)is available
for control using one RS232/RS422 port. All of these base devices handles all
persistent and history storage of parameter values.
Parameters / Database:
A parameter in ConSys is one specific control, like a floating point setting or
acquisition value, or one bit or word setting/acquisition. These individual
parameters are grouped in ParameterNames, which is one entity, like a
power supply. One parameter is then specified as ParameterName.SurName (as an
example BMH11IBM.dac). To help selections in up- and download etc., the
ParameterNames are furthermore grouped in MachinesGroups.
All parameter configuration (addressing, display options, conversions (i.e.
scalings, units, and bit interpretations) are stored in an ODBC-compliant
database (Microsoft SQL server). This means that adding new parameters is very
easy, since it only requires changes in the database, and no changes in the
software. Similar is the configuration of the Console set-up (which parameters on
which pages, etc.) stored in the database, again permitting the same Console
program to be used at different facilities.
References to more documentation:
-
EPAC 98 (TUP46G) article (pdf). A more user (operator) oriented view.
-
EPAC 98 (TUP46G) poster (pdf).
-
ICALEPCS 99 article (pdf). A more programmer oriented view.
-
ICALEPCS 99 poster (pdf).
Document created by JSN 16-09-2003,
Last Modified 06 May 2020