User manual: Database Editor
Status:
This information applies to Database Editor version 1.47.551.251 (27. marts. 2023)
The content of this manual is only partly maintained.
Contents:
- Overview
- Display Group Permissions
- Batch Copy Parameters
- Batch Create Graphics Page
- Device definition / device loading
Other links:
- Consys home page
- ConSys User Manuals
- Console Database tables
- ConSys Interpretations
- ASTRID2 Nomenclature
Overview:
If usage string starts with the character '#' the '#' is removed from the string and the corresponding field is not enabled in the DatabaseEditor.
Display Group Permissions:
The Display Group permissions is used by the console to limit the available page groups and graphic pages to those with the correct permissions set. The user must have at read access to at least one security group for a given ‘Display Group’ in order to have access to the page groups and graphic pages belonging to the given display group. Graphic pages defined in the SQL ‘GraphicPage’ table links to a display group by the field ‘DisplayGroup’. The same is the case for the console pages defined in the SQL table ‘ConsoleGroup’.
Batch
Copy Parameters:
New method from version 1.31.530.219
Should be used with care - not much error checking, and done is done (no undo etc...)
The bacth copy parameters is an extension of the 'Copy elements' method. The bacth mode is meant for copying settings for devices with many similar clusters. The parameters from the source cluster is copied to the destination clusters as specified in the bacth copy file. The command file is text based, where the first character in each line specifies the use of that line:
S: The source cluster name, only one source
can be defined
Q: Additional SQL filter, can be used to select or avoid certain surNames etc.
Only one SQL filter can be defined
P: The name of the destination cluster. The fields following a P line specifies
the options for that cluster
O: Options.
M: Modify existing parameters (if not defined, only add new
parameters)
P:Modify existing but keep console position numbers
N: Modify existing, but keep negative position numbers
C: Comment - not parsed.
E: End. Stops parsing, rest of input file is ignored
F: Field value. Used to modify field values when copying from the source
cluster.
d: If specified, the deviceId is changed to the spefied value
a: Set one of the general purpose address fields a0 to a8 to a
specific value
a+:Add the specified value to the source value
A1:Storage device add value to source value. The value added is
dependent on the data type specified in a0. The values are added to the address
field a1.
s: Set general purpose address string.
L: Log group. Set the mode of how the log group id is updated.
K: Modify: Keep Existing loggroup, New: Source loggroup
S: Set source loggroup id
V: Set loggroup to the specified value
A: Add specified value to source loggroup id
I: Ignore changes
A: Ignore adding new values to this cluster
I: Ignore interpretation changes to parameters in this cluster
Batch file format:
S:<Source Cluster Name>
Q:<SQL filter string>
P:<Destination Cluster Name>
O:M
F:<d|a<a index 0..8>|a+<a index 0..8>|s<s index 0..1>|A1>;<Value/A1
value list>
<A1 value list> = <double add>,<bit add>,<word add>,<string add>,<time
add>,<pulse bit add>,<data value add>
Examples:
S:P2_READ
Q:(SurName != 'lowLim') AND (SurName != 'upperLim')
P:P2_READ_C1
P:P2_READ_C2
O:M
F:d;100
F:a+2;10
F:a8;1234
F:A1;1,2,3,4,5,6,7
F:s0;This is a test text
F:s1;Another test
P:P2_READ_C3
L:K
L:S
L:V:111
L:A:-100
Batch
Create Graphics Page:
New method from version 1.31.615.220
Should be used with care - not much error checking, and done is done (no undo etc...)
The batch create parameter page tool is used to generate/update a previous generated graphich page base on a text based script file. The tool works on a specified graphic page, specified by the graphic page id. The tool can generate a page consisting of parameters from similar clusters. A source cluster must be specified. All parameters found in the source cluster on the graphic will be created placed for all destination clusters. The x and y position of the destination parameters will be updated according to the script. The first charecter in each line defines the use of the line:
C: Comment - everything on this line is ignored
G: Graphics Page Id (Page field in dbo_ConsoleGraphParameter)
S: The source cluster name, only one source can be defined
D: Destination cluster name. The fields following this line is the settings related to this cluster.
X: Absolute x position. The position is relative to the source parameter position.
x: Incremental x position. For each destination cluster following this definition, the incremental x position will be added to the absolute x postion.
Y: Absolute y position. The position is relative to the source parameter position.
y: Incremental y position. For each destination cluster following this definition, the incremental y position will be added to the absolute y postion.
H: Header: Specifies a new header text.
Batch file format:
G:<Graphics Page Id>
C:<Comment>
S:<Source Cluster Name>
P:<Destination Cluster Name>
X:<Absolute x position>
x:<Incremental x position>
Y:<Absolute y position>
y:<Incremental y position>
H:<Header>
There is two database tables related to graphics pages:
dbo_GraphicsPage: This is the table where the page (and background bitmap) is defined, one entry per page
Note there is both a record Id and a GraphControlId in the dbo_GraphicsPage. The Id is used for ordering in the Console, whereas the GraphControlId is the one linked with the Page field in dbo_ConsoleGraphParameter.
dbo_ConsoleGraphParameter: This is the table which defines all the controls, one entry per consys parameter
Example:
G:301
C:This is a comment
S:UBX111TBTast2
D:UBX112TBTast2
y:30
H:UBX112
D:UBX113TBTast2
H:UBX113
D:UBX141TBTast2
X:450
Y:0
H:UBX141
D:UBX142TBTast2
H:UBX142
Device definition / device loading:
Since about 2017 (version 1.?.?.?) it has been possible to also define devices in the ConSys Database, and this is today the preferred method. A few old devices may still only load through local configuration files, but most devices has been converted to support database configuration. New devices may not support local configuration files.
Devices are configured in dbo_DeviceConfiguration with helper tables dbo_DeviceClass (list of all different devices (different device classes) and dbo_DeviceConfigurationDefinition (definition of the use of the general database fields). The devices class indices in the device class must match the class id’s defined in ConSysKernel, indices.h.
Each DeviceConfiguration has a unique ID (DeviceConfigId), which is linked to a unique DeviceId (from dbo_DeviceLocation)). The reason for multiple DeviceConfigId's for a given DeviceId' is to make debugging easier (allows for separate (alternative) configuration for debugging of a device). Typical the unique DeviceConfigId is the same as the (unique) DeviceId (for the "production" DeviceConfigId)
Each unique DeviceId (from dbo_DeviceLocation) has a defined Frontend and LoaderInstance, where the device is intended to run. Each DeviceConfiguration has an alternative computer id (and alternative loader instance) where the device CAN be loaded (for instance for debug purpose). If the alternative computer id is positive the device will not be loaded on the (intended) frontend computer (but a device will keep running on the frontend until the frontend kernel is restarted). A device is only loaded if the enable flag is set. Remark that client computers apart from the computer running a local copy of a device will always look for a device at is original location defined in the device location table.
- Simple debugging (single DeviceConfiguration): Set the ComputerId of the debugging computer in the alternative computer id field and start the debugging kernel with the /ld option. The original device will keep running on the original frontend UNTIL the original frontend is restarted. An easy way of disabling the alternative computer is done by negating the alternative computer is (this way it is easy to enable the alternative computer again). Other computers will look for the device at the (original) frontend. If it is a device which communicates with an instrument (or something) remember to disable the communication (using the device enable/disable parameter). For this method device configuration will be same for debugging as for the "real" device.
- More advanced debugging (dual DeviceConfiguration): Have an extra DeviceConfiguration (typical with a DeviceConfigId which is +20000 or +50000 of the DeviceId). Set the ComputerId of the debugging computer in the alternative computer id field and start the debugging kernel with the /ld option. The original device will keep running on the original frontend unless the original DeviceConfiguration is disabled and the original frontend is restarted. Other computers will look for the device at the (original) frontend. If it is a device which communicates with an instrument (or something) remember to disable the communication (using the device enable/disable parameter). For this method the device configuration can be different for debugging as for the "real" device. This method is properly a little more "safe", since less editing of the original DeviceConfiguration is likely to happen (but requires an extra DeviceConfiguration). In this way the device will also be loaded if the ConSysLoader is restarted at the original location.
- Separate device: For more throughout debugging a separate (test) device (with separate test parameters) may be needed. This will typical then only need one DeviceConfiguration (unless different device configurations are to be tried (tested)).
When using the local device (/ld) option the local devices "reuses" the parameters for the original device, i.e. one does not have to define extra parameters. Dependending on the device under debug it may be needed/a good idea to copy the persistent stored data for the device from the original device location to the debug location.
Device load order:
- Enabled devices from local configuration file
- Devices from dbo_DeviceConfiguration, which is enabled and where the Frontend computer ID match the loading computer ID and which does not have a positive Alternative computer ID
- If the ConsysLoader is started with the Local Devices option (/ld), then enabled devices from dbo_DeviceConfiguration, where the Alternative computer ID match the loading computer ID will be loaded
A given (unique) DeviceID will only be loaded once on a given Frontend/LoaderInstance (but CAN be loaded on different Frontend/LoaderInstances).
How to create a new device (with existing types):- ??? Create a new record in dbo_DeviceLocation
- Hvorfor er hver device ikke forbundet til en given DeviceConfigurationDefinition (hvorfor har hver DeviceConfiguration sin egen DeviceConfigurationDefinition)?
- Hvad med Database update
Last Modified 13 December 2023