Whereby, December 17, 2025

Meeting Minutes

## Participants {#participants .list-paragraph}

## Marcus Oscarsson, Antonia Beteva, Yan Walesch, Didier Nurizzo (ERSF) {#marcus-oscarsson-antonia-beteva-yan-walesch-didier-nurizzo-ersf .list-paragraph}

Elmir Yagudin, Ezequiel Panepucci (MAX IV)

Rasmus Fogh. Peter Keller (Global Phasing)

Michael Hellmig, Hedi Tej (BESSY)

Daniel Eriksson (ANSTO)

Andrey Gtuzinov (DESY)

Rafael Lyra (LNLS)

Alessandro Olivo (Elettra)

Joseph Brunzelle, Pamela Focia (LS-CAT)

Dan

## Feedback from last MXCuBE meeting in Oxford {#feedback-from-last-mxcube-meeting-in-oxford .list-paragraph}

#  {#section .list-paragraph}

Only one point was made relative to the meeting itself, specifically
that it would have been nice if the occasion of having industrial users
present had been used also to gather feedback on MXCuBE itself.

It was noted that there might be a number of proposed corrections to the
minutes of the meeting discussions, and that .docx format was ill suited
to making changes in pull requests. It was therefore agreed to try
submitting minutes in markdown instead. **DONE: RF**.

The next MXCuBE meeting is 9-12 June at BESSY in Berlin. This meeting
includes a code camp, and the agreed topic is making in-depth tutorials
for the internals of MXCuBE. It is noted that status reports this time
must be sent in two weeks in advance for summarising or selection of
actual talks, and that active working groups should send in a status
report as well.

## Log style for non HardwareObjects {#log-style-for-non-hardwareobjects .list-paragraph}

EY presented his pull request, proposing a new standard format for
logging commands for use outside of HardwareObjects. AB raised one
problem with this, that it would not be possible to use this framework
for sending logging calls from external libraries like Bliss. It was
agreed to accept and merge the new logging style, and that the Bliss
problem would have to be dealt with separately.

## **Configuration repository** {#configuration-repository .list-paragraph}

RF proposed postponing the completion of the separate configuration
repository till the ESRF had started using yaml configuration in
production, and putting only yaml configuration files into it. The
meeting, however, agreed that the configuration repository would need a
set of XML configuration files as well, since several synchrotrons would
be using XML configuration for a while yet. It was pointed out that the
mxcubeweb demo/ and demo.yaml/ directories were both correct and up to
date. RF undertook to set up the configuration repository accordingly,
though possibly not until ESRF had indeed gone over to yaml
configuration. **ACTION: RF**.

## **AbstractDiffractometer, Latest tests** {#abstractdiffractometer-latest-tests .list-paragraph}

The Abstract Diffractometer has been extensively tested and should now
be ready for merging and production use (AB). The changes include a
number of non-core functions being moved from the Diffractometer to the
SampleView, and some breaking changes, e.g. replacing the phase name
strings with an enumeration. It was agreed that this should me merged in
January. AB planned to write a new PR, as the current one had become too
complex through repeated rebasing. **ACTION: AB**.

On the point of the more precise definition of coordinate axes and motor
axis definitions and the way this was documented, PK has started a
discussion on github that still needs some additional input. AB noted in
this respect that what was proposed did not aspire to be a standard but
only a convention.

UX/UI working group

A new working group is being started on user interfaces, with a specific
interest in the problems raised by automation in multi-user sessions. EP
and Daniele de Sanctis will lead it, and are asking for volunteers. It
was agreed that the working group should do its work in a github
discussion, and it was pointed out that users that joined the
corresponding team on github would automatically receive notifications
of activity on the discussion.

## **Any Other Business** {#any-other-business .list-paragraph}

###  {#section-1 .list-paragraph}

### **Yaml configuration** {#yaml-configuration .list-paragraph}

It was clarified that the yaml configuration was merged and fully
functional. It had been used in anger at MAX IV and extensively tested
at the ESRF. ESRF plans to take it into production soon, though the
original target date of January 2026 has slipped.

### **\_init function** {#init-function .list-paragraph}

It was clarified that HardwareObjects do indeed need a \_init()
function, but that this need not be programmed each time, since the
function is defined in the topmost superclass.

### Autoamatic log-out of inactive accounts. {#autoamatic-log-out-of-inactive-accounts. .list-paragraph}

Dan raised the problem of users not active in the UI being automatically
logged out even though experiments were still running, The consensus was
that this was not a deliberate behaviour and so was most likely a bug.

### Integrating components and EPICS {#integrating-components-and-epics .list-paragraph}

RL (LNLS) had written a number of new components and started a
discussion of the best way of integrating them in MXCuBE so that others
could also use them. This was very positively received. There were
multiple aspects.

New components that were *not* specific to a single site should be put
in the top-level HardwareObject directory, whereas site-specific
components should go in e.g. the LNLS subdirectory.

The best way to document the new objects could be found in the online
MXCuBE documentation, both for examples and for actual instructions. For
a first effort it was recommended to put documentation in class headers,
whence it is automatically extracted by the MXCuBE documentation
generation scripts.

It was noted that there were now many EPICS users in MXCuBE, including
LNLS,LS-CAT, ANSTO, and the Taiwan and Shanghai synchrotrons, and they
were encouraged to come together in an EPICS users subgroup. ESS also
uses EPICS, though the interactions ar via an intermediate layer, and
BESSY has some minimal EPICS use as well.

LNLS needs to integrate MXCuBE with both BlueSky (instrument control)
and Kafka (messaging), and it was asked whether there was already
something in MXCuBE that was built to interact with outside APIs. The
answer is that the commands and channels facilities were made for this
purpose, though there is no guarantee that they will work for this
particular problem,

### Messaging libraries {#messaging-libraries .list-paragraph}

It was clarified that ESRF is moving away from XMLRPC (for security
reasons). The most favoured replacements would be REST (http) or
GoogleRPC. PK (Global Phasing) registered an interest, since GPhL needs
a messaging application for communication with their workflow, and the
current py4j may need replacing at some point. GPhL had mostly been
considering ZeroMQ or RabbitMQ. It was agree that the two sides should
keep each other informed of their deliberations, possibly through a
github discussion.

### AbstractLIMS {#abstractlims .list-paragraph}

It was clarified that the new abstract LIMS clients that are being
written were not the same thing as AbstractLIMS, which is essentially a
synonym for what is now MXLIMS. The two efforts started in a similar
place, but have now completely diverged.