Common–EGSE & Test Scripts: User Manual

Although this manual is intended for operators, i.e. those users that operate the system, perform the tests, and execute the procedures, some sections will be dedicated to administrators or developers when there is a need in the context of the section. Please note that this user manual is complementary to the PLATO Camera Ground Test Commanding Manual [PLATO-KUL-PL-MAN-0004] with only minimal overlap.

Since we assume the Common-EGSE and Test Scripts have been installed and configured, the starting point for you is the Process Manager. The Process Manager (PM) provides a GUI which is started on the egse-client and looks much like the screenshot below. The PM GUI can be started either by clicking its icon on the desktop or from a terminal with the pm_ui command.

The Process Manager GUI represents the state of the system. It provides information about all the processes that are needed to perform the camera tests. These processes are divided in four categories: Core services, File Generation Processes, Non-Device Control Servers, and Device Control Servers. The screenshot below is taken from CSL and the GUI only shows processes that are applicable to CSL. The left column of services and processes are common for CSL and all the test houses. The right column with Device Control Servers is test house specific and is defined by the content of the Setup. [XXXXX explain what the Setup is and where more info can be found].

The red and green bullets in the PM GUI describe the state of the service or process. When the bullet is green the process is running as expected, when the bullet is red the process is not running. For some devices the bullet can become orange to indicate that the control server process is running, but the device is not connected and can therefore not be commanded. The icons at the right of the processes are for starting/stopping the process. Some processes can be started in simulator mode (toggle the device icon) and some of the processes have a GUI associated that can be started from the PM GUI. Please note that none of the core services can be started from the Process Manager GUI. Core services are managed by the Systemd services of your Linux system and when stopped or crashed they will be automatically restarted.

The Process Manager is fully explained in its own section The Process Manager GUI in Section 3.2.

The Process Manager presents you with a view of the state of the system and allows you to start and stop device processes and start some GUIs to manipulate certain devices and services. The main task for an operator to perform camera tests or alignment procedures is however to execute the test procedure as described in the TP-0011 Google Sheet for each of the test houses and in the ambient alignment procedure PR-0011 for CSL. These documents contain step-by-step as-run procedures that describe all manual interactions, tasks and code execution needed to successfully perform a camera test. Each of the rows in these procedures describe one action that needs to be successfully finished before proceeding to the next action. As said, this can be a manual interaction with a device, a task to be executed from a specific GUI, or a code snippet that needs to be executed in the dedicated environment. The Python source code from the as-run procedure will be executed in a Python Console that is used throughout the completion of the as-run procedure.

We recommend to use the Python Console provided by the PyCharm IDE. [XXXXX What about the Qt Python Console that is available from the e.g. CSL Commanding GUI?]

Your server is a powerful machine with one or two CPUs and a few tens of cores. This was chosen because we will have a lot of applications/services running, and they can take up different cores without being interrupted. The server also has several disks that are used for active data storage and data archive. The active data storage needs to be a fast SSD disk with enough space to store the data of a few test days. The disk needs to be fast because of the image data that is received from the camera. When the image data is not written fast enough the camera front-end electronics might generate a buffer over-full error hereby corrupting the image data for the current exposure. The archive disk is a normal SATA disk that can hold the test data for the whole campaign.

The client machine is a small desktop computer with preferably two large screens to place all the GUIs and the browser for commanding and monitoring the tests.

This section describes the Process Manager GUI.

This section briefly describes the CSL specific task GUI, the CSL Operator GUI.

The intent of the CSL Operator GUI is to simplify the work of the test operator at CSL when executing routine tasks to perform the alignment of the PLATO Cameras. At the top of the GUI you will find the tasks for taking a single position measurement, a circle around the optical axis, and a Hartmann measurement. Each of these task groups has a task to do the actual commanding and a task to reduce and analyse the data. Then, there are tasks that are grouped by components like the PUNA Hexapod, the Camera, OGSE, etc. Each of these groups contain tasks to perform a specific action on that component. When you hover over the tasks with your mouse, the documentation for that task will show up in a tooltip. Alternatively, you can right click on a task and select View source…​ to inspect the source for for the task.

For more information on the working of the Task GUIs, please go and read the section on the Tasks GUI in Chapter 4.

The DPU GUI is a (near) real-time viewer for the data that is received from the N-FEE. I say near real-time because the data comes with a small delay due to the nature of the interface and the inner working of the N-FEE. Image data e.g. can take up to four seconds to transfer from the N-FEE to the DPU Processor just for one frame of one of the four CCDs. The housekeeping data is only sent once on every (or right after) a synchronisation pulse, which takes 6.25s for external synchronisation measurements. Because of this delay, you need to be aware of the current operating mode and the synchronisation mode of your observation to estimate how long it will take before you can inspect the data. Sometimes its quick like with internal sync measurements of a partial readout and a period of a second versus full frame external sync measurements. Since mode changes only happen on the long (400ms) pulses, it can take up to 25s before you can see the change in the GUI.

The DPU GUI is usually started from the Process Manager GUI by pressing the UI button associated to the DPU Control Server. You can also start the DPU GUI from the terminal with the dpu_ui command. The DPU GUI always runs on the client machine in any test house.

To start up the DPU GUI, at least the core services need to be running on the server. The DPU GUI gets its information from the DPU Processor, so as long as this process is not running, you will see a CONNECTION LOST message as the N-FEE mode in the 'Mode Parameters' panel. As soon as the DPU Processor starts and connects to the N-FEE, the DPU GUI will receive data and update its displays. Whenever the DPU Processor loses connection with the N-FEE (e.g. because the camera was switched off) or the DPU Processor is terminated or crashed, the N-FEE Mode will show the CONNECTION LOST message again.

The CCD images are all oriented with the readout register at the bottom. The image that is visualised is a composition of —from left to right— the serial pre-scan pixels (25), the actual CCD pixels (2255), the serial overscan pixels (15), and on top of these the parallel overscan pixels (30). The red lines in the displays indicate the boundaries of the CCD pixels.

The four CCD image displays are build from a pyqtgraph widget. This means you have all functionality available for interactive inspection of the image. Please refer to the PyQtGraph documentation to learn the details. The most used mouse interactions are:

In Figure 3, we show the zoom window for CCD1. The image display is the same for the other CCDs and for the main DPU GUI window with all four CCDs. We see both sides of the CCD displayed next to each other in independent (pyqtgraph) widgets. Each side has the image data on the left and the histogram on the right. The histogram can be manipulated using the standard PyQtGraph interactions in order to change the color mapping or zoom and select the histogram range.

The right-side of the CCD is zoomed and we clearly see that there are 25 serial pre-scan pixels. The big cross is part of the simulated data in order to identify the orientation of the image (a debugging tool). In this right-side view you also see the small 'A' in the lower-left corner that you can use to bring the visualization back to the actual full size. Above each of the CCD sides are coordinates that represent the pixel position and the flux for that pixel where the mouse is pointed.

The two icons in the upper-right corner of the display allow you to (1) select and zoom to the brightest pixels in the display, and to (2) clear the image data. In de main window there is a third button per CCD that will open de image data in a separate zoom window like in Figure 3.

There is no functionality to save CCD images because all data is automatically saved in HDF5 files by the DPU Processor. The HDF5 file is fully explained in the Interface Control Document (ICD).

Describe the HK display…​

Describe the Register Map display tab…​ when is this updated? Can we freeze it? Can we filter?

What improvements could we envisage for the DPU GUI?

The toolbar is dedicated to the Python kernel that is used to execute the tasks. The left-most button can be used to restart the kernel. Do this when you want to start a fresh new Python Interpreter or when you need to change the kernel. The second button on the toolbar is used to open a Python Console that is connected to the currently running kernel. Pressing this button will open a window with a prompt where you can enter or paste Python code to be executed. Here you can also find back the code that was executed by pressing one of the buttons.

You might ask why you would need to change the kernel? Normally, you don’t need to do this and you can simply execute code from the Python prompt or by pressing buttons and running tasks. But it might happen that the kernel crashed or hangs due to a bug in the executed code. At that point you would need to restart the kernel. A second reason is when you want to use another kernel from the drop-down menu at the right end of the toolbar. By default, the plato-test-scripts kernel will be started if it is available, otherwise the fall-back kernel is python3. Please note that only one kernel can be managed from this application, and you can also open only one Python Console window.

All tasks are available in the Button Panel. The tasks are arranged in groups and in each group in columns of four tasks.

When you press a task button an associated arguments panel will appear below the button panel. Before pressing the Run button you can provide input for all the parameters of the task. Most of the arguments will have a simple builtin type like int, float or bool, but more complex argument types are possible and for some of those a special icon will appear on the right side to

TBW

XXXXX: update text below! As an example, when you press a task button, it will change color to indicate this task has been selected (see screenshot above) and an arguments panel will appear in the middle of the GUI. The set_trp1 task expects one parameter (temperature) for which no default was provided. The expected input is a float. When you press the Run button, the task will be executed in the kernel. All tasks are by default executed in the kernel. You will sometimes see that a task will execute in the GUI App or as a script, don’t use those options yourself unless you know what you are doing.

You might want to run tasks from the Jupyter QtConsole or any other REPL that you use. Since the tasks in the GUI as just like any other function, you can import the task and run the function from the Python interpreter. The only thing you need to know is where the tasks are defined, from which module they should be imported. In our PLATO project, all tasks are defined in the plato-test-scripts repository and they live inside the camtest.tasks package. It depends on the TAB and the location in that TAB where your tasks is defined. As an illustration, we start from the CSL Operator GUI (screenshot below) and select the Camera TAB and the Camera Switch ON button. This will open the arguments panel, and we see this task takes one argument, the hk_frequency. We would like to execute this task in the REPL instead of pressing the 'Run' button.

The example below shows how this is done for the Camera Switch ON and Switch OFF tasks. We import the tasks from camtest.tasks.shared.camera.camera in line [4]. In line [5] we print the documentation associated with this task and we see what the task does and what the parameters are (and their defaults).

Running the tasks is as simple as executing the function. While this specific task would open dialogs asking for confirmation when the task is run from the button, in this case, the input is requested in the REPL and you type your answer at the prompt.

Switching OFF the camera is equally simple:

Use the following commands in a terminal:

See the section [Update the Common-EGSE Software] on how to get the latest version installed in your environment.

TBW

Process Manager GUI or from the terminal…​

You can check this in a terminal with the following command:

If you need more information e.g. to debug which files are being used to save the observation data, add the --full option to the above command:

More information can be found in the

You can check this in a terminal with the following command:

You can check this in a terminal with the following command:

You can check this in a terminal with the following command:

You can check this in a terminal with the following command:

TBW