This document as a preliminary design note for the ConSys System, ConSys, console program. A test implementation using MFC and controlbars is under construction.

Console program

The console program is supposed to be the main client program on operator stations. The purpose of the console program is to act as the user interface to the ConSys control system - displaying acquisition values and performing on-line control of the hardware. It has a number of predefined control pages as well as user defined control pages. Control pages is build by standardized blocks, in text or graphic format.

Layout

The basic functionality of the console program follows windows Single Document Interface (SDI). It has a standard windows menu with the conventional functionality. A docable toolbar, by default placed at the top of the window just below the menu bar, contains buttons for fast selection of console pages. At the bottom of the page there is a status bar and to control windows. The center of the window contains the selected console page, build from standardized blocks. The console program is, like any other windows program, scaleable in size. The figure below shows a rough sketch of the console layout:

Toolbar(s)

The graphical layout and functionality of the toolbar will be Microsoft's standard toolbars used in many commercial programs, like Word, Excel etc. The toolbar can be placed either in the top, the bottom, one of the sides of the window, or in a separate window by drag and drop. It is composed of buttons for standard system pages, defined by the system administrators, and buttons for user defined pages. Additional buttons for common operations may be optional.

Console pages:

Each console page is build from a number of console view blocks, as seen in the example above. Each view block can contain several parameters. Acquisition and status parameters can be displayed. Control parameters can be displayed and selected for control. Binary controls (control bits) can be set directly. View blocks define a tab order for all controls in the block. The console page defines a tab order between blocks. The tab order for all parameters on a console page is given by first following the tab order inside a block, and at the end of the block tab order, following the page tab order. Tab orders are used in selection of parameters to the control window.

The simplest console view block is a single (acquisition) parameter in text format. The width of a single parameter text block is half of the console page view port (inside of control page window). The height defines the smallest possible height of view blocks. View blocks can in general be either half or full with and have heights which is an integer times the height of the single parameter text block. The largest possible view block will use a full console page. The functionality of view blocks is the only thing defined by the console program. Its up to the view block itself to define the display format, which can be either text or graphic based. This will ensure maximum flexibility when defining the console page.

The console page/block functionality will be discussed later in ConSys interface.

Status bar

The status bar is meant for a display of the current status of the system. It has not been decided what to display in the status bar. One use of the status bar could be to show the last error message from the ConSys system - or perhaps just information about, that a error message or a warning has appeared in the event log.

Control windows

The control will be based on a system with two optical encoded digital potentiometers like the existing system at ASTRID. The existing system will probably be slightly modified - instead of the top/bottom selection switch there will up/down buttons. The potentiometers is connected to the controls selected in the respective control window. The selection method is very important for the daily use and therefore has to be considered carefully - a final decision of the functionality has not been decided yet. The main problem is how to select the parameters for control. Different solutions is presented below.

What must be included in the control window

The control window should must an analog display of the control and corresponding acquisition value. A digital (text) display of the control value is also needed. It should be possible to change display and control resolution. Usually, control will be on analogue values, but for special cases it should be possible to use binary control as well. Keyboard input of analogue/binary control values should also be possible.

Control selection, method 1:

Make a system exactly as the present system in the ASTRID console program. Parameters are selected by clicking on the parameter name to enable selection and thereafter on the control in one of the acquisition windows. Each control value can have two control parameters, selected with the top/bottom switch.

Control selection, method 2:

In this method, the top/bottom switch is substituted with up/down buttons. Each control window will only have one control value. New control values are selected either by the mouse, as in method 1, or by the up/down buttons following the control tab order in the view blocks. The efficiency of this method depends very much on a careful design of view block/tab orders.

Control selection, method 3:

This method is a bit more refined and in a way combines method 1 and 2.

With this method, a number of parameters (up to 4 in the picture above) can be selected for control. Parameters are selected by clicking on the parameter name to enable selection and thereafter on the control in one of the acquisition windows. Double clicking a selection will remove it. Changing the active control between the selected parameters can be done either by the mouse by clicking at the corresponding radiobutton or by using the up/down controls on the control box. The action performed when using the up/down buttons will depend on the number of selected parameters in the control window:

0: The first/last parameter in the control parameter tab order is selected for control.

1: The next/previous parameter in the control parameter tab order substitutes the selected parameter in the control window.

>1: The control value marked by the radio button is the one being controlled. Using up/down will shift the radiobutton selection up/down.

Other methods, perhaps using history list or many/more control windows should also be considered.

Console page setups

Before a console page can be defined its view blocks must be defined. View blocks can be either predefined, as is typical the case for a graphical display of part of the hardware, or forms without predefined parameters. Form based view blocks must have parameters selected before/when they are added to a console page. The positioning of view blocks on the screen has not been decided yet - it could be either automatic, semiautomatic or fully manual - we will se when the stuff is implemented.

All setup pages will be stored in a format to be defined in a common database. Some pages will be locked and can only be changed by system administrators. These are base pages used by all operators, and should include all system parameters with a convenient ordering - for ASTRID much like the ordering in the present control system. Different users can create and store there own setup pages. It should be possible to create 'private' pages, which can not be used by other users, and public pages available for all users. All predefined pages will be available for fast access through the toolbar. Custom toolbars with custom user pages can be added to the toolbar. It should be possible to save/load custom setup for the console program - including custom toolbars.

Storing/Retrieving of control values

Each console page has a history list of control values. It is meant for an easy way to come back to a given setting. The history list will be a stack of control sets, each containing all control values on the page. The operator can store (push) control values on the stack whenever he wants, and recall (pop) all control values again at any time. The list will operate as a stack - but it should also be possible to restore a control set from any level in the stack. The stack will only store a limited number of control values (5-10) - storing more sets than the stack height will just course the oldest values to fall out of the bottom of the stack. A control set can also be stored with a name. Control sets stored with a name has to be deleted explicit. Stored control values for a control page is kept while other pages is in use. All stored values is only stored as long as the console program is running.

Device pop-up dialogs

All parameters in the system has a device pop-up dialog. This dialog has all acquisition, control, and status parameters related to the parameter; As a example, an acquisition parameter displaying a power supply's voltage has a link to a pop-up dialog with all controls and readings for that supply. In practice, several parameters will be linked to the same dialog. When a user clicks on a parameter with the right mouse button, the dialog should pop-up and show the current status of the parameter. It should be possible to set control bits from the dialog. It is possible to allow control of analogue control values as well - this has to be decided at a later stage.

ConSys interface

This section discuss the internal structure used in the software development. The structure of the console pages replicates the structure of the commands needed to access the LSS kernel software. When a new page is selected, a request for parameters is generated by letting each view block generate its own request, and then let the console page collect these request to one common request. The handle for each block, which would probably just be a pointer to the block, is build into the request list.

Ideas

Last Modified 11 January 2019