User manual: ConSys Kernel
Status:
This information applies to ConSys Kernel version 1.47.751.790 (23. may 2024)
Contents:
- Overview
- History Types
- Use of Histories in standard devices
- Write History Types
- Read History Types
- CalcDevice
- Application Id's
Other links:
Overview:
The ConSysKernel API contain all the core code for the ConSys control system. This includes all base classes for:
Database handling
Data values
Data Requests
Devices
Dataservers
etc.
History Types:
ConSys record and maintain value histories in memory by different methods dependent on use. Devices can make use of three different kind of histories: 'Reduced Read/Device Histories', 'Common device write history' and 'Parameter specific write histories'. In addition to this data can be logged for permanent storage to the SQL log database(s). There are two versions of SQL log databases - The original type logged to by the DataLogger application. - and the new device based logging to database, Log Database 2020.
Reduced Read/Device Histories:
These history types store data for each individual parameters and is typically used for readings from a device - but can be used for writings as well. Every time a device get a new reading from the hardware the value is stored in the history buffer. The history buffer store only the value and the time. No other information is stored. The history buffers can reduce the data by averaging in several steps. The number of points in each step and the amount of averaging is hardcoded into the history type - see the history type table below. This history type is implemented for floating point values and WORD values. The bit conversion used in the crateConvBase devices (see below) can - however - extract bit histories from the individual bits in a word history.
Common device write history:
The common write history buffer store one common list of write values for each device. The size of the list is hardcoded into the devices - the default size is 1000 value. The full ConSys data value and its related address is stored in the list - i.e. all information of source, time, user, application etc. that is in the value class is stored and returned when the history is requested. When a device receives a request for a specific parameter, the device ran through the common history list and extracts all values for the requested address. The draw back with this history type is that a parameter that is written to often fills up the buffer fast.
Parameter specific write histories:
Write history stored separately for each parameter in the device. Store a list of values as send from connected clients. The full ConSys data value is stored in the list - i.e. all information of source, time, user, application etc. that is in the value class is stored and returned when the history is requested. The size of the history lists is hardcoded into the device - the default size is 100 values.
In some devices using parameter specific write addresses, the address field a5 is used as a option filter. Bit 2 (value 4) in these devices can be set to get a larger write history (1000 values) for the given parameter.
Request of histories from applications:
Application can make two kind of history requests:
Demand Write - Detailed history:
Return: Parameter specific write history if present, otherwise common device
history if present.
Demand Read - As in CsPlot:
Return: Reduced read/device history if present, otherwise as 'Demand Write -
Detailed history'
Use of Histories in standard devices:
Storage Device:
- 'Reduced read/device history' for floating point parameters. History type obtained from database.
- 'Parameter specific write history' for all parameters.
- 'Address field a5 bit 2': If set, the write history will be large (1000) for this parameter.
CVdCalc Based devices (this includes many small devices for instruments, and a lot of virtual devices):
- 'Reduced read/device history' for floating point parameters. History type obtained from database.
- 'Parameter specific write history' for all parameters.
CCrateConvBase based devices (ModBus, G64, CAEN, VME)
- 'Reduced read/device history' for floating point parameters and Word's. History type obtained from database.
- 'Parameter specific write history' for some parameters. (device dependent)
- 'Address field a5 bit 2': If set, the write history will be large (1000) for this parameter.
- 'Common device write history' for with no parameter specific write history.
Other device types:
The base device class implements use of the common device write history - but the actual use of histories depend on the device.
Write History Types:
From version 1.47.751.790 (23. may 2024): For some devices (CStorageDevice, CVdCalc Based devices, CCrateConvBase based devices) the parameter specific write histories are changed from hardcoded sizes to user defined sizes based on a new interpration field, writeHistoryType, in the SQL configuration interpretation table.
History Type: The history type defines the combination of the values 'Maximum Age', 'Minimum Size' and 'Maximum Size'.
MaximumAge: Values with timestamps witch are older than specified by maximumAge will be deleted from the write history - keeping at least minimumSize values independent off age. The deletion age check could take place periodically - or at device startup. The purpose of the age parameter is to avoid taking up memory on the device computers of to old values.
Minimum Size: The minumum number of values in the write history. The history will never be reduced below this number of values even if values are older than the age limit.
Maximum Size: The maximum number of values in the write history. When this limit is reached adding a new value will delete the oldest value. (similar to what happened with the write size in earlier versions.)
Write History Type | Maximum Age (days) | Minimum Size | Maximum Size | Comment |
0, Default | 365 | 10 | 200 | |
1 | 0 | 1000 | 1000 | No maximum age, 1000 values |
2 | 365 | 20 | 1000 | |
3 | 5*365 | 100 | 1000 | |
4 | 5*365 | 20 | 200 | |
5 | 30 | 100 | 10000 | Meant for temperary use during debugging of problems |
6 | 0 | 10 | 10 | No maximum age |
7 | 7 | 5 | 50 | |
8 | 1 | 10 | 100 | Only one day history, primary meant for test |
9 | 1 | 0 | 5 |
Reduced Read History / Device history types:
Most devices implement read histories - and in most devices these are specified in ConSys SQL configuration database through the interpretation. The read history types availeble are in the lists below.
Remark: The memory used by the history types depends on the data type. Each point in the history will use 10 bytes + the size of the data type stored (double: 8 byte, word: 2 byte).
Remark: For double interpretations, a read and a write history
Id |
Description |
Definition |
0 |
No history |
No history stored |
1 |
Standard 24 hour |
150 points unreduced (input rate 200 ms => 30 s) |
2 |
Standard 48 hour |
300 points unreduced (input rate 200 ms => 1 min) |
3 |
1 hour med, 24 hour low res |
2 points unreduced |
4 |
24 hour low res |
2 points unreduced |
5 |
14 days |
500 points unreduced |
6 |
Standard reduction, 5000 points |
150 points unreduced (input rate 200 ms => 30 s) |
7 |
Standard reduction, 7500 points |
150 points unreduced (input rate 200 ms => 30 s) |
8 |
Standard reduction, 10000 points |
150 points unreduced (input rate 200 ms => 30 s) |
9 |
Standard reduction, 15000 points |
150 points unreduced (input rate 200 ms => 30 s) |
10 |
10000 point raw, 48 hour reduced |
10000 points unreduced |
11 |
2000 point raw, 5 hour reduced |
2000 points unreduced (input rate 200 ms => 400 s) |
12 |
2000 point raw, 50 hour reduced |
2000 points unreduced (input rate 200 ms => 400 s) |
13 | 30 days |
500 points unreduced (input rate 200 ms => 100 s) 720 points/ 25 (5 sec/6 minutes) 300 points/5 (25 sec/2 hours) 11000 points (4 min/ 28 days) |
14 | 10k points raw 10k points div 10 (new from v748, 17/5-24) |
10000 points unreduced 10000 points points/10 |
15 | 10k points raw 10k points div 50 (new from v748, 17/5-24) |
10000 points unreduced 10000 points points/50 |
100 |
500 point |
(input rate 200 ms => 1.7 min) |
101 |
1000 point |
(input rate 200 ms => 3.3 min) |
102 |
2000 point |
(input rate 200 ms => 7 min) |
103 |
5000 point |
(input rate 200 ms => 17 min) |
104 |
10000 point |
(input rate 200 ms => 33 min) |
200 |
Device specific: Beam Current |
5000 points unreduced (input rate 50 ms => 4 min s) |
201 |
Device specific: I*Tau |
50 points unreduced (input rate 50 ms => 50 s) |
202 |
Device specific: Lifetime, tau |
100 points unreduced (input rate 50 ms => 50 s) |
203 | A2 Beam beamcurrent |
1500 points unreduced (input rate 20 ms/30 minutes) 300 points/5 (100 ms/30 seconds) 1200 points/20 (2 s/1 hour - added space for marks) 30000 points/15 (30 s/2 weeks incl marks) Marks every 2 minute, 3 points/mark |
204 | A2 I*Tau |
1500 points unreduced (input rate 20 ms/30 minutes) 300 points/5 (100 ms/30 seconds) 1200 points/20 (2 s/1 hour - added space for marks) 30000 points/15 (30 s/2 weeks incl marks) Marks every 2 minute, 3 points/mark |
205 | A2 Tau |
1500 points unreduced (input rate 20 ms/30 minutes) 300 points/5 (100 ms/30 seconds) 1200 points/20 (2 s/1 hour - added space for marks) 30000 points/15 (30 s/2 weeks incl marks) Marks every 2 minute, 3 points/mark |
206 | Radiation Monitor |
120 points unreduced (input rate 1 s => 2 minutes 20000 points / 60 (1 minute/ 5.5 days) 5000 points / 30 (30 minutes/ 104 days) |
Word and (and Boolean) history types:
5000 | 500 points |
5001 | 1000 points |
5002 | 1500 points |
5003 | 3000 points |
5004 | 5000 points |
5005 | 10000 points |
5006 | 100 points (from version 1.26.136.545) |
Bit/Words defined in the same device word share one history buffer. A new
entry is added to the history buffer whenever the common word value is changed
(i.e. every time a bit is changed). The length of the history buffer is chosen
as the longest history defined in the database for the set of parameters
belonging to the same device word. If no histories are defined the minimum
history of 500 points is chosen.
(The meaning of device word can vary. In CrateConv based devices bits are
not stored individually but defined and stored in a word - this word is the one
used in the history, i.e. there is a history buffer per G64 word.)
Text history types (from ConSys version 1.26.137.545):
6000 | 25 points |
6001 | 50 points |
6002 | 100 points |
6003 | 200 points |
6004 | 500 points (new from version v748, 17/5-24) |
6005 | 1000 points (new from version v748, 17/5-24) |
Date (Time) history types (from ConSys version 1.26.137.545):
7000 | 100 points |
7001 | 200 points |
7002 | 500 points |
7003 | 1000 points |
7004 | 2000 points |
CalcDevice:
Base device class calculation devices etc. Has basic functionality for making a virtual or real device.
New from version 1.28.317.579 (19/12-2009): Handling of disconneted source parameters and common device status parameters.
Common device status parameters:
Addres type: 100, Calc Device Status and control
Status parameters for source client connection
Description | Suggested surname | Adressed (a0) | Data type |
Client connection ok, all parameters connected | clientCon | 0 | Boolean |
Number of unconnected parameters | notCon | 1 | Word |
Total number of source parameters | nuSource | 2 | Word |
List of connected parameters | connected | 3 | Text |
List of unconnected parameters | notCon | 4 | Text |
Application Id's:
The ConSys data values has an DWORD application-id that can be set from an application to identify itself when values are returned from a device. The application ids are built from a random or serial number and an application specific number. The random number is in the lower WORD of the application-id. The application specific number is in the upper WORD. The 12 least significant bits in the upper WORD are reserved for specific application id, see Application Id's below. The 4 most significant bits are 'application' type bit filter. If no specific application id is set, the upper WORD will be 0.
Application type bit filters
Application type bit filter | Id | Description |
ConSysLoader | 0x10000000 | ConSysLoader filter, bit set if application is ConSysLoader/ConSys service |
CalcDevice | 0x20000000 | CalcDevice filter, bit set for CalcDevice based devices (each CCalcDevice has it's own application id |
CsAPI | 0x40000000 |
Application Specific Id's
Application | Application Specific Id |
ConSysLoader I0 | 0x00010000 |
ConSysLoader I1 | 0x00020000 |
ConSysLoader I2 | 0x00030000 |
Resto | 0x00100000 |
Console | 0x00200000 |
CsPlot | 0x00300000 |
RampControl | 0x00400000 |
DatabaseEditor | 0x00500000 |
Datalogger | 0x00600000 |
ConSysLog | 0x00800000 |
DafLoader | 0x00A00000 |
FaradayCurrentDisp | 0x00B00000 |
CsWebWriter | 0x00C00000 |
SimpleWebWriter | 0x00D00000 |
TopoScan | 0x00E00000 |
AstridElOp | 0x00F00000 |
BeamCurrentDisp | 0x00100000 |
CsCompare | 0x00200000 |
See the file 'Indices.h' for up to date details of application ids
Last Modified 31 May 2024