Implementation details

The special focus here is on the implementation flow!
TIP If possible template proposals are made for the respectively implementation issues!

Implementing description

Providing of a new device class/equipment model

(e.g. new FESA class or not previously used DeviceAccess equipment model(e.g. only used at Unilac))

1. Assign DeviceControl device type name

(for mapping of DeviceType to DevCtrDeviceType to integrate the (LSA) device in the DeviceControl application):
Check in DevCtrlCommonDevice#createDevCtrlDevice:
Does a DeviceControl device class already exist for monitoring the new device class, e.g. common device class?

private static AbstractDevice<?> createDevCtrlDevice(final AbstractDevCtrlDevice device) {
   :
   switch (device.getDevCtrlDeviceType()) {
   :
   case AbstractDevCtrlDevice.COMMON_TYPE:
            devCtrlDevice = new DevCtrlCommonDevice(device);
            break;
   

DONE enter the corresponding DeviceControl device type in

choice-no continue as follows:
  1. AbstractDevCtrlDevice
    • define a new DeviceControl type value
      • if the DeviceControl device type has to be visible in table area (= table row), additionally insert this value in the TABLE_DEVICE_TYPES
      • if the DeviceControl device type is a driven device, additionally insert this value in the DRIVEN_DEVICES
  2. LsaDeviceAdapter
  3. DevCtrlContentModel
    • assign DeviceControl device type in createDevCtrlDevice(...)
    • If the DeviceControl device type has to be visible in table: ensure that the DeviceControl device type is known either as
      • driven device (actuator is implicitly integrated, actuator type): DRIVEN_TYPE_POSITIONS
      • actuator (without a driven device known by control system (i.e. in LSA))

alert Unfortunately the generation of the table is extremely complicated implemented so it will be definitely an advantage if there is already a suitable (!) DeviceControl device type to introduce a new table row (type).

info The assignment between a FESA steppermotor and a driven device is configured. This is always under consideration and should not lead to any issues!

TIP Template for DeviceControl device types:
  • only visible in picto area (not movable, bottom area)
  • movable, i.e. also visible in table area
    • if there is an actuator with no driven device, DeviceControl device type VALVE_TYPE
    • if there is a driven DeviceControl device type known by the control system, DeviceControl device type CUP_TYPE
    • if there is a driven DeviceControl device type not known by the control system, DeviceControl device type FLUOR_SCREEN_TYPE
    • if there is a driven DeviceControl device type known as well as unknown by the control system, DeviceControl device type DISC_TYPE

2. Implementation of feature(s) concerning the new device class:

Is the feature to implement an extension of an already existing (DeviceControl) device class?

DONE Check if it is sufficient to extend an existing DeviceControl device or even to create a subclass of an existing DeviceControl device (cf. steppermotor package). However the procedure is always the same: Depending on the device infos required for the implementation define resp. override the following methods. The methods listed here correspond to "DCL API categories":
  • Device Info: (extension of common (= DCL specific) device info
  • Configuration:
  • Status (only if going beyond evaluation of common and detailed status. Otherwise all items should hopefully be implemented)
    • updateStatus
    • updateStatusException
  • Acquisition
    • readAcquisitionFields (used in updateAcquisition)
    • updateAcquisitionException

choice-no A new DeviceControl device class has to be implemented. Additionally to the items listed above the following has to be considered:
  • clarify where to exactly locate the new class in the domain package. Subsequently continue with the procedure described above.
  • define the field "acquisitionParameterName".

alert Currently only a single acquisitionParameterName can be defined per DeviceControl device!

GUI modification

Table area
Add another feature in selection mode

TIP Template to insert a new feature in table area: DRIVING (moving an actuator).

Add a new device type row

TIP Template PROF_TYPE_POSITION (Profile grid) as starting point.

Remove an existing device type row

Remove the relating definition of e.g. TRAF_TYPE_POSITION (Trafo device) as starting point for an orientation to delete the corresponding row.

Picto area
Implement a new filter

TIP Template: definition of APP_EVENT_SELECT_FREE_TEXT_SEARCH_FILTER.
Add a new device icon

Synonym: pictogram. Pictogram constants are defined here. The only thing you have to do:

TIP Template: Definition of PICTO_SLIT_TWO_MOTORS.

Implement a new feature

Controller Integration
Table area
Picto area

Viewer Integration

If a new feature is implemented using a new dialog s. Implement a new dialog

TIP The definition "COMMAND_DEVICE_DISTANCE" is commented like the complete implementation procedure sequence (integration of distance feature) should be implemented but commented!

Implement a new dialog
  • Implementation
TIP Template: ComparisonOfDeviceValuesDialog.

Modification/addition of an existing feature

Use startpoints for Table area integration resp. Picto area integration and find out by following the call hierarchy where the modification has to be implemented.

Hardcoded specifities

Following specific features have been implemented by use of hardcoded definitions

Select and restrict chain devices (for testing)

In order to focus on the devices of interest, the devices to be monitored by DeviceControl can be selected: To do this modify in DevCtrlMainModel#getDevicesWithoutRemoved(), e.g.:
 getDevicesWithoutRemoved()
 :
 clearedDevices.removeIf(
                d -> removedDevices.contains(d) || !(d.getName().startsWith("GTE1DI1P") && !d.getName().endsWith("V"))
                        && !d.getName().startsWith("GTE1DG1"));
 :

Provided that a chain will be selected which contains the related accelerator zone this will reduce the devices to be monitored to:
  • GTE1DI1P
  • GTE1DI1PP
  • GTE1DG1
  • GTE1DG1 _P

-- SigridHeymell - 03 Aug 2022
Topic revision: r21 - 19 Aug 2022, SigridHeymell
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback