SwissFEL operation software meeting

Thursday 18 May 2017, 09:00 → 10:00 Europe/Zurich

Working group for SwissFEL operation panels and tools.

09:00 → 10:00 Open issues

Review open issues list

Convener: Didier Voulot

Minutes Nicole hiller:

Here comes the summary from our discussion today, please comment if you want anything added/changed, so we can decide how to proceed: 

———————————————

Update rate of panels/widgets

———————————————

There are currently several panels that use up a lot of performance when opened and it would be good if the update rate could be changed easily and that e.g. the panels per default start with a low update rate. This will become an even bigger issue once we move to 100 Hz with beam operation, but even now, e.g. the camera image display updates at roughly 6 Hz regardless of the actual trigger rate of the device. 

There are several options where to tackle this (widget-based, global for the panel, but set while designing the panel or global for the caqtdm session). 

 Suggestion: Check with Anton what he would recommend

———————————————

Dynamic generation of the macro list for the cainclude widget, based on a “list generating command”

———————————————

Cainclude offers the possibility to have one sub-panel included several times based on a static macro list which makes the maintaining slightly cumbersome if anything is changed and the initial generation of the list is done manually. 

E.g. you want to generate a display of all the quadrupole and corrector magnets along linac 1, sorted based on their z coordinate. 

If we could have the option to put the “list generating” command in the panel, then this list would be generated dynamically when the panel is called. 

Especially the sorting based on Z would be nice. 

The problem is, that ideally we want to have this rather generic and build up on a lookup method that is available on all platforms. 

———————————————

Scaled alignment of widgets based on a machine coordinate system / PVs

———————————————

For synoptic displays it is very convenient if you can scale the alignment of widgets within an area of a panel based on machine coordinates (could be given by PVs). This would e.g. allow you to easily generate a synoptic display for certain machine sections. E.g. show all BPMs and correctors with symbols along a certain section of the machine. And it would even allow you to make it dynamic e.g. a display of the bunch compressor that is automatically updated when the bunch compressor is moved. 

Or display a dot for the beam position based on the x and y readings of a BPM, or have a graphic for an undulator move based on the undulator position. 

———————————————

Wishlist what should be improved for plotting-display options

———————————————

Another thing we discussed was what features we would like in plotting tools and what should be handled in which way. 

Currently there are several tools available to visualize data be it EPICS PVs or bsread data. 

1.) Caqtdm stripchart widget (can display up to 7 EPICS PVs on a common time axis, but with only one y-axis)

2.) Caqtdm cartesian plot  (allows you plot up to 6 EPICS PV pairs in a single plot, currently also used to access the data-buffer and archiver)

3.) Stripchart (replaces the old strip tool) - PSHELL tool that allows you to make a quick plot of live data (PVs and bsread) for several channels in several sub-plots, data can be saved/logged, sampling interval can be specified and bsread streams can be filtered (e.g. based on values of streams and/or beam-ok-flag

4.) Correlation plot - PSHELL tool that allows a quick correlation of 2 PVs or streams

5.) Webinterface - Interface to set up quick plots with several PVs from the archiver or data-buffer for specific time intervals

Each of the tools have their advantages and disadvantages and none of the tools can really do “everything” that people have requested in the past.

Especially the issue of the data source and the ease of accessing data from the archiver/data-buffer is a big issue. 

Categories under which the features can be grouped: 

A) Data source (EPICS, archiver, bsread/data-buffer)

B) Display options (persistence, average, adding/removing channels, changing axes, number of channels, machine coordinates)

C) Filtering (based on: beam ok flag, time/bunch id, values of PVs/streams,…)

D) Correlation (quick check if signals are correlated)

E) “Easy-Analysis” (e.g. subtracting one channel from another, multiplication, scaling)

F) Data export/Logging (file format, archiver access, …)

This is a bigger task and should probably be coordinated from higher up, how we want to proceed there and which features should be implemented where. 

How should we proceed there?

---Comments Christoph--- 

 

Thanks for the nice summary. I have some comments to the various topics:

Dynamic generation of the macro list for the cainclude widget, based on

a “list generating command”

-------------------------------------------------------------

* I don't know the cainclude widget yet, but Didier told me that there

is a scripting tool from Mike Laznovsky, which can generate list-panels

in form of a table for a PV.

Scaled alignment of widgets based on a machine coordinate system / PVs:

-------------------------------------------------------------

* it would be good to have X,Z coordinates (center or corner) and the

size of each device in these two dimensions.

Wishlist what should be improved for plotting-display options

-------------------------------------------------------------

* it would make sense to concentrate the efforts on 2 tools:

--> a simple, light-weight tool with a limited feature-set for quick

visualizations

--> a feature-rich visualization suite, which can be extended with

scripts while offering a repository for them to profit from other

peoples work (similar to pshell)

Another important feature would be that the launcher checks if a panel

exist before opening it a 2nd (or 3rd) time and transferring the focus

to this panel. Maybe this can be done also via caqtdm.

It would also be nice, if all solutions could be done in way that other

accelerators may use them as well, to help streamlining operational tools.

---Comments Andreas---

———————————————

Update rate of panels/widgets

———————————————

As fas as I know there is already a method to limit the update rate in caqtdm.
What we want in addition is:
- to be able to define the max. update rate for a specific panel (or even for a specific widget).
- to be able to change this max. update rate at runtime (starting up with .5 Hz and switching to 10 Hz if required)

———————————————

Dynamic generation of the macro list for the cainclude widget, based on a “list generating command”

———————————————

The cainclude allows you to include the same file multiple times and expanding it with different macros.
The included qt panels are automatically stacked; either vertically, horizontally or in a table grid.
What we want is to have a macroCommand that is called at startup and the output of that command is used to fill the macroList.
We don't need any sorting done by caqtdm: the macroCommand will provide the list in the correct order.

I don't thing that Mike is even using cainclude with stacking and macro lists. He's simply generating some panels from scripts.
The XML files are plain text files, easy to generate. That's what I'm doing with the synoptic: it's fine for a single purpose, but inflexible for generic applications.

———————————————

Scaled alignment of widgets based on a machine coordinate system / PVs

———————————————

The simplest implementation would be, to provide a generic extension of all ca* widgets:
- in addition to the properties X and Y one would provide
    - X_PV, Y_PV and X_SCALE, Y_SCALE
- if X_PV or Y_PV are not "", then
    - connect to those PVs
    - multiply the value with the corresponding *_SCALE factor
    - set X or Y accordingly
For performance reasons one might want to have a switch like:
- XY_PV_UPDATE ("at init", "on monitor")
In most cases one only want to calculate the widget placement once at start-up.
But for some fancy things like a moving bunch compressor one might want to update "on monitor".

Size scaling is probably not necessary, unless you want to make it dynamic to zoom in or out.
At least I would put that on a much lower priority. Although it would be cool..  ;-)
What you draw on the screen is given by the content of the include.
I guess there is already a QT widget that allows you to scale whatever is drawn into it.
Full QT windows have this feature already: you can tell each widget to rescale its size proportionally when the window is resized.

———————————————

Wishlist what should be improved for plotting-display options

———————————————

I think that this will probably need more discussion, to first collect all requirements and then decide which tool should provide what feature.

One open question was, if caqtdm would need additional widgets for plotting.
E.g. a barchart where each bar connects to a different channel.
But this could be achieved as well with the placement of widgets based on machine coordinate PVs (see above).