-
Notifications
You must be signed in to change notification settings - Fork 53
/
changelog.txt
121 lines (98 loc) · 4.91 KB
/
changelog.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
CHANGELOG
===========
Background
-----------------
MXCuBE is a project with a long history, initially started at ESRF in 2003 and built
on top of an inhouse developed framework called Framework-2. The project has since
been adopted by a large number of sites performing MX experiments. There is within
MXCuBE the possibility to create encapsulated pieces of code that pertain to certain
equipment or routines. This logic is written as what's called HardwareObjects. These
HardwareObjects can be configured via XML (and more recently YAML) files, there is
further an infrastructure for emitting events from and to HardwareObjects. Each site
has the possibility to extend and adapt the functionality by adding site specific
HardwareObjects.
During the course of time parts of the API have been "organically" patched and grown
to be less consistent. The MXCuBE developers team therefore decided that it would be
crucial to refactor and clean up inconsistencies and rework other aspects of the
core functionality (known as HardwareRepository) to facilitate the further
development of the MXCuBE application.
The MXCuBE developers conducted a series of meetings and workshops to discuss these
matters before starting the initial work. The discussions have naturally continued
during the process and some are still ongoing. This means that there are still
features and ideas that are being discussed that are not yet settled but are likely
to be implemented soon, found in the BEING DRAFTED section. Finally, the aim of
this rework is to make it easier and faster to extend MXCuBE with new functionality.
It will also contribute to make it easier for new sites to adopt MXCuBE.
During this process a more rigorous versioning schema have been put in place to
facilitate the update and maintenance process of the software on the various sites.
This file is the first changelog and is meant to summarise the changes made in a
comprehensible way so that any developer can get an idea of what has changed, being
discussed and is still subject to change. It's of course impossible to summarize
all the work that have been done during the course of the last 2 years but the
intention is that the developer with this information can get a good idea of what
is considered stable or at least to be well informed enough to know when to ask the
community for input.
## Added/Changed in Version 1.0.0 - 2022-06-21
=================================
- HardwareRepository was renamed to mxcubecore and made into a Python module (installable with i.e pip)
- Possibility to configure HardwareObjects using YAML
- All method names and variables are snake cased
- Methods that set a value of a member are prefixed with set_[member name] and members
that retrieve a value are called get_[member name].
- The HardwareObject base class have been refactored so that all hardware objects have
application wide state being either: UNKNOWN, WARNING, BUSY, READY, FAULT or OFF
accessed via the "get_state" method
A HardwareObject can further implement a device/routine specific state accessed via
get_specific_state.
The HardwareObject base class implements the following methods that can be considered
part of the stable API (defined by the class HardwareObjectMixin in BaseHardwareObjects.py)
abort()
stop()
get_state()
get_specific_state()
wait_ready(timeout=None)
is_ready()
update_state(state=None)
update_specific_state(state=None)
re_emit_values()
force_emit_signals()
emit(signal, *args)
connect(sender, signal, slot=None)
disconnect(sender, signal, slot=None)
The AbstractActuator base class implements the functionality required by hardware objects
that act as actuators or more specifically have a value. This includes a value, its
limits and limit validation. An object inheriting abstract actuator has the following
signature in addition to that of HarwareObject:
get_value()
get_limits()
set_limits(limits)
validate_value(value)
set_value(value, timeout=0)
update_value(value=None)
update_limits(limits=None)
The abstract classes considered stable are derived from HardwareObject and/or AbstractActuator
and considered stable are:
AbstractAperture
AbstractBeam
AbstractCharacterisation
AbstractDetector
AbstractEnergy
AbstractEnergyScan
AbstractFlux
AbstractMCA
AbstractMachineInfo
AbstractMotor
AbstractNState
AbstractResolution
AbstractSampleChanger
AbstractSampleView
AbstractShutter
AbstractSlits
AbstractTransmission
BEING DRAFTED (Likely to be implemented soon)
AbstractDiffractometer
AbstractCollect
AbstractProcedure
AbstractCentring
AbstractProcessing
Improvements of Queuing system