Hackathon Opening an OPI Outside of a Synoptic - ISISComputingGroup/ibex_developers_manual GitHub Wiki

Wiki > Project overview > Design documents > Hackathon - Opening an OPI outside of a synoptic

• Link to ticket on GitHub
• Link to original design document (superseded by this)

Add a tab to the IBEX GUI where OPIs for connected equipment can be viewed – similar to the LabVIEW tab in SECI (see figure 1).

Figure 1 - SECI's LabVIEW view

This may change on the day as we get going but it is something to get started with.

The BlockServer and GUI s communicate through two PVs; one for reading and one for writing:

• %MYPVPREFIX%CS:BLOCKSERVER:GET_SCREENS = returns the XML for the screens

• %MYPVPREFIX%CS:BLOCKSERVER:SET_SCREENS = sets the XML for the screens

The data sent over Channel Access will need to be zipped and hashed in the same way as the configurations and synoptics.

The BlockServer will be responsible for saving and loading a list of 'Device Screens'. It is proposed that these are stored in a separate XML file in the configuration or component: NDXXXXX/configurations/my_config/device_screens.xml.

The XML will be something like:

<devices>
    <device>
        <name>Eurotherm 1</name>             
        <key>Eurotherm</key>                 
        <type>OPI</type>
        <properties>
            <property>
                <key>EURO</key>
                <value>EUROTHERM1</value>
            </property>
        </properties>
    </device>
</devices>

A schema will also be required. It could look something like:

<complexType name="devices">
    <sequence>
        <element name="device" type="device" maxOccurs="unbounded" minOccurs="0"></element>
    </sequence>
</complexType>

<complexType name="device">
    <sequence>
        <element name="name" type="string" maxOccurs="1"
            minOccurs="1">
        </element>
        <element name="key" type="string" maxOccurs="1"
            minOccurs="1">
        </element>
        <element name="type" type="tns:type" maxOccurs="1"
            minOccurs="1">
        </element>
        <element name="properties" type="tns:properties" maxOccurs="1" minOccurs="0"></element>
    </sequence>
</complexType>

<simpleType name="type">
    <restriction base="string">
        <enumeration value="COMPONENT"></enumeration>
        <enumeration value="OPI"></enumeration>
    </restriction>
</simpleType>

<complexType name="property">
    <sequence>
        <element name="key" type="string"></element>
        <element name="value" type="string"></element>
    </sequence>
</complexType>

<complexType name="properties">
    <sequence>
        <element name="property" type="tns:property" maxOccurs="unbounded" minOccurs="0"></element>
    </sequence>
</complexType>

The PVs and logic should be implemented in such a way as to be optional, so if, say, the ESS didn't want the functionality it would be easy to exclude. The way the synoptics are handled is an example of how to do this.

The XML for the synoptic may need to change to allow device screens to be specified – this will need to be coordinated with the GUI side (see Task 5 in Section 3).

UNIT TESTS MUST BE WRITTEN!

It is proposed that it will be via the device screens that macros etc. are configured for an OPI. The synoptic editor will be simplified to just allow the already configured device screens to be used for creating a synoptic. In other words, if the device screen is not configured for an item of kit, it will not be possible to add that kit to the synoptic.

Note: We may need a quick way to launch the "device screen configurator" from the synoptic editor

Tasks:

1. Connect up to the new PVs and decode/encode the data
2. A new perspective/tab for showing the OPIs (see mockup in figure 2)
3. A dialog for configuring the device screens (see mockup in figure 2)
4. The synoptic editor will no longer need to allow editing of macros, but will need a way to pick the correct screen (and suggest defaults)
5. The synoptic XML may need to change to handle device screens (this will need to be done in collaboration with the people working on the BlockServer)
6. Unit tests
7. GUI tests (ask Ian for help)

Figure 2 - Mockup of the Device Screen view with the configuration dialog

It might be useful to be able to start and stop the BlockServer without having to use ProcServCtrl while developing. To enable this follow these steps:

1. Open C:\Instrument\Apps\EPICS\start_inst_full.bat in Notepad
   • Comment out the line call %STARTINSTDIR%ISIS\inst_servers\master\start_blockserver.bat
   • Save the changes
2. Open `C:\Instrument\Apps\EPICS\ISIS\inst_servers\master\start_blockserver_cmd.bat' into Notepad
   • Comment out the %HIDEWINDOW% h line near the top
   • Replace %PYTHONW% with %PYTHON%
   • Save the changes
3. Run start_inst.bat. This will start the system without the BlockServer
4. From the command line run start_blockserver_cmd.bat to start the BlockServer.