Implementation details

The special focus here is on the implementation flow!
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;
   

enter the corresponding DeviceControl device type in

• FESA-Klasse: LsaDeviceAdapter#checkDeviceInfo()
• DeviceAccess: LsaDeviceAdapter#checkDeviceAccessTypes() This should be all you need to do!

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
   • FESA device: assign in checkDeviceInfo()
   • DeviceAccess device: assign in checkDeviceAccessTypes()
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))

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).

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

Template for DeviceControl device types:

• only visible in picto area (not movable, bottom area)
  • DeviceControl device type POWER_SUPPLY_TYPE
• 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?

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
  • readSingleDeviceData (e.g. AbstractDevCtrlCommonActuator)
• Configuration:
  • readConfiguration (e.g. DevCtrlSteppermotor)
• 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

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".

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

GUI modification

Table area

Add another feature in selection mode

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

Add a new device type row

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

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:

• add a tooltip for the pictogram (updatePictoTooltips())

Template: Definition of PICTO_SLIT_TWO_MOTORS.

Implement a new feature

Controller Integration

Table area

• starting point: executeDeviceSelection(...) (performs mouse left-click in table area)
• Template: singlePressMeasureDialog

Picto area

• starting point: actionPerformed(...)

Viewer Integration

• Implement a new button in picto area
• Template: definition COMMAND_DEVICE_ON.

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

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

Template: ComparisonOfDeviceValuesDialog.

• Integration
  • Table area: e.g. starting point: field "singlePressMeasureDialog"
  • Picto area: starting point: field "comparisonValuesDialog".

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

• Devices cf. Hardcoded specifity devices
• ChainNavigator cf. Chain navigator hardcoded specifity

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